On 11/30/23 18:45, Edgecombe, Rick P wrote:
> On Wed, 2023-11-29 at 15:07 -0600, Madhavan T. Venkataraman wrote:
>> 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.edgeco...@intel.com/
>
> 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
