Message-ID: <4103d68b07bb382e434cdaf19ab1986f9079b0bb.camel@intel.com>
Date: Fri, 1 Dec 2023 00:45:49 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "peterz@...radead.org" <peterz@...radead.org>,
	"madvenka@...ux.microsoft.com" <madvenka@...ux.microsoft.com>
CC: "ssicleru@...defender.com" <ssicleru@...defender.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "mic@...ikod.net"
	<mic@...ikod.net>, "marian.c.rotariu@...il.com" <marian.c.rotariu@...il.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "wei.liu@...nel.org"
	<wei.liu@...nel.org>, "virtualization@...ts.linux-foundation.org"
	<virtualization@...ts.linux-foundation.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "tgopinath@...rosoft.com" <tgopinath@...rosoft.com>,
	"chao.p.peng@...ux.intel.com" <chao.p.peng@...ux.intel.com>,
	"qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jgowans@...zon.com" <jgowans@...zon.com>, "ztarkhani@...rosoft.com"
	<ztarkhani@...rosoft.com>, "mdontu@...defender.com" <mdontu@...defender.com>,
	"x86@...nel.org" <x86@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
	"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
	"jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "vkuznets@...hat.com"
	<vkuznets@...hat.com>, "Andersen, John S" <john.s.andersen@...el.com>,
	"yu.c.zhang@...ux.intel.com" <yu.c.zhang@...ux.intel.com>,
	"nicu.citu@...oud.com" <nicu.citu@...oud.com>, "keescook@...omium.org"
	<keescook@...omium.org>, "Graf, Alexander" <graf@...zon.com>,
	"wanpengli@...cent.com" <wanpengli@...cent.com>,
	"dev@...ts.cloudhypervisor.org" <dev@...ts.cloudhypervisor.org>,
	"will@...nel.org" <will@...nel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>, "linux-security-module@...r.kernel.org"
	<linux-security-module@...r.kernel.org>, "yuanyu@...gle.com"
	<yuanyu@...gle.com>, "linux-hyperv@...r.kernel.org"
	<linux-hyperv@...r.kernel.org>, "linux-hardening@...r.kernel.org"
	<linux-hardening@...r.kernel.org>, "quic_tsoni@...cinc.com"
	<quic_tsoni@...cinc.com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>
Subject: Re: [RFC PATCH v2 17/19] heki: x86: Update permissions counters
 during text patching

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.edgecombe@intel.com/

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

Powered by blists - more mailing lists