Radim Krčmář and Anup Patel
dac15cb910
lib: sbi_hart: reset mstateen0
...
The current logic clears some bits based on SBI known extensions.
Be safe and do not leave enabled anything that SBI doesn't control.
This is not a breaking change, because the register must be initialized
to 0 by the ISA on reset, but it is better to not depend on it when we
don't need to.
Reviewed-by: Anup Patel <anup@brainfault.org >
Signed-off-by: Radim Krčmář <rkrcmar@ventanamicro.com >
Link: https://lore.kernel.org/r/20250429142549.3673976-8-rkrcmar@ventanamicro.com
Signed-off-by: Anup Patel <anup@brainfault.org >
2025-04-30 10:14:26 +05:30
Radim Krčmář and Anup Patel
8c814b5c9b
lib: sbi_hart: fix sstateen emulation
...
The Sstateen extension defines 4 sstateen registers, but SBI currently
configures the execution environment to throw illegal instruction
exception when accessing sstateen1-3.
SBI should implement all sstateen registers, so delegate the
implementation to hardware by setting the SE bit.
Reviewed-by: Anup Patel <anup@brainfault.org >
Signed-off-by: Radim Krčmář <rkrcmar@ventanamicro.com >
Link: https://lore.kernel.org/r/20250429142549.3673976-7-rkrcmar@ventanamicro.com
Signed-off-by: Anup Patel <anup@brainfault.org >
2025-04-30 10:14:26 +05:30
Radim Krčmář and Anup Patel
6b877fb53b
lib: sbi_hart: reset sstateen and hstateen
...
Not resetting sstateen is a potential security hole, because U might be
able to access state that S does not properly context-switch.
Similar for hstateen with VS and HS.
Reviewed-by: Anup Patel <anup@brainfault.org >
Signed-off-by: Radim Krčmář <rkrcmar@ventanamicro.com >
Link: https://lore.kernel.org/r/20250429142549.3673976-6-rkrcmar@ventanamicro.com
Signed-off-by: Anup Patel <anup@brainfault.org >
2025-04-30 10:14:26 +05:30
Radim Krčmář and Anup Patel
009f77a9f0
lib: sbi_hart: reset hstatus
...
hstatus.HU must be cleared, because U-mode could otherwise use the
HLS/HSV instructions. This would allow U-mode to read physical memory
directly if vgatp and vsatp was 0.
The remaining fields don't seem like a security vulnerability now, but
clearing the whole CSR is not an issue, so do that be safe.
Reviewed-by: Anup Patel <anup@brainfault.org >
Signed-off-by: Radim Krčmář <rkrcmar@ventanamicro.com >
Link: https://lore.kernel.org/r/20250429142549.3673976-5-rkrcmar@ventanamicro.com
Signed-off-by: Anup Patel <anup@brainfault.org >
2025-04-30 10:14:26 +05:30
Radim Krčmář and Anup Patel
65e8be4fe8
lib: sbi: use 64 bit csr macros
...
Switch the most obvious cases to new macros.
Reviewed-by: Anup Patel <anup@brainfault.org >
Signed-off-by: Radim Krčmář <rkrcmar@ventanamicro.com >
Link: https://lore.kernel.org/r/20250429142549.3673976-4-rkrcmar@ventanamicro.com
Signed-off-by: Anup Patel <anup@brainfault.org >
2025-04-30 10:14:25 +05:30
Radim Krčmář and Anup Patel
f82c4bdf8c
lib: sbi: add 64 bit csr macros
...
Most CSRs are XLEN bits wide, but some are 64 bit, so rv32 needs two
accesses, plaguing the code with ifdefs.
Add new helpers that split 64 bit operation into two operations on rv32.
The helpers don't use "csr + 0x10", but append "H" at the end of the csr
name to get a compile-time error when accessing a non 64 bit register.
This has the downside that you have to use the name when accessing them.
e.g. csr_read64(0x1234) or csr_read64(CSR_SATP) won't compile and the
error messages you get for these bugs are not straightforward.
Reviewed-by: Anup Patel <anup@brainfault.org >
Signed-off-by: Radim Krčmář <rkrcmar@ventanamicro.com >
Link: https://lore.kernel.org/r/20250429142549.3673976-3-rkrcmar@ventanamicro.com
Signed-off-by: Anup Patel <anup@brainfault.org >
2025-04-30 10:14:25 +05:30
