------------------------------------------------------------------

From:Dong Du <dudong@...>

Send Time:2021年5月4日(星期二) 16:54

To:bichengyang <bichengyang@...>; tech-privileged <tech-privileged@...>; tech-tee <tech-tee@...>

Subject:Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] Updates on the proposal of MPU (privious sPMP)

BTW, we would like to know more opinions from privilege group and H-extension group on how MPU/sPMP and virtualization should be used together,

  e.g., do we have any scenarios that should use paging, MPU (sPMP), and  G-stage translation together?

Please feel free to give us any feedbacks to help moving forward.

All the best,

Dong

 

 

------------------ Original ------------------

From:  "bichengyang"<bichengyang@...>;

Date:  Tue, May 4, 2021 04:44 PM

To:  "tech-privileged"<tech-privileged@...>; "tech-tee"<tech-tee@...>;

Subject:  [RISC-V] [tech-privileged] Updates on the proposal of MPU (privious sPMP)

 

Hello all,

After the discussion of the tee group, we decide to rename sPMP to MPU (the RISC-V Memory Protection Unit), and reuse page fault for MPU fault based on our discussion and feedback of the privileged group.

Therefore we propose to rename page fault to MPU/MMU fault for clarity.

We also have updates on the proposal of MPU:
https://docs.google.com/document/d/1x7esOSBFfpcbDHaRPpe5NEWmav1_8der_nB25Hd5hqs/edit?usp=sharing

Best, 
Bicheng

------------------------------------------------------------------

From:Nick Kossifidis <mick@...>

Send Time:2021年5月5日(星期三) 16:29

To:郑文斌(玄翦) <zhengwenbin.zwb@...>

Cc:bichengyang <bichengyang@...>; tech-privileged <tech-privileged@...>; tech-tee <tech-tee@...>; 杜东 <dudong@...>; anup.patel <anup.patel@...>

Subject:Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] Updates on the proposal of MPU (privious sPMP)

Στις 2021-05-05 07:47, Robin Zheng via lists.riscv.org έγραψε:

> sPMP(MPU) is designed for the separation between U-mode and S-mode and 
> it only make sense only when paging is not available. With H extension, 
> there're 3 atp registers  to control the translation for different 
> stages:
> - satp (normal translation for HS-mode)
> - vsatp (1st translation for VS-mode)
> - hgatp (2nd translation for VS-mode)
> and there also has 2 hypervisor types for virtualization model:
> 
> For Hypervisor Type-I, sPMP(MPU) makes sense when paging is not 
> available in Guest OS(s). But it makes no sense for hypervisor 
> itself(who is working in HS-mode) even if hypervisor has no paging too, 
> because Type-I hypervisor only runs under HS-mode and has no user 
> space.
> For Hypervisor Type-II,  sPMP(MPU) also makes sense when paging is not 
> available in Guest OS(s). sPMP(MPU) also makes sense for Host OS who 
> without paging, but for most host OS, e.g., Linux, Windows, MacOS, 
> paging is always available, I didn't see a Host OS who supports 
> virtualization but has no paging support.
> 
> Thus, when H extension exists, sPMP(MPU) makes more sense for VS-mode 
> other than HS-mode, i don't think we need to support sPMP(MPU) for 
> both(HS-mode and VS-mode).
> 
> Regards,
> Robin

(ccing Anup for more feedback on this)

This distinction between type 1 and type 2 hypervisors is a bit 
obsolete. If you consider type 1 hypervisors as bare-metal, then KVM for 
example is a type 1 hypervisor, you may check out Anup's patches for KVM 
on RISC-V and you'll notice that the kernel runs on HS mode, modifying 
h* CSRs, so basically Host OS is the hypervisor as well, and it still 
has userspace for monitoring, configuration, device emulation etc. If 
you consider type 1 hypervisors as standalone without their own 
userspace then it makes sense to not use paging for their own mappings, 
they can reduce code complexity and memory usage, in which case having 
an MPU to enforce memory protections makes perfect sense. There is 
nothing preventing satp = bare && vsatp != bare, its a very possible 
scenario, supported by the current spec, so since we introduce an MPU 
why not make it available for HS mode as well ? Wouldn't that break the 
concept that "HS-mode acts the same as S-mode, but with additional 
instructions and CSRs that control the new stage of address translation 
and support hosting a guest OS in virtual S-mode (VS-mode). Regular 
S-mode operating systems can execute without modification either in 
HS-mode or as VS-mode guests" ?

Also in case the vendor doesn't want to implement 2-stage translation 
(hgatp can be hardwired to 0 in the current spec), doesn't it make sense 
to have an option of using MPU for managing memory protection for the 
guest's physical memory, providing isolation between the host and the 
guest and between guests ? Why rely on PMP/ePMP on M-mode for that 
requiring to go though M-mode every time the hypervisor wants to switch 
between guests ?

Regards,
Nick

------------------------------------------------------------------

From:Nick Kossifidis <mick@...>

Send Time:2021年5月6日(星期四) 19:58

To:郑文斌(玄翦) <zhengwenbin.zwb@...>

Cc:Nick Kossifidis <mick@...>; bichengyang <bichengyang@...>; tech-privileged <tech-privileged@...>; tech-tee <tech-tee@...>; 杜东 <dudong@...>; anup.patel <anup.patel@...>

Subject:Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] Updates on the proposal of MPU (privious sPMP)

Στις 2021-05-06 08:04, Robin Zheng via lists.riscv.org έγραψε:

> Hi, Nick
> There is nothing preventing satp = bare && vsatp != bare, its a very 
> possible
> scenario, supported by the current spec, so since we introduce an MPU
> why not make it available for HS mode as well ?
> For hypervisor type-I,  when satp = bare && vsatp != bare,  the 
> protection for VM can be done by 2nd-stage translation(hgatp != bare), 
> but in that case, since the bare hypervisor can access VM memory 
> freely, SMAP protection may be required by HS-mode. That may require 
> the MPU(sPMP) to extend another bit to distinguish VS-mode and HS-mode, 
> just like S bit does, isn't it ? When 2nd-stage translation is 
> disabled(hgatp = bare), it makes sense by MPU, and for SMAP protection, 
> it still requries the distinction for the access, from HS-mode or 
> VS-mode.  Since there're 3 modes, i.e., U/VS/HS, would we add another 
> bit besides S bit for MPU(sPMP)?
> 
> Regards,
> Robin
> 

The goal of SMAP/SMEP (or HSMAP/HSMEP in this case) is to prevent 
accidental access / execution of memory controlled by a low privileged 
level, from a higher privileged one (e.g. due to a bug), but for this to 
happen both privilege levels need to have the same view of the virtual 
memory or at least share some memory regions / mappings. This doesn't 
apply here, in the general case the host and the guest will use a 
different set of physical regions / page tables, and when hgatp != bare, 
they'll also have a different view of the physical memory. So for 
accessing the memory of the guest, even when hgatp = bare, the host 
would need to create shared regions / mappings, and that's not 
accidental (it can only be accidental when satp = vsatp = hgatp = bare, 
a highly unlikely scenario), if an attacker manages to compromise the 
hypervisor like this it's game over. We can't do much in the scenario of 
a compromised/malicious host, it's still an open issue and the way to 
solve it is probably to use some form of attestation to prove to the 
guest that the host is trustworthy (but that's another discussion). The 
problem is when hgatp = bare, in which case a malicious guest will be 
able to access the memory of other guests and / or the host by creating 
mappings to the same physical memory. With the current spec it's 
possible to prevent this using PMP/ePMP on M-mode, my point is that it 
makes more sense to e.g. have a set of hmpu* registers and let the 
hypervisor handle it directly on HS mode. My other point is that since 
MPU is defined for S mode it should be available to both HS/VS modes. 
Using a separate bit for distinguishing between HS/VS wouldn't work here 
because we still need VS to manage its own regions, we need a separate 
table, so basically I'm talking about mpu*/vmpu*/hmpu* registers in the 
same way we have satp/vsatp/hgatp.

Regards,
Nick

------------------------------------------------------------------

From:Nick Kossifidis <mick@...>

Send Time:2021年5月6日(星期四) 19:58

To:郑文斌(玄翦) <zhengwenbin.zwb@...>

Cc:Nick Kossifidis <mick@...>; bichengyang <bichengyang@...>; tech-privileged <tech-privileged@...>; tech-tee <tech-tee@...>; 杜东 <dudong@...>; anup.patel <anup.patel@...>

Subject:Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] Updates on the proposal of MPU (privious sPMP)

Στις 2021-05-06 08:04, Robin Zheng via lists.riscv.org έγραψε:

> Hi, Nick
> There is nothing preventing satp = bare && vsatp != bare, its a very
> possible
> scenario, supported by the current spec, so since we introduce an MPU
> why not make it available for HS mode as well ?
> For hypervisor type-I,  when satp = bare && vsatp != bare,  the
> protection for VM can be done by 2nd-stage translation(hgatp != bare),
> but in that case, since the bare hypervisor can access VM memory
> freely, SMAP protection may be required by HS-mode. That may require
> the MPU(sPMP) to extend another bit to distinguish VS-mode and HS-mode,
> just like S bit does, isn't it ? When 2nd-stage translation is
> disabled(hgatp = bare), it makes sense by MPU, and for SMAP protection,
> it still requries the distinction for the access, from HS-mode or
> VS-mode.  Since there're 3 modes, i.e., U/VS/HS, would we add another
> bit besides S bit for MPU(sPMP)?
>
> Regards,
> Robin
>

The goal of SMAP/SMEP (or HSMAP/HSMEP in this case) is to prevent
accidental access / execution of memory controlled by a low privileged
level, from a higher privileged one (e.g. due to a bug), but for this to
happen both privilege levels need to have the same view of the virtual
memory or at least share some memory regions / mappings. This doesn't
apply here, in the general case the host and the guest will use a
different set of physical regions / page tables, and when hgatp != bare,
they'll also have a different view of the physical memory. So for
accessing the memory of the guest, even when hgatp = bare, the host
would need to create shared regions / mappings, and that's not
accidental (it can only be accidental when satp = vsatp = hgatp = bare,
a highly unlikely scenario), if an attacker manages to compromise the
hypervisor like this it's game over. We can't do much in the scenario of
a compromised/malicious host, it's still an open issue and the way to
solve it is probably to use some form of attestation to prove to the
guest that the host is trustworthy (but that's another discussion). The
problem is when hgatp = bare, in which case a malicious guest will be
able to access the memory of other guests and / or the host by creating
mappings to the same physical memory. With the current spec it's
possible to prevent this using PMP/ePMP on M-mode, my point is that it
makes more sense to e.g. have a set of hmpu* registers and let the
hypervisor handle it directly on HS mode. My other point is that since
MPU is defined for S mode it should be available to both HS/VS modes.
Using a separate bit for distinguishing between HS/VS wouldn't work here
because we still need VS to manage its own regions, we need a separate
table, so basically I'm talking about mpu*/vmpu*/hmpu* registers in the
same way we have satp/vsatp/hgatp.

Regards,
Nick