tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

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

By Allen Baum · #54 ·

Re: comments on PMP enhancements

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

By Jonathan Behrens <behrensj@...> · #53 ·

Re: comments on PMP enhancements

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

By John Hauser · #52 ·

Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] enhanced PMP with four security levels

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.

By Allen Baum · #51 ·

Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] enhanced PMP with four security levels

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

By Mr Tariq Kurd <tariq.kurd@...> · #50 ·

Re: enhanced PMP with four security levels

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

By John Hauser · #49 ·

Re: enhanced PMP with four security levels

Here is my visual cheat sheet showing the 3 proposals

By Allen Baum · #48 ·

Re: enhanced PMP with four security levels

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

By John Hauser · #47 ·

Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

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

By Mr Tariq Kurd <tariq.kurd@...> · #46 ·

Re: comments on PMP enhancements

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

By mick@... · #45 ·

Re: comments on PMP enhancements

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

By John Hauser · #44 ·

Re: comments on PMP enhancements

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

By Allen Baum · #43 ·

Re: comments on PMP enhancements

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

By Jonathan Behrens <behrensj@...> · #42 ·

Re: comments on PMP enhancements

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

By mick@... · #41 ·

Re: [RISC-V] [tech-tee] comments on PMP enhancements

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

By mick@... · #40 ·

Re: comments on PMP enhancements

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

By Allen Baum · #39 ·

Re: [RISC-V] [tech-tee] comments on PMP enhancements

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

By Mr Tariq Kurd <tariq.kurd@...> · #38 ·

Re: comments on PMP enhancements

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

By John Hauser · #37 ·

Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

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

By mick@... · #36 ·

Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

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

By Mr Tariq Kurd <tariq.kurd@...> · #35 ·

1281 - 1300 of 1334

Home Hashtags Subgroups Terms