Re: Stacks, was Segments

On Thu, 6 Feb 2025 21:53:27 +0000, EricP wrote:

Stephen Fuld wrote:

-----------------
>
I am a little confused here.  When you talk about I0MMU addresses, are
you talking about memory addresses or disk addresses?  ISTM that
protecting memory of lower privileged programs is useless if a higher
privileged program can force a page out to disk, then can read the data
from the disk drive itself.  Of course, the same is true for data
written to disk by a lesser privileged program.  If the higher
privileged program can read the file, then it can compromise security.

>
I'm just kinda free associating what the consequences of restricting
the HV's access to lesser privilege levels might be.
>
As I understand it, the AMD secure HV approach is that memory owned by a
guest kernel and its applications is encrypted and only the guest kernel
has the key. Memory content is only decrypted while inside the core.
As the key is only stored inside that guest kernel memory there is
no way for HV to get at it.

Interesting, so you can see the data you just can't interpret the
bit-patterns. This still leaves the door open for malicious action.

So it doesn't matter that the HV has access to guest memory because it
can only see encrypted memory values. Presumably such data is encrypted
on disk so intercepting a DMA gives you nothing.

It maters if HV can access (especially modify) what is in storage
(not memory), making it impossible for secure process from using
his own data !

But it doesn't look like blocking HV access to the guest kernel, user,
or sandbox memory accomplishes the same security because the HV can
always diddle its own page tables to grant itself access.

My 66000 does it differently. HV can create a PTE that translates
"anywhere", but cannot use the VA of Guest OS or SM in order to
use that PTE. There are 4 VAS privilege levels::
               HoB = 0          nest   HoB = 1       nest
application:   application VAS   yes   no access       X
Guest OS       application VAS   yes   Guest OS VAS   yes
HyperVisor     HyperVisor VAS    no    Guest OS VAS   yes
Secure         HyperVisor VAS    no    SM VAS         no
So, HV has no 'direct' path to Application VAS using standard
memory access protocols.