coreboot.git - my copy of coreboot

Age	Commit message (Collapse)	Author
2024-08-11	arch/riscv: Add PMP print function	Maximilian Brune
	For easier debugging it is useful to have a function that prints the PMP regions. Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I6ab1531c65b14690e37aecf57ff441bf22db1ce5 Reviewed-on: https://review.coreboot.org/c/coreboot/+/83283 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: ron minnich <rminnich@gmail.com>
2024-03-14	arch/riscv: support physical memory protection (PMP) registers	Ronald G Minnich
	PMP (Physical Memory Protection) is a feature of the RISC-V Privileged Architecture spec, that allows defining region(s) of the address space to be protected in a variety of ways: ranges for M mode can be protected against access from lower privilege levels, and M mode can be locked out of accessig to memory reserved for lower privilege levels. Limits on Read, Write, and Execute are allowed. In coreboot, we protect against Write and Execute of PMP code from lower levels, but allow Reading, so as to ease data structure access. PMP is not a security boundary, it is an accident prevention device. PMP is used here to protect persistent ramstage code that is used to support SBI, e.g. printk and some data structures. It also protects the SBI stacks. Note that there is one stack per hart. There are 512- and 1024-hart SoC's being built today, so the stack should be kept small. PMP is not a general purpose protection mechanism and it is easy to get around it. For example, S mode can stage a DMA that overwrites all the M mode code. PMP is, rather, a way to avoid simple accidents. It is understood that PMP depends on proper OS behavior to implement true SBI security (personal conversation with a RISC-V architect). Think of PMP as "Protection Minus Protection". PMP is also a very limited resource, as defined in the architecture. This language is instructive: "PMP entries are described by an 8-bit configuration register and one XLEN-bit address register. Some PMP settings additionally use the address register associated with the preceding PMP entry. Up to 16 PMP entries are supported. If any PMP entries are implemented, then all PMP CSRs must be implemented, but all PMP CSR fields are WARL and may be hardwired to zero. PMP CSRs are only accessible to M-mode." In other words if you implement PMP even a little, you have to impelement it all; but you can implement it in part by simply returning 0 for a pmpcfg. Also, PMP address registers (pmpaddr) don't have to implement all the bits. On a SiFive FU740, for example, PMP only implements bits 33:0, i.e. a 34 bit address. PMPs are just packed with all kinds of special cases. There are no requirements that you read back what you wrote to the pmpaddr registers. The earlier PMP code would die if the read did not match the write, but, since pmpaddr are WARL, that was not correct. An SoC can just decide it only does 4096-byte granularity, on TOR PMP types, and that is your problem if you wanted finer granulatiry. SoC's don't have to implement all the high order bits either. And, to reiterate, there is no requirement about which of the pmpcfg are implemented. Implementing just pmpcfg15 is allowed. The coreboot SBI code was written before PMP existed. In order for coreboot SBI code to work, this patch is necessary. With this change, a simple S-mode payload that calls SBI putchar works: 1: li a7, 1 li a0, 48 ecall j 1b Without this change, it will not work. Getting this to build on RV32 required changes to the API, as it was incorrect. In RV32, PMP entries are 34 bits. Hence, the setup_pmp needed to accept u64. So, uinptr_t can not be used, as on 32 bits they are only 32 bit numbers. The internal API uses uintptr_t, but the exported API uses u64, so external code does not have to think about right shifts on base and size. Errors are detected: an error in base and size will result in a BIOS_EMERG print, but not a panic. Boots not bricks if possible. There are small changes to the internal API to reduce stack pressure: there's no need to have two pmpcfg_t on the stack when one will do. TEST: Linux now boots partly on the SiFive unmatched. There are changes in flight on the coreboot SBI that will allow Linux to boot further, but they are out of scope for this patch. Currently, clk_ignore_unused is required, this requires a separate patch. Change-Id: I6edce139d340783148cbb446cde004ba96e67944 Signed-off-by: Ronald G Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/81153 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Hug <philipp@hug.cx>
2024-03-09	arch/riscv: Remove typedefs	Maximilian Brune
	typedefs violate our coding-style Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: Id51eda53b6b53ed2cc66c0339c03c855c12c1bd8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/81124 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Hug <philipp@hug.cx>
2020-05-11	treewide: Remove "this file is part of" lines	Patrick Georgi
	Stefan thinks they don't add value. Command used: sed -i -e '/file is part of /d' $(git grep "file is part of " \|egrep ":( /\.\/\$\|#\|;#\|-- \| \ )" \| cut -d: -f1 \|grep -v crossgcc \|grep -v gcov \| grep -v /elf.h \|grep -v nvramtool) The exceptions are for: - crossgcc (patch file) - gcov (imported from gcc) - elf.h (imported from GNU's libc) - nvramtool (more complicated header) The removed lines are: - fmt.Fprintln(f, "/* This file is part of the coreboot project. /") -# This file is part of a set of unofficial pre-commit hooks available -/ This file is part of coreboot / -# This file is part of msrtool. -/ This file is part of msrtool. / - This file is part of ncurses, designed to be appended after curses.h.in -/* This file is part of pgtblgen. / - This file is part of the coreboot project. - /* This file is part of the coreboot project. / -# This file is part of the coreboot project. -# This file is part of the coreboot project. -## This file is part of the coreboot project. --- This file is part of the coreboot project. -/ This file is part of the coreboot project / -/ This file is part of the coreboot project. / -;## This file is part of the coreboot project. -# This file is part of the coreboot project. It originated in the - This file is part of the coreinfo project. -## This file is part of the coreinfo project. - * This file is part of the depthcharge project. -/* This file is part of the depthcharge project. / -/ This file is part of the ectool project. / - This file is part of the GNU C Library. - * This file is part of the libpayload project. -## This file is part of the libpayload project. -/* This file is part of the Linux kernel. / -## This file is part of the superiotool project. -/ This file is part of the superiotool project / -/ This file is part of uio_usbdebug */ Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-03-06	src/arch/riscv: Convert to SPDX license header	Patrick Georgi
	This also drops individual copyright notices, all mentioned authors in that part of the tree are listed in AUTHORS. Change-Id: I770c1afd9b68a40ec0e69818f24b5ef3ad4f1d35 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39283 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2018-10-11	riscv: add physical memory protection (PMP) support	Xiang Wang
	These codes are written by me based on the privileged instruction set. I tested it by qemu/riscv-probe. Change-Id: I2e9e0c94e6518f63ade7680a3ce68bacfae219d4 Signed-off-by: Xiang Wang <wxjstz@126.com> Reviewed-on: https://review.coreboot.org/28569 Reviewed-by: Philipp Hug <philipp@hug.cx> Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>