|
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
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: [tech-tee] RISCV PMP enhancement
ACK, I'll update the doc accordingly.
Regards,
Nick
ACK, I'll update the doc accordingly.
Regards,
Nick
|
By
Nick Kossifidis
·
#14
·
|
|
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
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
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
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
·
|
|
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
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 Waterman
·
#11
·
|
|
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.
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
Nick Kossifidis
·
#10
·
|
|
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.
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
Nick Kossifidis
·
#9
·
|
|
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
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
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
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
Is it worth adding a generic rationale comment, for example around the
definition of WARL?
Paolo
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
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
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 Waterman
·
#5
·
|
|
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
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
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
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: [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
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
·
|
|
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
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 Waterman
·
#1
·
|