I wrote: Allen Baum: By the "M & L proposal" I meant Tariq Kurd's proposal, the one I was speaking of. (On your own cheat sheet from yesterday, the tab for this proposal is labeled "sep_M&L". But I

I wrote: Allen Baum: Sorry, I meant that, under the existing standard, locked PMP entries are intended to deny some or all accesses from M mode to a memory region. The RISC-V standard says, "In

Jonathan Behrens wrote: Because the PMP table is explicitly searched in order for a match, locked entries must always be at the head of the table to be truly effective. When software wants to add a

You need to be careful with terminology. I am assuming that "denying access to Mmode" means "denying the ability of M-mode to change an entry" , and not "denying access to the region

Remind me, did all the other proposals have a way to prevent the S/U-mode entries from being reconfigured to M-mode ones later? Locking M-mode entries doesn’t do a ton if more can be added later

Hello all, Concerning the proposal from Tariq Kurd (Huawei) with separate M and L bits in PMP configuration bytes, in my view there are two details that should disqualify it from consideration, at

I'm going to suggest removing the DMC bit and replacing it with "any region locked". This is a lot less expensive than a configuration bit, and I'd argue it gives you the functionality you need.

Thanks Allen and John, I found John's version easier to read and I have added an extra sheet "permissions" to it showing the effect of the 4 different schemes. I give an idea of how to program the

Allen Baum wrote: I've attached my own version, somewhat simplified. (I edited Allen's file with LibreOffice on Linux. Hope it comes through clear for everyone.) Since the MML and MSL variables

Here is my visual cheat sheet showing the 3 proposals

Hello all, I've created a more convenient PDF document of my proposal to give our enhanced PMP four security levels, available here: http://www.jhauser.us/RISCV/Hauser_enhancedPMP-0.2.pdf The

Hi Nick, John, Here's my proposal for adding two fields to the proposed MSECCFG CSR: DPL and DMC. This proposal assumes that the programming model for the permissions is sufficient without adding

Hello Jonathan, Page tables aren't vastly easier to modify, we are talking about doing page table walking, finding the pte you want to modify and then modify the one used by the hardware and also the

Hi Allen, Since it looks like you're responding to me, I'll try to answer. There are now three proposals that I know of. The original and most visible is the task group's working proposal, which

I read the proposed changes (some of them at least) as reducing the cost of security, not so much adding security or making it more secure. E.g. having a default rule costs a single bit rather using

Coming from an operating systems background, the concern about locking PMP entries being absolutely necessary for security comes across as overblown. I've never heard of a platform that provided

Hello John, Στις 2020-02-14 22:56, John Hauser έγραψε: So does the original PMP spec and the group's proposal. There are people already using PMP as-is in production, providing TEE and

Hello Tariq, Στις 2020-02-17 11:02, Mr Tariq Kurd έγραψε: I'm referring to your original proposal of a bit that when set allows for locked rules to be removed / edited (DPL) temporarily. I

Two quick comments: - I am assuming that this is a proposal to replace the existing "enhanced" PMP proposal, rather than an "enhanced-enhanced" PMP proposal. - do we ever need to allow Write_Only

Hi Nick, Thanks for the feedback, and I understand your arguments. When you say "It" above are you talking about: 1. my original proposal (DMC and DPL) 2. my updated proposal (M-bit in each PMP