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
