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


Nick Kossifidis
 

Hello Tariq,

On 2/14/20 1:39 PM, Tariq Kurd wrote:
The threat model Tariq brought up was about detecting a glitch attack but the glitch can also happen when setting
a rule in the first place, I don't see how this is the proper approach, PMP is not there as an anti-tampering
mechanism. If we want this as a debug feature I'm ok with it but it must be treated as such and not as a security
improvement.

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 so we are not (obviously) susceptible to a code-reuse ROP attack to reprogram the PMP, because the software to do so doesn't exist in the existing code.
If we need to lock regions to prevent such things from other software later then we need the flexibility to be able to lock the regions individually on a case by case basis.

Put simply we need orthogonal controls for locking and M-mode only access.
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 mode without also locking
the rules for preventing further modifications from the next boot
stages. If the next boot stage runs on S/U mode then that's not a
problem since S/U-mode-only rules are removable.

When defining security controls there are guarantees we put in place.
Let's say that we did everything correctly, both in hw and sw, up to the
point where we place the PMP rule there to prevent "other software"
running on M-mode from accessing some memory region. Can we guarantee
that this restriction will be enforced and that "other software" can't
simply bypass it ? I don't believe we can provide such a guarantee,
hence we can't claim this approach to be a security control. If the code
we are trying to restrict has direct control over the security control,
then it's not a security control, it's an ilusion of a security control.
To the contrary it may pose a security threat.

In contrast a locked PMP rule guarantees that "other software" on M mode
can't remove it, same goes for rules placed by M mode for restricting
S/U mode, since S/U mode can't modify PMP entries, or with MMU
restrictions implemented on S mode, since U mode can't modify the page
tables.

Your DMC proposal for exapmle for restricting M mode from accessing any
region not covered by a PMP rule is a security control, it's a more
strict version of MML where M mode is only restricted from executing
such a region. I'm more positive towards adding that, than allowing for
unlocked M-mode-only PMP rules, although the same can be achieved with a
locked M-mode-only rule, or with a locked PMA rule (that's even better
since it's valid for all harts).

There are multiple use cases for the PMP, some we know about but many we don't and others won't have been thought of yet - so the proposal need to be flexible. Nick has a use case in mind which is perfectly valid with MML but unfortunately it doesn't cover our use case, and it also causes problems for Nvidia as Joe told us during the meeting on Tuesday.
We had the same discussion with Joe some time ago, they wanted to
restrict their BootROM if I remember corectly so that it becomes
inaccessible after it jumps to the next boot stage. We concluded that
since this is not a per-hart protection, it's better to handle it in PMA
checker instead of PMP (and I think there was a proposal for a task
group on programmable PMAs where such solutions can be discussed). In
any case their scenario is covered by the current proposal, unless there
is a different scenario I'm not aware of.

If we can come up with specific use cases not covered by the current
proposal, and valid threat models for them, I'm all in for proposing new
security controls, what I try to prevent is to allow for weak security
controls in the name of flexibility.

As we discussed on our previous call, I'm not against such a feature, as
Andy pointed out, it is a useful debug feature and I can understand why
you may want to use it. My ojections are:

a) It should be disabled by default.
b) It should be noted that this is not a security control but a debug
feature.
c) It should be noted that this needs to be disabled after sw is done
using it (e.g. during the boot sequence), and remains disabled until
hard-reset (sticky bit).

Regards,
Nick

Join tech-privileged@lists.riscv.org to automatically receive all group messages.