Date
1 - 2 of 2
[RISC-V] [tech-tee] TEE proposal for M-mode SMEP/SMAP via PMP
Bill Huffman
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 the data that's written to the CSR. Having an
exception on CSR data makes for an annoying pipeline timing issue.
Bill
On 12/20/19 7:04 PM, Greg Favor wrote:
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 avoids having any "register-operate" instructions that cause architectural exceptions based on data-dependent execution (e.g. based on the value of its register operands). Currently all computational instructions and CSR rd/wr instructions conform to this. In contrast, item 3b violates this and would represent the first and only case in which implementations have to signal an exception on a "register-operate" instruction at execution time (versus based on what can be checked at decode time).
If people agree that this is undesirable, then it seems like the suggested alternative or "fix" to this would be that the write to a pmpcfg CSR write with pmpcfg.L and pmpcfg.X bits set, would not be performed (i.e. the write is ignored and the register remains unchanged). If desired, one could imagine things like also setting some form of "security error" bit in the new mseccfg CSR.
Greg
On Fri, Dec 20, 2019 at 3:23 PM Andrew Waterman <andrew@...> wrote:
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 the link below. Please review and provide feedback on this thread; I'll do the same shortly.
Thanks,Andrew
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 work. Then it's handled exactly like all the other exception - basically noRWX, but instead of an access exception, its a security exception.
On Fri, Dec 20, 2019 at 7:14 PM Bill Huffman <huffman@...> wrote:
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 the data that's written to the CSR. Having an exception on CSR data makes for an annoying pipeline timing issue.
Bill
On 12/20/19 7:04 PM, Greg Favor wrote:
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 avoids having any "register-operate" instructions that cause architectural exceptions based on data-dependent execution (e.g. based on the value of its register operands). Currently all computational instructions and CSR rd/wr instructions conform to this. In contrast, item 3b violates this and would represent the first and only case in which implementations have to signal an exception on a "register-operate" instruction at execution time (versus based on what can be checked at decode time).
If people agree that this is undesirable, then it seems like the suggested alternative or "fix" to this would be that the write to a pmpcfg CSR write with pmpcfg.L and pmpcfg.X bits set, would not be performed (i.e. the write is ignored and the register remains unchanged). If desired, one could imagine things like also setting some form of "security error" bit in the new mseccfg CSR.
Greg
On Fri, Dec 20, 2019 at 3:23 PM Andrew Waterman <andrew@...> wrote:
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 the link below. Please review and provide feedback on this thread; I'll do the same shortly.
Thanks,Andrew