Re: [Linux-6.12.y] XEN: CVE-2024-53241 / XSA-466 and Clang-kCFI

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 20/12/2024 12:27 am, Sedat Dilek wrote:
> On Fri, Dec 20, 2024 at 12:26 AM Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 19/12/2024 11:10 pm, Sedat Dilek wrote:
>>> On Thu, Dec 19, 2024 at 6:07 PM Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
>>>> On Thu, Dec 19, 2024 at 5:44 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
>>>> wrote:
>>>>> 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
>>>> Thanks for the technical explanation, Andrew.
>>>>
>>>> Hope that helps the folks of "CLANG CONTROL FLOW INTEGRITY SUPPORT".
>>>>
>>>> I am not an active user of XEN in the Linux-kernel but I am willing to
>>>> test when Linux v6.12.6 is officially released and give feedback.
>>>>
>>> https://wiki.xenproject.org/wiki/Testing_Xen#Presence_test
>>> https://wiki.xenproject.org/wiki/Testing_Xen#Commands_for_presence_testing
>>>
>>> # apt install -t unstable xen-utils-4.17 -y
>>>
>>> # xl list
>>> Name                                        ID   Mem VCPUs      State   
>>> Time(s)
>>> Domain-0                                     0  7872     4     r-----     
>>> 398.2
>>>
>>> Some basic tests LGTM - see also attached stuff.
>>>
>>> If you have any tests to recommend, let me know.
>> That itself is good enough as a smoke test.  Thankyou for trying it out.
>>
>> If you want something a bit more thorough, try
>> https://xenbits.xen.org/docs/xtf/  (Xen's self-tests)
>>
>> Grab and build it, and `./xtf-runner -aqq --host` will run a variety of
>> extra codepaths in dom0, without the effort of making/running full guests.
>>
>> ~Andrew
> Run on Debian 6.12.5 and my selfmade 6.12.5 and 6.12.6.
> All tests lead to a reboot in case of Debian or in my kernels to a shutdown.
>
> Can you recommend a specific test?

Oh, that's distinctly less good.

Start with just "example".  It's literally a hello world microkernel,
but the symptoms you're seeing is a dom0 crash, so it will likely
provoke it.

Do you have serial to the machine?  If so, boot Xen with `console=com1
com1=115200,8n1` (or com2, as appropriate).

If not and you've only got a regular screen, boot Xen with `vga=,keep
noreboot` (comma is important) which might leave enough information on
screen to get an idea of what's going on.

Full command line docs at
https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

> dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --list functional xsa | grep 
> xsa-4
> test-pv64-xsa-444
> test-hvm64-xsa-451
> test-hvm64-xsa-454
>
> Is there no xsa-466 test?

No.  XSA-466 is really "well don't do that then if it matters".

More generally, not all XSAs are amenable to testing in this way.

~Andrew