linux-kernel - Re: [PATCH 16/18] KVM: x86: Take mem attributes into account when faulting memory

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: <D3MJJCTNY7OM.WOB5W8AVBH9G@amazon.com>
Date: Thu, 22 Aug 2024 15:21:02 +0000
From: Nicolas Saenz Julienne <nsaenz@...zon.com>
To: Nicolas Saenz Julienne <nsaenz@...zon.com>,
	<linux-kernel@...r.kernel.org>, <kvm@...r.kernel.org>
CC: <pbonzini@...hat.com>, <seanjc@...gle.com>, <vkuznets@...hat.com>,
	<linux-doc@...r.kernel.org>, <linux-hyperv@...r.kernel.org>,
	<linux-arch@...r.kernel.org>, <linux-trace-kernel@...r.kernel.org>,
	<graf@...zon.de>, <dwmw2@...radead.org>, <pdurrant@...zon.com>,
	<mlevitsk@...hat.com>, <jgowans@...zon.com>, <corbet@....net>,
	<decui@...rosoft.com>, <tglx@...utronix.de>, <mingo@...hat.com>,
	<bp@...en8.de>, <dave.hansen@...ux.intel.com>, <x86@...nel.org>,
	<amoorthy@...gle.com>
Subject: Re: [PATCH 16/18] KVM: x86: Take mem attributes into account when
 faulting memory

On Sun Jun 9, 2024 at 3:49 PM UTC, Nicolas Saenz Julienne wrote:
> Take into account access restrictions memory attributes when faulting
> guest memory. Prohibited memory accesses will cause an user-space fault
> exit.
>
> Additionally, bypass a warning in the !tdp case. Access restrictions in
> guest page tables might not necessarily match the host pte's when memory
> attributes are in use.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenz@...zon.com>

I now realize that only taking into account memory attributes during
faults isn't good enough for VSM. We should check the attributes anytime
KVM takes GPAs as input for any action initiated by the guest. If the
memory attributes are incompatible with such action, it should be
stopped. Failure to do so opens side channels that unprivileged VTLs can
abuse to infer information about privileged VTL. Some examples I came up
with:
- Guest page walks: VTL0 could install malicious directory entries that
  point to GPAs only visible to VTL1. KVM will happily continue the
  walk. Among other things, this could be use to infer VTL1's GVA->GPA
  mappings.
- PV interfaces like the Hyper-V TSC page or VP assist page, could be
  used to modify portions of VTL1 memory.
- Hyper-V hypercalls that take GPAs as input/output can be abused in a
  myriad of ways. Including ones that exit into user-space.

We would be protected against all these if we implemented the memory
access restrictions through the memory slots API. As is, it has the
drawback of having to quiesce the whole VM for any non-trivial slot
modification (i.e. VSM's memory protections). But if we found a way to
speed up the slot updates we could rely on that, and avoid having to
teach kvm_read/write_guest() and friends to deal with memattrs. Note
that we would still need to use memory attributes to request for faults
to exit onto user-space on those select GPAs. Any opinions or
suggestions?

Note that, for now, I'll stick with the memory attributes approach to
see what the full solution looks like.

Nicolas