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]

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

On Thu, 2023-12-21 at 09:02 -0500, Yang Weijiang wrote:
> Control-flow Enforcement Technology (CET) is a kind of CPU feature
> used
> to prevent Return/CALL/Jump-Oriented Programming (ROP/COP/JOP)
> attacks.
> It provides two sub-features(SHSTK,IBT) to defend against ROP/COP/JOP
> style control-flow subversion attacks.
> 
> Shadow Stack (SHSTK):
>   A shadow stack is a second stack used exclusively for control
> transfer
>   operations. The shadow stack is separate from the data/normal stack
> and
>   can be enabled individually in user and kernel mode. When shadow
> stack
>   is enabled, CALL pushes the return address on both the data and
> shadow
>   stack. RET pops the return address from both stacks and compares
> them.
>   If the return addresses from the two stacks do not match, the
> processor
>   generates a #CP.
> 
> Indirect Branch Tracking (IBT):
>   IBT introduces new instruction(ENDBRANCH)to mark valid target
> addresses of
>   indirect branches (CALL, JMP etc...). If an indirect branch is
> executed
>   and the next instruction is _not_ an ENDBRANCH, the processor
> generates a
>   #CP. These instruction behaves as a NOP on platforms that doesn't
> support
>   CET.

What is the design around CET and the KVM emulator?

My understanding is that the KVM emulator kind of does what it has to
keep things running, and isn't expected to emulate every possible
instruction. With CET though, it is changing the behavior of existing
supported instructions. I could imagine a guest could skip over CET
enforcement by causing an MMIO exit and racing to overwrite the exit-
causing instruction from a different vcpu to be an indirect CALL/RET,
etc. With reasonable assumptions around the threat model in use by the
guest this is probably not a huge problem. And I guess also reasonable
assumptions about functional expectations, as a misshandled CALL or RET
by the emulator would corrupt the shadow stack.

But, another thing to do could be to just return X86EMUL_UNHANDLEABLE
or X86EMUL_RETRY_INSTR when CET is active and RET or CALL are emulated.
And I guess also for all instructions if the TRACKER bit is set. It
might tie up that loose end without too much trouble.

Anyway, was there a conscious decision to just punt on CET enforcement
in the emulator?