Nick Kossifidis wrote: I'd like to point out that my own proposal does always allow for the locking of regions for the next boot stages, when that's appropriate. If unlocked M-mode PMP entries can't

Hello Tariq, You don't need to do a ROP attack on BootROM to remove the rules, any code that runs on M-mode can remove them in a few instructions. I don't see how we can have a security control on M

It's not just for glitch protection, but also for security to control access permissions. The software is loaded from the boot ROM and the boot ROM does not contain software to unlock the PMP entries

I wrote: Bill Huffman: To answer your question, for current standard PMP, when a PMP entry makes a region execute-only for all modes, MXR does not make reading possible from any mode, because MXR is

Στις 2020-02-13 22:30, John Hauser έγραψε: S/U mode doesn't have access to PMP registers so it's not possible to distinguish between an access fault e.g. due to a bug on an application /

I'm afraid I agree with John. I asked the same question myself some months ago - but less forcefully. :-) On one level, I agree with John here. But MXR and MPRV were set up when M mode never had

I concur with JohnH's reasoning. Omitting the new cause code does not remove any essential functionality, since M-mode software or debugger software can examine the protection and translation

Nick Kossifidis wrote: I'm sorry to say, providing information to a debugger is not usually considered a valid reason for additional RISC-V exception codes when the same information can be extracted

>A while ago, I expressed opposition to consuming one of the remaining pmpcfg bits because it seemed, >at the time, that the goals of this proposal could be accomplished without doing so. If that is

Hello John and thanks for your feedback, The new mechanism (when MML is set) introduces a barrier between S/U mode and M mode, We want to be able to distinguish between an access fault due to

Sure, something custom would work. And what you suggested is a good possibility. But I brought it up because I thought the use case might be more broadly applicable and maybe some combination in

Bill Huffman wrote: Concerning PMP, that's what I was suggesting, yes. I believe the answer can be physical memory attributes (PMAs), which apply in addition to the software-programmable PMP

Hello John, I'm thinking positively about your proposal for a 2-bit MSL field and a 2-bit PL field per PMP entry. But I'm still a little concerned by what you say below... Chipmakers sometimes

Sean Halle wrote: Hi Sean, I'm afraid I wasn't completely clear on what question you're asking. Is your baseline case a Fedora OS that doesn't configure PMP? I don't know the current behavior of

Pull request is here: https://github.com/riscv/riscv-isa-manual/pull/484

Thank you John, Joe, Greg and Andrew for the interesting discussion. One general question, at more of a management level. Our architecture has 16 harts per core. That means that the CSR logic is one

A while ago, I expressed opposition to consuming one of the remaining pmpcfg bits because it seemed, at the time, that the goals of this proposal could be accomplished without doing so. If that is

I wrote: "I assume there is also an independent DMC bit (Default Memory Closed)." - John Hauser

As promised, here is my suggestion for modifying the TEE Task Group's "PMP Enhancements" proposal to have four security levels, to support a larger set of use cases. Instead of the two bits MML and

It seems like the current trade-off in supported use cases is due to the combination of two constraints: backward compatibility and avoiding use of a Reserved PMP bit. A year ago the exact degree of