Page MenuHomeFreeBSD

riscv: Panic on PMP errors
ClosedPublic

Authored by kp on Sep 24 2020, 10:54 AM.

Details

Summary

Load/store/fetch access exceptions always indicate a violation of a PMP
rule. We can't treat those as page faults, because updating the page
table and trying again will only result in exactly the same access
exception recurring. This leaves us in an endless exception loop.

We cannot recover from these exceptions, so panic instead.

Sponsored by: Axiado

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

kp requested review of this revision.Sep 24 2020, 10:54 AM
kp created this revision.

That's not true. You can get those faults even without a PMP if you try and access non-existent memory or if the hardware gives a bus fault due to an access that's not legal for a given peripheral.

Those would also be unrecoverable errors, right?

The problem I'm trying to address here is that if FreeBSD touches PMP protected memory it'll get a load/store/fetch fault and right now it treats that like a TLB miss, tries to load the right page table entry and then tries again. Which faults again, which ...

(And as an aside, is there a better resource about RISC-V in these situations than "RISC-V Instruction Set Manual: Volume II: Privileged Architecture"? I can't seem to find anything relevant about bus errors there, but I may also be overlooking it.)

Panicking here makes sense. Perhaps call it a "memory access exception" rather than a "PMP violation" per Jess's comment. I don't know of any other reference besides the priv spec.

Yeah, the privileged spec calls each an "X access fault". The non-PMP discussion is in the "Physical Memory Attributes" section, and is a more general thing that can include bus faults on implementations where they can occur.

Hopefully correct patch

This revision is now accepted and ready to land.Tue, Sep 29, 5:56 PM
This revision was automatically updated to reflect the committed changes.

Should we be doing something for user load/store/fetch faults? Probably a SIGBUS?

Or maybe a panic if we don't expect that to ever happen (though if you start doing memory-mapped devices that's no longer the case).

Should we be doing something for user load/store/fetch faults? Probably a SIGBUS?

Yes, we should.

See https://reviews.freebsd.org/D26621

I mmap()ed /dev/mem and accessed PMP protected memory. I see the same endless fault loop as in kernel mode, but it's easily "fixed" by terminating the process.

I did need to implement /dev/mem mmap to test that: https://reviews.freebsd.org/D26622