[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <099d3a80-4fdb-49a7-9fd0-207d7386551f@citrix.com>
Date: Thu, 19 Dec 2024 16:44:10 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: sedat.dilek@...il.com, Juergen Gross <jgross@...e.com>,
Peter Zijlstra <peterz@...radead.org>,
Sami Tolvanen <samitolvanen@...gle.com>
Cc: Jan Beulich <jbeulich@...e.com>, Josh Poimboeuf <jpoimboe@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Sasha Levin <sashal@...nel.org>, linux-kernel@...r.kernel.org,
stable@...r.kernel.org, Kees Cook <kees@...nel.org>,
Nathan Chancellor <nathan@...nel.org>, llvm@...ts.linux.dev
Subject: Re: [Linux-6.12.y] XEN: CVE-2024-53241 / XSA-466 and Clang-kCFI
On 19/12/2024 4:14 pm, Sedat Dilek wrote:
> Hi,
>
> Linux v6.12.6 will include XEN CVE fixes from mainline.
>
> Here, I use Debian/unstable AMD64 and the SLIM LLVM toolchain 19.1.x
> from kernel.org.
>
> What does it mean in ISSUE DESCRIPTION...
>
> Furthermore, the hypercall page has no provision for Control-flow
> Integrity schemes (e.g. kCFI/CET-IBT/FineIBT), and will simply
> malfunction in such configurations.
>
> ...when someone uses Clang-kCFI?
The hypercall page has functions of the form:
MOV $x, %eax
VMCALL / VMMCALL / SYSCALL
RET
There are no ENDBR instructions, and no prologue/epilogue for hash-based
CFI schemes.
This is because it's code provided by Xen, not code provided by Linux.
The absence of ENDBR instructions will yield #CP when CET-IBT is active,
and the absence of hash prologue/epilogue lets the function be used in a
type-confused manor that CFI should have caught.
~Andrew
Powered by blists - more mailing lists