tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

TEE proposal for M-mode SMEP/SMAP via PMP

PrivArch folks, The TEE TG has proposed additional PMP functionality to mitigate some forms of security attack against M-mode. A description of the threat model and the proposed augmentation is at

By andrew@... · #1 ·

Re: [RISC-V] [tech-tee] TEE proposal for M-mode SMEP/SMAP via PMP

Excellent point, Greg. I think either nop or setting a security error bit (which would cause an error the next time the entry or the PMP was used) would be better than making the exception depend on

By Bill Huffman · #2 ·

Re: [RISC-V] [tech-tee] TEE proposal for M-mode SMEP/SMAP via PMP

This all looks very good, except for one issue with item 3b: "Adding a new PMP rule with pmpcfg.L and pmpcfg.X bits set fails with Security exception." RISC-V architecture - rather nicely - currently

By Greg Favor · #3 ·

Re: TEE proposal for M-mode SMEP/SMAP via PMP

I’ve been keeping track of it, and I’m pretty happy with it. -Allen

By Allen Baum · #4 ·

Re: [RISC-V] [tech-tee] TEE proposal for M-mode SMEP/SMAP via PMP

Although I still haven’t grokked the proposal, I can say I agree with your line of reasoning. This use case doesn’t justify crossing the Rubicon of data-dependent traps. Your proposed solution

By andrew@... · #5 ·

Re: [RISC-V] [tech-tee] TEE proposal for M-mode SMEP/SMAP via PMP

Is it worth adding a generic rationale comment, for example around the definition of WARL? Paolo

By Paolo Bonzini · #6 ·

Re: [RISC-V] [tech-tee] TEE proposal for M-mode SMEP/SMAP via PMP

The other possibility is to simply write it, but any access that is matched by it (and not overridden by another with a lower index?) causes a security exception. That is actually how I thought it did

By Allen Baum · #7 ·

Re: [RISC-V] [tech-tee] TEE proposal for M-mode SMEP/SMAP via PMP

I notice another seeming issue, in the "rationale" for item 3a, where it says: First, it would be good for this rule locking behavior to be explicitly included in item 3's description of the

By Greg Favor · #8 ·

Re: [RISC-V] [tech-tee] TEE proposal for M-mode SMEP/SMAP via PMP

Hello Greg and thanks for your feedback ! Στις 2019-12-21 05:04, Greg Favor έγραψε: Good point, I've updated the document so that writing pmpcfg.L and pmpcfg.X while MML is set is ignored.

By mick@... · #9 ·

Re: [RISC-V] [tech-tee] TEE proposal for M-mode SMEP/SMAP via PMP

Hello Greg, Στις 2019-12-22 03:12, Greg Favor έγραψε: In the current PMP spec, the only way for a rule to be enforced on M-mode is for that rule to have the L bit set, hence being locked.

By mick@... · #10 ·

misa.T bit = Ztso?

A while back, it was proposed that the Ztso extension (which strengthens the memory model to RVTSO instead of RVWMO) be discoverable via the misa.T bit. The T bit had been tentatively reserved for a

By andrew@... · #11 ·

Re: [tech-tee] RISCV PMP enhancement

I have just noticed a minor spec hole here: the new security exception has mCause=16. The question is, whether xEDELEG[16] is RW or must be fixed as WARL 0? I am assuming it must be fixed to 0, but

By Allen Baum · #12 ·

Re: [tech-tee] RISCV PMP enhancement

Good point, Allen. I think it would make good sense to begin assigning mCause values >= 64 where there's no likelihood of wanting a rapid delegation to a privilege below M. The Security Exception is

By Bill Huffman · #13 ·

Re: [tech-tee] RISCV PMP enhancement

ACK, I'll update the doc accordingly. Regards, Nick

By mick@... · #14 ·

comments on PMP enhancements

Hello all, I've been studying the TEE Task Group's "PMP Enhancements" proposal with great interest off-and-on for several weeks. I definitely agree with the intention of the proposal, but I see

By John Hauser · #15 ·

Re: comments on PMP enhancements

I wrote: Correction: I believe that should say "... implicitly grants read permission to S/U modes when in M mode and MXR = 1". This is relevant only when MPRV = 1 and MPP = 0 or 1, so it's a rather

By John Hauser · #16 ·

Re: comments on PMP enhancements

For 4.. As we discussed in the meeting we agree with the use case, lock is existing in current PMP. The current PMP enhancement proposal tries to be back compatible and thus does not try to address

By Joe Xie · #17 ·

Re: comments on PMP enhancements

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

By Greg Favor · #18 ·

enhanced PMP with four security levels

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

By John Hauser · #19 ·

Re: enhanced PMP with four security levels

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

By John Hauser · #20 ·

1 - 20 of 1334

Home Hashtags Subgroups Terms