linux-kernel - Re: [RFC PATCH v1 0/9] Hypervisor-Enforced Kernel Integrity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fd1dd8bcc172093ad20243ac1e7bb8fce45b38ef.camel@intel.com>
Date:   Tue, 30 May 2023 16:23:22 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "mic@...ikod.net" <mic@...ikod.net>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "hpa@...or.com" <hpa@...or.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "wanpengli@...cent.com" <wanpengli@...cent.com>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>
CC:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "qemu-devel@...gnu.org" <qemu-devel@...gnu.org>,
        "liran.alon@...cle.com" <liran.alon@...cle.com>,
        "marian.c.rotariu@...il.com" <marian.c.rotariu@...il.com>,
        "Graf, Alexander" <graf@...zon.com>,
        "Andersen, John S" <john.s.andersen@...el.com>,
        "madvenka@...ux.microsoft.com" <madvenka@...ux.microsoft.com>,
        "ssicleru@...defender.com" <ssicleru@...defender.com>,
        "yuanyu@...gle.com" <yuanyu@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tgopinath@...rosoft.com" <tgopinath@...rosoft.com>,
        "jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        "will@...nel.org" <will@...nel.org>,
        "dev@...ts.cloudhypervisor.org" <dev@...ts.cloudhypervisor.org>,
        "mdontu@...defender.com" <mdontu@...defender.com>,
        "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>,
        "nicu.citu@...oud.com" <nicu.citu@...oud.com>,
        "ztarkhani@...rosoft.com" <ztarkhani@...rosoft.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC PATCH v1 0/9] Hypervisor-Enforced Kernel Integrity

On Fri, 2023-05-26 at 17:22 +0200, Mickaël Salaün wrote:
> > > Can the guest kernel ask the host VMM's emulated devices to DMA
> > > into
> > > the protected data? It should go through the host userspace
> > > mappings I
> > > think, which don't care about EPT permissions. Or did I miss
> > > where you
> > > are protecting that another way? There are a lot of easy ways to
> > > ask
> > > the host to write to guest memory that don't involve the EPT. You
> > > probably need to protect the host userspace mappings, and also
> > > the
> > > places in KVM that kmap a GPA provided by the guest.
> > 
> > Good point, I'll check this confused deputy attack. Extended KVM
> > protections should indeed handle all ways to map guests' memory.
> > I'm
> > wondering if current VMMs would gracefully handle such new
> > restrictions
> > though.
> 
> I guess the host could map arbitrary data to the guest, so that need
> to 
> be handled, but how could the VMM (not the host kernel) bypass/update
> EPT initially used for the guest (and potentially later mapped to the
> host)?

Well traditionally both QEMU and KVM accessed guest memory via host
mappings instead of the EPT. So I'm wondering what is stopping the
guest from passing a protected gfn when setting up the DMA, and QEMU
being enticed to write to it? The emulator as well would use these host
userspace mappings and not consult the EPT IIRC.

I think Sean was suggesting host userspace should be more involved in
this process, so perhaps it could protect its own alias of the
protected memory, for example mprotect() it as read-only.

There is (was?) some KVM PV features that accessed guest memory via the
host direct map as well. I would think mprotect() should protect this
at the get_user_pages() stage, but it looks like the details have
changed since I last understood it.