Hello John,

Στις 2020-02-14 22:56, John Hauser έγραψε:
>
> 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.
>

So does the original PMP spec and the group's proposal.

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

There are people already using PMP as-is in production, providing TEE
and secure boot mechanisms (e.g. multizone and keystone) without needing
the ability to have removable / editable rules on M-mode. For 1+ year
that we've been working on this proposal to improve PMP so that it can
also be used to provide access / execution prevention from M-mode, we've
only heard of such a requirement from Huawei so that the PMP spec
matches their solution. I'm not against incorporating such a feature,
all I want is to make sure it's there for the right reasons and that
it's defined properly. On one hand I get your point that we need to be
as flexible as possible, on the other hand we can't please everyone,
especially by making an already established security control weaker.
RISC-V already allows for vendors to implement their own PMP mechanism
anyway and vendors will do that regardless of the PMP spec, the proposed
mseccfg CSR may make this even easier / cleaner to do so e.g. by having
vendor-specific fields there in the future. Where do we put the line
between a spec that provides a set of security guarantees, and allowing
for that spec to be weaker for flexibility ?

At least in Huawei's case what they want can be integrated to the
group's proposal (or even the current PMP spec since it's independent of
MML) easily, and hopefully without compromising security if defined /
used properly. What happens if a vendor asks for something that allows
e.g. for a security control to be completely bypassed (e.g. disable
SMEP), or for an insecure crypto algorithm to be added on one of our
specs, or for a security mechanism that's not secure at all ? Will we go
for flexibility or for security ?

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

When a system gets compromised it's everyone's problem. It's not a
matter of having or not having a hw mechanism, it's a matter of properly
defining what's the goal of this mechanism and its scope. If we say for
example that a region is "protected by PMP" when on M-mode, and the
corresponding rule can be removed / edited by M-mode at any time, in a
few instructions, then we will be lying. If the spec is not absolutely
clear on how a security mechanism works and under which conditions it
provides security guarantees, things will go wrong. It has happened many
times in the past where people created specs or products that allowed
for less-secure (or even totally insecure) configurations to be used.

Regards,
Nick

Hello all,

I've created a more convenient PDF document of my proposal to give our
enhanced PMP four security levels, available here:
http://www.jhauser.us/RISCV/Hauser_enhancedPMP-0.2.pdf

The purpose is to provide additional options for better protection than
MML = 0, for those times when it is not yet possible to set MML = 1.
More rationale is in the document.

Regards,

    - John Hauser

Thanks Allen and John,

I found John's version easier to read and I have added an extra sheet "permissions" to it showing the effect of the 4 different schemes. I give an idea of how to program the different modes, but I'm mainly showing which combinations of

M-mode permissions
S/U-mode permissions
Locked / unlocked

....are possible.

I'm planning to use this to help an internal discussion on the options in the next few days.

Tariq


-----Original Message-----
From: tech-tee@... [mailto:tech-tee@...] On Behalf Of John Hauser
Sent: 19 February 2020 06:23
To: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] enhanced PMP with four security levels

Allen Baum wrote:
> Here is my visual cheat sheet showing the 3 proposals

I've attached my own version, somewhat simplified.  (I edited Allen's file with LibreOffice on Linux.  Hope it comes through clear for
everyone.)

Since the MML and MSL variables serve the same purpose, I've rearranged the tables to keep those dimensions aligned.  Also, I feel that the question of whether a "security exception" or an ordinary access fault is taken is an entirely separate debate, so I removed that distinction from the tables.  I've made some other simplifications and realignments to aid comparison, as you'll see.

Regards,

    - John Hauser

On Wed, Feb 19, 2020 at 3:46 PM John Hauser via Lists.Riscv.Org <jh.riscv=jhauser.us@...> wrote:

Hello all,

Concerning the proposal from Tariq Kurd (Huawei) with separate M and L
bits in PMP configuration bytes, in my view there are two details
that should disqualify it from consideration, at least as currently
designed:

First, as we all know, the existing PMP standard allows PMP entries to
be locked, with the clear intention of denying access to M mode.  In
the task group's working proposal and in my proposal for four security
levels, when higher security is enabled (MML = 1 or MSL > 0), these
locked PMP entries retain their enforcement for M mode but deny all
access to S/U mode.  The M & L proposal does the opposite:  It denies
all access to M mode and gives access to S/U mode!  If an earlier
stage of boot software is unaware of the PMP extension, it might easily
create such locked entries (L = 1, M = 0), after which M mode will be
helpless to deny S/U access, or grant itself access when MML = 1.  That
looks obviously wrong to me.

Second, the M & L proposal doesn't currently offer an option to totally
lock down the executable regions for M mode, a feature touted for the
task group's working proposal and kept in my proposal with MSL = 3.  I
see no reason why this feature should be abandoned.

I believe both of these flaws can be fixed, but only at the expense of
the simple separation of the L and M bits.  In fact, you start to get a
design that looks more like my proposal.

The one feature clearly offered by the M & L proposal and not by
the other two is the ability to lock PMP entries that allow S/U-mode
access.  But on this point, I have to agree with Nick Kossifidis:  I
don't see a need for this ability.

Remind me, did all the other proposals have a way to prevent the S/U-mode entries from being reconfigured to M-mode ones later? Locking M-mode entries doesn’t do a ton if more can be added later

Regards,

    - John Hauser

Creating a new thread, for a new topic, although I'm excerpting some old
email as inspiration.

Anyway: Andrew Waterman tells me that 1 of the big purposes of M-mode is
to emulate instructions.

For example, a hardware implementation may not implement misaligned memory
accesses. But these can trap to M mode, which can emulate.

Q: doesn't MML, M-mode lockdown, preventing M-mode from reading or
writing, interfere with such emulation? At least in the cases where the
M-mode code needs to actually perform memory accesses on behalf of the
code that it is emulating.

My apologies if this is already been discussed. I mentioned this to Andrew
a week or so ago, meant to post to this list, but I want to read all the
history before I embarrass myself. That hasn't happened, so I just want to
send this email and risk embarrassing myself and wasting your time if you
have already discussed this.

I can't resist a meta-observation: M-mode is going the way of Intel SMM.
There are too many different uses, which should be indifferent privileged
domains, that are being crammed into the single M-mode privileged level.

-----Original Message-----
From: tech-privileged@... <tech-privileged@...> On
Behalf Of John Hauser
Sent: Wednesday, February 19, 2020 14:29
To: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] comments on PMP enhancements

... under the existing standard, locked PMP entries are intended to deny
some or all accesses from M mode to a memory region.  The RISC-V standard
says, "In addition to locking the PMP entry, the L bit indicates whether
the R/W/X permissions are enforced on M-mode accesses."  The only reason
the entry is locked is so that M mode can't then undo this restriction
imposed on it.