linux-kernel - Re: [PATCH v8 00/26] Enable CET Virtualization

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]

Date: Fri, 5 Jan 2024 00:34:08 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "Gao, Chao" <chao.gao@...el.com>, "Yang, Weijiang"
	<weijiang.yang@...el.com>, "Hansen, Dave" <dave.hansen@...el.com>,
	"peterz@...radead.org" <peterz@...radead.org>, "john.allen@....com"
	<john.allen@....com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "mlevitsk@...hat.com"
	<mlevitsk@...hat.com>
Subject: Re: [PATCH v8 00/26] Enable CET Virtualization

On Thu, 2024-01-04 at 16:22 -0800, Sean Christopherson wrote:
> No, the days of KVM making shit up from are done.  IIUC, you're
> advocating that
> it's ok for KVM to induce a #CP that architecturally should not
> happen.  That is
> not acceptable, full stop.

Nope, not advocating that at all. I'm noticing that in this series KVM
has special emulator behavior that doesn't match the HW when CET is
enabled. That it *skips* emitting #CPs (and other CET behaviors SW
depends on), and wondering if it is a problem.

I'm worried that there is some way attackers will induce the host to
emulate an instruction and skip CET enforcement that the HW would
normally do.

> 
> Retrying the instruction in the guest, exiting to userspace, and even
> terminating
> the VM are all perfectly acceptable behaviors if KVM encounters
> something it can't
> *correctly* emulate.  But clobbering the shadow stack or not
> detecting a CFI
> violation, even if the guest is misbehaving, is not ok.
> 
[snip]
> Yeah, I don't even know what the TRACKER bit does (I don't feel like
> reading the
> SDM right now), let alone if what KVM does or doesn't do in response
> is remotely
> correct.
> 
> For CALL/RET (and presumably any branch instructions with IBT?) other
> instructions
> that are directly affected by CET, the simplest thing would probably
> be to disable
> those in KVM's emulator if shadow stacks and/or IBT are enabled, and
> let KVM's
> failure paths take it from there.

Right, that is what I was wondering might be the normal solution for
situations like this.

> 
> Then, *if* a use case comes along where the guest is utilizing CET
> and "needs"
> KVM to emulate affected instructions, we can add the necessary
> support the emulator.
> 
> Alternatively, if teaching KVM's emulator to play nice with shadow
> stacks and IBT
> is easy-ish, just do that.

I think it will not be very easy.