Re: Stacks, was Segments

On Sun, 9 Feb 2025 20:45:13 +0000, EricP wrote:

MitchAlsup1 wrote:

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.

>
Yes. Their Secure VM sounds exactly like what a timeshare vendor might
want
if they desire to sell services to governments and businesses that have
secrets that rogue operators must provably not access.

Just enough to gain the confidence of *.gov buyers, without enough
to prevent NSA from using the data.

Also blocks accidental leaks between guests so you could have multiple
such secure guest OS on the same host.
>

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 !

>
Yes a rogue or buggy HV could DoS a guest OS by scrambling its data.
Or an ECC memory error on critical memory location, like the key.
>

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.

>
But the physical memory in use by that guest can be remapped
by rogue HV to be in its own virtual space and then accessed.

You can never get away from the notion that the code creating
PTP and PTE bit patterns, or manipulating Root pointers requires
a certain amount of trust.