How can M mode emulate instructions if it is locked down?


Andy Glew Si5
 

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.


Jonathan Behrens <behrensj@...>
 

Hi Andy,

M-mode can use mstatus.mprv to access S/U-mode memory regions, provided that S/U-mode has read access to them. If any non-readable regions are configured then trap-and-emulate won't be possible for them. However, it has been pointed out that this wouldn't be a huge issue because non-readable regions are also non-writable. This means that once the relevant PMP entry is installed, the contents of that memory is fixed and so M-mode can be sure that no instructions requiring emulation are placed in that region.

Regarding your point about M-mode becoming similar to Intel SMM, I share your concern. I also worry that it might also end up resembling SMM in the sense that the actual owner of the CPU ends up having very limited visibility or control over the most privileged code that is being run.

Jonathan


On Wed, Feb 19, 2020 at 8:01 PM Andy Glew Si5 via Lists.Riscv.Org <andy.glew=sifive.com@...> wrote:
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.