Hello Tariq,

Στις 2020-02-17 11:02, Mr Tariq Kurd έγραψε:

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 entry)
The best solution for us would be the M-bit in each PMP entry and also
DMC, as this gives us the smallest PMP hardware for our embedded
cores.
I can write a two proposals, one for the M-bit and one for DMC and
email them if you like
Tariq

I'm referring to your original proposal of a bit that when set allows for locked rules to be removed / edited (DPL) temporarily. I also see some value as I mentioned for the DMC bit you also proposed and it seems others believe it would be useful, although it can be implemented differently. I understand that you want to be flexible to allow both locked and unlocked rules for M-mode with the per-entry M bit but to me this introduces a security risk and doesn't provide any security benefits.

As we discussed on our conf call we can simply add the two bits you propose on mseccfg introduced on the group's proposal, if you agree with having them disabled by default (to also be backwards compatible), not define DPL as a security control (DMC on the other hand is a security control and we can define it as such), and allow DPL to be locked (possibly with another bit) so that it can't be re-enabled after sw is done using it.

Regards,
Nick

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 objections 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).

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 entry)

The best solution for us would be the M-bit in each PMP entry and also DMC, as this gives us the smallest PMP hardware for our embedded cores.

I can write a two proposals, one for the M-bit and one for DMC and email them if you like

Tariq

-----Original Message-----
From: tech-tee@... [mailto:tech-tee@...] On Behalf Of John Hauser
Sent: 14 February 2020 20:57
To: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-tee] comments on PMP enhancements

Nick Kossifidis wrote:

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. [...]

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.

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.

If unlocked M-mode PMP entries can't be called security controls, then fine, let's call them something else. As I see it, the point is that there is a demand/need for such an ability, it obviously involves PMP, and furthermore it's been shown that the physical mechanisms are very close to one another. If you ignore this other need and adopt the current proposal, there's a very good chance we'll end up having to retrofit the PMP table to support this other need later, creating a bigger mess than if we learn to accomodate it now.

I understand you're afraid that offering any compromises in the PMP mechanism will allow developers to choose the not-totally-secure options and delude themselves that it gives them true security.
But that's not a hardware-mechanisms problem; that's a problem for software policies and their enforcement. That concern needs to be dealt with in a different way than by hobbling the hardware.

For my part, I will try to be much more careful about my use of the words "secure" and "security" going forward.

Regards,

- John Hauser