On 11/30/23 18:45, Edgecombe, Rick P wrote:

On Wed, 2023-11-29 at 15:07 -0600, Madhavan T. Venkataraman wrote:

quoted

Threat Model
------------

In the threat model in Heki, the attacker is a user space attacker
who exploits
a kernel vulnerability to gain more privileges or bypass the kernel's
access
control and self-protection mechanisms. 

In the context of the guest page table, one of the things that the
threat model translates
to is a hacker gaining access to a guest page with RWX permissions.
E.g., by adding execute
permissions to a writable page or by adding write permissions to an
executable page.

Today, the permissions for a guest page in the extended page table
are RWX by
default. So, if a hacker manages to establish RWX for a page in the
guest page
table, then that is all he needs to do some damage.

I had a few random comments from watching the plumbers talk online:

Is there really a big difference between a page that is RWX, and a RW
page that is about to become RX? I realize that there is an addition of
timing, but when executable code is getting loaded it can be written to
then and later executed. I think that gap could be addressed in two
different ways, both pretty difficult:
 1. Verifying the loaded code before it gets marked 
    executable. This is difficult because the kernel does lots of 
    tweaks on the code it is loading (alternatives, etc). It can't 
    just check a signature.
 2. Loading the code in a protected environment. In this model the 
    (for example) module signature would be checked, then the code 
    would be loaded in some sort of protected environment. This way 
    integrity of the loaded code would be enforced. But extracting 
    module loading into a separate domain would be difficult. 
    Various scattered features all have their hands in the loading.

Secondly, I wonder if another way to look at the memory parts of HEKI
could be that this is a way to protect certain page table bits from
stay writes. The RWX bits in the EPT are not directly writable, so more
steps are needed to change things than just a stray write (instead the
helpers involved in the operations need to be called). If that is a
fair way of looking at it, then I wonder how HEKI compares to a
solution like this security-wise:
https://lore.kernel.org/lkml/20210830235927.6443-1-rick.p.edgecombe@intel.com/ (local)

Functional-wise it had the benefit of working on bare metal and
supporting the normal kernel features.

Thanks for the comments. I will think about what you have said and will respond
soon.

Madhavan