Page MenuHomeFreeBSD

riscv: Clear SUM in SSTATUS for supervisor mode exceptions.
ClosedPublic

Authored by jhb on Apr 14 2021, 4:46 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 3, 10:47 PM
Unknown Object (File)
Mon, Oct 21, 5:04 PM
Unknown Object (File)
Thu, Oct 17, 10:51 PM
Unknown Object (File)
Oct 10 2024, 1:50 PM
Unknown Object (File)
Oct 4 2024, 2:40 PM
Unknown Object (File)
Oct 4 2024, 1:48 PM
Unknown Object (File)
Oct 2 2024, 6:13 AM
Unknown Object (File)
Oct 2 2024, 4:30 AM
Subscribers

Details

Summary

Previously, a page fault taken during copyin/out and related functions
would run the entire fault handler while permitting direct access to
user addresses. This could also leak across context switches (e.g. if
the page fault handler was preempted by an interrupt or slept for disk
I/O).

To fix, clear SUM in assembly after saving the original version of
SSTATUS in the supervisor mode trapframe.

Sponsored by: DARPA

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 38752
Build 35641: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Apr 14 2021, 4:46 PM
sys/riscv/riscv/exception.S
108–111

You should be able to li t0, SSTATUS_SUM; csrc sstatus, t0

Looks good. Just curious, does the issue manifest in practice or was it caught by inspection?

This revision is now accepted and ready to land.Apr 21 2021, 4:12 PM

Looks good. Just curious, does the issue manifest in practice or was it caught by inspection?

No evidence we've ever accidentally accessed a user address. But you do very quickly fall over with the added assertion as you take page faults in copyin/out for init. I was talking on IRC with someone who was discovering a similar issue on Linux (https://github.com/torvalds/linux/commit/285a76bb2cf51b0c74c634f2aaccdb93e1f2a359) and it made me realise this issue in FreeBSD. (If you're wondering, Armv8 doesn't have this issue, since the PAN bit gets saved to SPSR and cleared in PSTATE on traps, and x86 has the code in its trap handler to clear AC, so it's just a RISC-V issue.)