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?
My full kernel-config is attached.
Thanks in advance.
Best regards, -Sedat-
https://xenbits.xen.org/xsa/advisory-466.html https://www.phoronix.com/news/Xen-XSA-466-Linux https://mirrors.edge.kernel.org/pub/tools/llvm/files/
On Thu, Dec 19, 2024 at 05:14:28PM +0100, 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.
WHat is the error that you get?
...when someone uses Clang-kCFI?
My full kernel-config is attached.
You don't show the error, please do so.
thanks,
greg k-h
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
On Thu, Dec 19, 2024 at 5:44 PM Andrew Cooper andrew.cooper3@citrix.com 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 RETThere 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.
Best regards, -Sedat-
On Thu, Dec 19, 2024 at 6:07 PM Sedat Dilek sedat.dilek@gmail.com wrote:
On Thu, Dec 19, 2024 at 5:44 PM Andrew Cooper andrew.cooper3@citrix.com 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 RETThere 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.
Thanks.
Best regards, -Sedat-
On 19/12/2024 11:10 pm, Sedat Dilek wrote:
On Thu, Dec 19, 2024 at 6:07 PM Sedat Dilek sedat.dilek@gmail.com wrote:
On Thu, Dec 19, 2024 at 5:44 PM Andrew Cooper andrew.cooper3@citrix.com 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 RETThere 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/%C2%A0 (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
On Fri, Dec 20, 2024 at 12:26 AM Andrew Cooper andrew.cooper3@citrix.com wrote:
On 19/12/2024 11:10 pm, Sedat Dilek wrote:
On Thu, Dec 19, 2024 at 6:07 PM Sedat Dilek sedat.dilek@gmail.com wrote:
On Thu, Dec 19, 2024 at 5:44 PM Andrew Cooper andrew.cooper3@citrix.com 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 RETThere 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?
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?
Thanks.
BR, -Sedat-
On 20/12/2024 12:27 am, Sedat Dilek wrote:
On Fri, Dec 20, 2024 at 12:26 AM Andrew Cooper andrew.cooper3@citrix.com wrote:
On 19/12/2024 11:10 pm, Sedat Dilek wrote:
On Thu, Dec 19, 2024 at 6:07 PM Sedat Dilek sedat.dilek@gmail.com wrote:
On Thu, Dec 19, 2024 at 5:44 PM Andrew Cooper andrew.cooper3@citrix.com 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 RETThere 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
On Fri, Dec 20, 2024 at 2:39 AM Andrew Cooper andrew.cooper3@citrix.com wrote:
On 20/12/2024 12:27 am, Sedat Dilek wrote:
On Fri, Dec 20, 2024 at 12:26 AM Andrew Cooper andrew.cooper3@citrix.com wrote:
On 19/12/2024 11:10 pm, Sedat Dilek wrote:
On Thu, Dec 19, 2024 at 6:07 PM Sedat Dilek sedat.dilek@gmail.com wrote:
On Thu, Dec 19, 2024 at 5:44 PM Andrew Cooper andrew.cooper3@citrix.com 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 RETThere 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
RUN example tests on Debian's 6.12.6 kernel.
$ cat /proc/version Linux version 6.12.6-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-11) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.50.20241215) #1 SMP PREEMPT_DYNAMIC Debian 6.12.6-1 (2024-12-21)
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --list example test-hvm32-example test-hvm32pae-example test-hvm32pse-example test-hvm64-example test-pv32pae-example test-pv64-example dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-hvm32-example Executing 'xl create -p tests/example/test-hvm32-example.cfg' Executing 'xl console test-hvm32-example' Executing 'xl unpause test-hvm32-example' --- Xen Test Framework --- Environment: HVM 32bit (No paging) Hello World Test result: SUCCESS
Combined test results: test-hvm32-example SUCCESS dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-hvm32pae-example Executing 'xl create -p tests/example/test-hvm32pae-example.cfg' Executing 'xl console test-hvm32pae-example' Executing 'xl unpause test-hvm32pae-example' --- Xen Test Framework --- Environment: HVM 32bit (PAE 3 levels) Hello World Test result: SUCCESS
Combined test results: test-hvm32pae-example SUCCESS dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-hvm32pse-example Executing 'xl create -p tests/example/test-hvm32pse-example.cfg' Executing 'xl console test-hvm32pse-example' Executing 'xl unpause test-hvm32pse-example' --- Xen Test Framework --- Environment: HVM 32bit (PSE 2 levels) Hello World Test result: SUCCESS
Combined test results: test-hvm32pse-example SUCCESS dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-hvm64-example Executing 'xl create -p tests/example/test-hvm64-example.cfg' Executing 'xl console test-hvm64-example' Executing 'xl unpause test-hvm64-example' --- Xen Test Framework --- Environment: HVM 64bit (Long mode 4 levels) Hello World Test result: SUCCESS
Combined test results: test-hvm64-example SUCCESS dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-pv32pae-example Combined test results: test-pv32pae-example SKIP dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner test-pv64-example Executing 'xl create -p tests/example/test-pv64-example.cfg' Executing 'xl console test-pv64-example' Executing 'xl unpause test-pv64-example' --- Xen Test Framework --- Environment: PV 64bit (Long mode 4 levels) Hello World Test result: SUCCESS
Combined test results: test-pv64-example SUCCESS
Thanks.
Best regards, -Sedat-
On Fri, Dec 20, 2024 at 2:39 AM Andrew Cooper andrew.cooper3@citrix.com wrote:
On 20/12/2024 12:27 am, Sedat Dilek wrote:
On Fri, Dec 20, 2024 at 12:26 AM Andrew Cooper andrew.cooper3@citrix.com wrote:
On 19/12/2024 11:10 pm, Sedat Dilek wrote:
On Thu, Dec 19, 2024 at 6:07 PM Sedat Dilek sedat.dilek@gmail.com wrote:
On Thu, Dec 19, 2024 at 5:44 PM Andrew Cooper andrew.cooper3@citrix.com 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 RETThere 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.
YES
# xl info | grep xen_commandline xen_commandline : placeholder vga=,keep noreboot
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
On Debian 6.12.6 kernel the TESTS stop with test-hvm64-xsa-454 - machine freezes - hard reboot.
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner -a --host
root@iniza:/var/log/xen# LC_ALL=C ls -alth | head -20 total 1.7M -rw-r--r-- 1 root adm 1008K Dec 21 19:10 xenstored-access.log drwxr-xr-x 16 root root 4.0K Dec 21 18:59 .. -rw-r--r-- 1 root adm 32 Dec 21 18:58 xenstored.log drwxr-s--- 2 root adm 36K Dec 21 18:58 . -rw-r--r-- 1 root adm 229 Dec 21 18:53 xl-test-hvm64-xsa-317.log -rw-r--r-- 1 root adm 67 Dec 21 18:53 xl-test-hvm64-xsa-454.log -rw-r--r-- 1 root adm 145 Dec 21 18:53 qemu-dm-test-hvm64-xsa-454.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 qemu-dm-test-hvm64-xsa-451.log -rw-r--r-- 1 root adm 211 Dec 21 18:53 xl-test-hvm64-xsa-451.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 xl-test-hvm32pse-xsa-317.log -rw-r--r-- 1 root adm 228 Dec 21 18:53 xl-test-pv64-xsa-444.log -rw-r--r-- 1 root adm 228 Dec 21 18:53 xl-test-pv64-xsa-339.log -rw-r--r-- 1 root adm 228 Dec 21 18:53 xl-test-pv64-xsa-333.log -rw-r--r-- 1 root adm 228 Dec 21 18:53 xl-test-pv64-xsa-317.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 qemu-dm-test-hvm64-xsa-317.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 xl-test-hvm32pae-xsa-317.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 qemu-dm-test-hvm32pse-xsa-317.log -rw-r--r-- 1 root adm 229 Dec 21 18:53 xl-test-hvm32-xsa-317.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 qemu-dm-test-hvm32pae-xsa-317.log
root@iniza:/var/log/xen# cat qemu-dm-test-hvm64-xsa-454.log VNC server running on 127.0.0.1:5900 xen-qemu-system-i386: failed to create 'console' device '0': declining to handle console type 'xenconsoled'
root@iniza:/var/log/xen# cat xl-test-hvm64-xsa-454.log Waiting for domain test-hvm64-xsa-454 (domid 94) to die [pid 4686]
-Sedat-
On Sat, Dec 21, 2024 at 7:17 PM Sedat Dilek sedat.dilek@gmail.com wrote:
On Fri, Dec 20, 2024 at 2:39 AM Andrew Cooper andrew.cooper3@citrix.com wrote:
On 20/12/2024 12:27 am, Sedat Dilek wrote:
On Fri, Dec 20, 2024 at 12:26 AM Andrew Cooper andrew.cooper3@citrix.com wrote:
On 19/12/2024 11:10 pm, Sedat Dilek wrote:
On Thu, Dec 19, 2024 at 6:07 PM Sedat Dilek sedat.dilek@gmail.com wrote:
On Thu, Dec 19, 2024 at 5:44 PM Andrew Cooper andrew.cooper3@citrix.com 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.
YES
# xl info | grep xen_commandline xen_commandline : placeholder vga=,keep noreboot
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
On Debian 6.12.6 kernel the TESTS stop with test-hvm64-xsa-454 - machine freezes - hard reboot.
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner -a --host
root@iniza:/var/log/xen# LC_ALL=C ls -alth | head -20 total 1.7M -rw-r--r-- 1 root adm 1008K Dec 21 19:10 xenstored-access.log drwxr-xr-x 16 root root 4.0K Dec 21 18:59 .. -rw-r--r-- 1 root adm 32 Dec 21 18:58 xenstored.log drwxr-s--- 2 root adm 36K Dec 21 18:58 . -rw-r--r-- 1 root adm 229 Dec 21 18:53 xl-test-hvm64-xsa-317.log -rw-r--r-- 1 root adm 67 Dec 21 18:53 xl-test-hvm64-xsa-454.log -rw-r--r-- 1 root adm 145 Dec 21 18:53 qemu-dm-test-hvm64-xsa-454.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 qemu-dm-test-hvm64-xsa-451.log -rw-r--r-- 1 root adm 211 Dec 21 18:53 xl-test-hvm64-xsa-451.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 xl-test-hvm32pse-xsa-317.log -rw-r--r-- 1 root adm 228 Dec 21 18:53 xl-test-pv64-xsa-444.log -rw-r--r-- 1 root adm 228 Dec 21 18:53 xl-test-pv64-xsa-339.log -rw-r--r-- 1 root adm 228 Dec 21 18:53 xl-test-pv64-xsa-333.log -rw-r--r-- 1 root adm 228 Dec 21 18:53 xl-test-pv64-xsa-317.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 qemu-dm-test-hvm64-xsa-317.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 xl-test-hvm32pae-xsa-317.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 qemu-dm-test-hvm32pse-xsa-317.log -rw-r--r-- 1 root adm 229 Dec 21 18:53 xl-test-hvm32-xsa-317.log -rw-r--r-- 1 root adm 232 Dec 21 18:53 qemu-dm-test-hvm32pae-xsa-317.log
root@iniza:/var/log/xen# cat qemu-dm-test-hvm64-xsa-454.log VNC server running on 127.0.0.1:5900 xen-qemu-system-i386: failed to create 'console' device '0': declining to handle console type 'xenconsoled'
root@iniza:/var/log/xen# cat xl-test-hvm64-xsa-454.log Waiting for domain test-hvm64-xsa-454 (domid 94) to die [pid 4686]
-Sedat-
With...
dileks@iniza:~/src/xtf/git$ mv tests/xsa-454 ../ dileks@iniza:~/src/xtf/git$ mv tests/xsa-consoleio-write ../
Combined test results: test-hvm32-cpuid-faulting SKIP test-hvm32pae-cpuid-faulting SKIP test-hvm32pse-cpuid-faulting SKIP test-hvm64-cpuid-faulting SKIP test-pv64-cpuid-faulting SKIP test-hvm64-fpu-exception-emulation SKIP test-hvm32-invlpg~hap SUCCESS test-hvm32-invlpg~shadow SUCCESS test-hvm32pae-invlpg~hap SUCCESS test-hvm32pae-invlpg~shadow SUCCESS test-hvm64-invlpg~hap SUCCESS test-hvm64-invlpg~shadow SUCCESS test-hvm64-lbr-tsx-vmentry SUCCESS test-hvm32-livepatch-priv-check SUCCESS test-hvm64-livepatch-priv-check SUCCESS test-pv64-livepatch-priv-check SUCCESS test-hvm32-lm-ts SUCCESS test-hvm64-lm-ts SUCCESS test-hvm32pae-memop-seg SUCCESS test-hvm64-memop-seg SUCCESS test-pv64-memop-seg SUCCESS test-hvm32pae-nmi-taskswitch-priv SUCCESS test-pv64-pv-fsgsbase SKIP test-pv64-pv-iopl~hypercall SUCCESS test-pv64-pv-iopl~vmassist SUCCESS test-hvm32-swint-emulation SKIP test-hvm32pae-swint-emulation SKIP test-hvm32pse-swint-emulation SKIP test-hvm64-swint-emulation SKIP test-hvm32-umip SKIP test-hvm64-umip SKIP test-hvm32-xsa-122 SUCCESS test-hvm32pae-xsa-122 SUCCESS test-hvm32pse-xsa-122 SUCCESS test-hvm64-xsa-122 SUCCESS test-pv64-xsa-122 SUCCESS test-hvm32-xsa-123 SKIP test-pv64-xsa-167 SKIP test-hvm64-xsa-168~shadow SUCCESS test-hvm64-xsa-170 SKIP test-hvm64-xsa-173~shadow SUCCESS test-pv64-xsa-182 SUCCESS test-hvm32-xsa-186 SKIP test-hvm64-xsa-186 SKIP test-hvm32-xsa-188 SUCCESS test-hvm32pae-xsa-188 SUCCESS test-hvm32pse-xsa-188 SUCCESS test-hvm64-xsa-188 SUCCESS test-pv64-xsa-188 SUCCESS test-hvm32-xsa-191 SKIP test-hvm32-xsa-192 SUCCESS test-pv64-xsa-193 SUCCESS test-hvm64-xsa-195 SUCCESS test-hvm64-xsa-196 SKIP test-hvm32-xsa-200 SKIP test-hvm32-xsa-203 SKIP test-hvm64-xsa-204 SKIP test-pv64-xsa-212 SUCCESS test-pv64-xsa-213 SUCCESS test-hvm64-xsa-221 SUCCESS test-pv64-xsa-221 SUCCESS test-pv64-xsa-224 SUCCESS test-pv64-xsa-227 SUCCESS test-hvm64-xsa-231 SUCCESS test-pv64-xsa-231 SUCCESS test-hvm64-xsa-232 SUCCESS test-pv64-xsa-232 SUCCESS test-pv64-xsa-234 SUCCESS test-hvm32-xsa-239 SUCCESS test-pv64-xsa-255 SUCCESS test-pv64-xsa-259 SUCCESS test-pv64-xsa-260 SUCCESS test-hvm64-xsa-261 SUCCESS test-pv64-xsa-265 SUCCESS test-hvm64-xsa-269 SUCCESS test-hvm64-xsa-277 SUCCESS test-hvm64-xsa-278 SUCCESS test-pv64-xsa-279 SUCCESS test-pv64-xsa-286 SUCCESS test-pv64-xsa-296 SUCCESS test-pv64-xsa-298 SUCCESS test-hvm64-xsa-304 SUCCESS test-hvm64-xsa-308 SUCCESS test-pv64-xsa-316 SUCCESS test-hvm32-xsa-317 SUCCESS test-hvm32pae-xsa-317 SUCCESS test-hvm32pse-xsa-317 SUCCESS test-hvm64-xsa-317 SUCCESS test-pv64-xsa-317 SUCCESS test-pv64-xsa-333 SUCCESS test-pv64-xsa-339 SUCCESS test-pv64-xsa-444 SKIP test-hvm64-xsa-451 SKIP
-Sedat-
Run all SUCCESS tests on my selfmade kernel.
# xl info | egrep 'release|version|commandline|caps' release : 6.12.6-1-amd64-clang19-kcfi version : #1~trixie+dileks SMP PREEMPT_DYNAMIC 2024-12-19 hw_caps : bfebfbff:17bae3bf:28100800:00000001:00000001:00000000:00000000:00000100 virt_caps : pv hvm hap shadow gnttab-v1 gnttab-v2 xen_version : 4.17.4-pre xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_commandline : placeholder vga=,keep noreboot
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --host $( grep SUCCESS ../TESTS-SUCCESS | awk '{ print $1 }' ) ... Combined test results: test-hvm32-invlpg~hap SUCCESS test-hvm32-invlpg~shadow SUCCESS test-hvm32pae-invlpg~hap SUCCESS test-hvm32pae-invlpg~shadow SUCCESS test-hvm64-invlpg~hap SUCCESS test-hvm64-invlpg~shadow SUCCESS test-hvm64-lbr-tsx-vmentry SUCCESS test-hvm32-livepatch-priv-check SUCCESS test-hvm64-livepatch-priv-check SUCCESS test-pv64-livepatch-priv-check SUCCESS test-hvm32-lm-ts SUCCESS test-hvm64-lm-ts SUCCESS test-hvm32pae-memop-seg SUCCESS test-hvm64-memop-seg SUCCESS test-pv64-memop-seg SUCCESS test-hvm32pae-nmi-taskswitch-priv SUCCESS test-pv64-pv-iopl~hypercall SUCCESS test-pv64-pv-iopl~vmassist SUCCESS test-hvm32-xsa-122 SUCCESS test-hvm32pae-xsa-122 SUCCESS test-hvm32pse-xsa-122 SUCCESS test-hvm64-xsa-122 SUCCESS test-pv64-xsa-122 SUCCESS test-hvm64-xsa-168~shadow SUCCESS test-hvm64-xsa-173~shadow SUCCESS test-pv64-xsa-182 SUCCESS test-hvm32-xsa-188 SUCCESS test-hvm32pae-xsa-188 SUCCESS test-hvm32pse-xsa-188 SUCCESS test-hvm64-xsa-188 SUCCESS test-pv64-xsa-188 SUCCESS test-hvm32-xsa-192 SUCCESS test-pv64-xsa-193 SUCCESS test-hvm64-xsa-195 SUCCESS test-pv64-xsa-212 SUCCESS test-pv64-xsa-213 SUCCESS test-hvm64-xsa-221 SUCCESS test-pv64-xsa-221 SUCCESS test-pv64-xsa-224 SUCCESS test-pv64-xsa-227 SUCCESS test-hvm64-xsa-231 SUCCESS test-pv64-xsa-231 SUCCESS test-hvm64-xsa-232 SUCCESS test-pv64-xsa-232 SUCCESS test-pv64-xsa-234 SUCCESS test-hvm32-xsa-239 SUCCESS test-pv64-xsa-255 SUCCESS test-pv64-xsa-259 SUCCESS test-pv64-xsa-260 SUCCESS test-hvm64-xsa-261 SUCCESS test-pv64-xsa-265 SUCCESS test-hvm64-xsa-269 SUCCESS test-hvm64-xsa-277 SUCCESS test-hvm64-xsa-278 SUCCESS test-pv64-xsa-279 SUCCESS test-pv64-xsa-286 SUCCESS test-pv64-xsa-296 SUCCESS test-pv64-xsa-298 SUCCESS test-hvm64-xsa-304 SUCCESS test-hvm64-xsa-308 SUCCESS test-pv64-xsa-316 SUCCESS test-hvm32-xsa-317 SUCCESS test-hvm32pae-xsa-317 SUCCESS test-hvm32pse-xsa-317 SUCCESS test-hvm64-xsa-317 SUCCESS test-pv64-xsa-317 SUCCESS test-pv64-xsa-333 SUCCESS test-pv64-xsa-339 SUCCESS
No CFI related stuff in dmesg seen after running XFT tests.
Best regards, -Sedat-
On 21/12/2024 6:25 pm, Sedat Dilek wrote:
With...
dileks@iniza:~/src/xtf/git$ mv tests/xsa-454 ../ dileks@iniza:~/src/xtf/git$ mv tests/xsa-consoleio-write ../
That's completely bizzare. There's nothing interestingly different with those two tests vs the others.
I take it the crash is repeatable when using either of these?
~Andrew
On Sat, Dec 21, 2024 at 10:31 PM Andrew Cooper andrew.cooper3@citrix.com wrote:
On 21/12/2024 6:25 pm, Sedat Dilek wrote:
With...
dileks@iniza:~/src/xtf/git$ mv tests/xsa-454 ../ dileks@iniza:~/src/xtf/git$ mv tests/xsa-consoleio-write ../
That's completely bizzare. There's nothing interestingly different with those two tests vs the others.
I take it the crash is repeatable when using either of these?
~Andrew
This time I stopped SDDM and thus KDE-6/Wayland session.
Tested with Debian's officially 6.12.6-amd64 kernel in VT-3.
test-hvm32pae-xsa-consoleio-write SUCCESS <--- 1st time I tried, never said this is not OK
test-hvm64-xsa-454 leads to FROZEN system and DATA LOSS (here: ext4). Reproducibly as told many times.- in Debian and selfmade kernels version 6.12.6.
Stolen from the picture I took with my smartphone:
sudo ./xft-runner test-hvm64-xsa-454
Executing 'xl create -p tests/xsa-454/test-hvm64-xsa-454.cfg' Executing 'xl console test-hvm64-xsa-454' Executing 'xl unpause test-hvm64-xsa-454'
^^ System does NOT react!
I can send you the picture on request.
-Sedat-
On Sun, Dec 22, 2024 at 11:37 AM Sedat Dilek sedat.dilek@gmail.com wrote:
On Sat, Dec 21, 2024 at 10:31 PM Andrew Cooper andrew.cooper3@citrix.com wrote:
On 21/12/2024 6:25 pm, Sedat Dilek wrote:
With...
dileks@iniza:~/src/xtf/git$ mv tests/xsa-454 ../ dileks@iniza:~/src/xtf/git$ mv tests/xsa-consoleio-write ../
That's completely bizzare. There's nothing interestingly different with those two tests vs the others.
I take it the crash is repeatable when using either of these?
~Andrew
This time I stopped SDDM and thus KDE-6/Wayland session.
Tested with Debian's officially 6.12.6-amd64 kernel in VT-3.
test-hvm32pae-xsa-consoleio-write SUCCESS <--- 1st time I tried, never said this is not OK
test-hvm64-xsa-454 leads to FROZEN system and DATA LOSS (here: ext4). Reproducibly as told many times.- in Debian and selfmade kernels version 6.12.6.
Stolen from the picture I took with my smartphone:
sudo ./xft-runner test-hvm64-xsa-454
Executing 'xl create -p tests/xsa-454/test-hvm64-xsa-454.cfg' Executing 'xl console test-hvm64-xsa-454' Executing 'xl unpause test-hvm64-xsa-454'
^^ System does NOT react!
I can send you the picture on request.
-Sedat-
[ CC 1091360@bugs.debian.org ]
I upgraded to Xen version 4.19.1 in Debian/unstable AMD64.
# xl info | egrep 'release|version|commandline|caps' release : 6.12.6-amd64 version : #1 SMP PREEMPT_DYNAMIC Debian 6.12.6-1 (2024-12-21) hw_caps : bfebfbff:17bae3bf:28100800:00000001:00000001:00000000:00000000:00000100 virt_caps : pv hvm hap shadow gnttab-v1 gnttab-v2 xen_version : 4.19.1 xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_commandline : placeholder
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --host test-hvm64-xsa-454 Executing 'xl create -p tests/xsa-454/test-hvm64-xsa-454.cfg' Executing 'xl console test-hvm64-xsa-454' Executing 'xl unpause test-hvm64-xsa-454' --- Xen Test Framework --- Environment: HVM 64bit (Long mode 4 levels) XSA-454 PoC Success: Not vulnerable to XSA-454 Test result: SUCCESS
Combined test results: test-hvm64-xsa-454 SUCCESS
root@iniza:~# LC_ALL=C ll /var/log/xen/*xsa-454*.log -rw-r--r-- 1 root adm 232 Dec 24 17:11 /var/log/xen/qemu-dm-test-hvm64-xsa-454.log -rw-r--r-- 1 root adm 232 Dec 24 17:11 /var/log/xen/xl-test-hvm64-xsa-454.log
root@iniza:~# cat /var/log/xen/qemu-dm-test-hvm64-xsa-454.log VNC server running on 127.0.0.1:5900 xen-qemu-system-i386: failed to create 'console' device '0': declining to handle console type 'xenconsoled' xen-qemu-system-i386: terminating on signal 1 from pid 6302 (/usr/lib/xen-4.19/bin/xl)
root@iniza:~# cat /var/log/xen/xl-test-hvm64-xsa-454.log Waiting for domain test-hvm64-xsa-454 (domid 144) to die [pid 6302] Domain 144 has shut down, reason code 0 0x0 Action for shutdown reason code 0 is destroy Domain 144 needs to be cleaned up: destroying the domain Done. Exiting now
Due to Debian-Bug #1091360 ("qemu-system-xen: Build against libxen-dev version 4.19.1-1") I am not able to do the full XFT tests.
-Sedat-
On Tue, Dec 24, 2024 at 5:23 PM Sedat Dilek sedat.dilek@gmail.com wrote:
On Sun, Dec 22, 2024 at 11:37 AM Sedat Dilek sedat.dilek@gmail.com wrote:
On Sat, Dec 21, 2024 at 10:31 PM Andrew Cooper andrew.cooper3@citrix.com wrote:
On 21/12/2024 6:25 pm, Sedat Dilek wrote:
With...
dileks@iniza:~/src/xtf/git$ mv tests/xsa-454 ../ dileks@iniza:~/src/xtf/git$ mv tests/xsa-consoleio-write ../
That's completely bizzare. There's nothing interestingly different with those two tests vs the others.
I take it the crash is repeatable when using either of these?
~Andrew
This time I stopped SDDM and thus KDE-6/Wayland session.
Tested with Debian's officially 6.12.6-amd64 kernel in VT-3.
test-hvm32pae-xsa-consoleio-write SUCCESS <--- 1st time I tried, never said this is not OK
test-hvm64-xsa-454 leads to FROZEN system and DATA LOSS (here: ext4). Reproducibly as told many times.- in Debian and selfmade kernels version 6.12.6.
Stolen from the picture I took with my smartphone:
sudo ./xft-runner test-hvm64-xsa-454
Executing 'xl create -p tests/xsa-454/test-hvm64-xsa-454.cfg' Executing 'xl console test-hvm64-xsa-454' Executing 'xl unpause test-hvm64-xsa-454'
^^ System does NOT react!
I can send you the picture on request.
-Sedat-
[ CC 1091360@bugs.debian.org ]
I upgraded to Xen version 4.19.1 in Debian/unstable AMD64.
# xl info | egrep 'release|version|commandline|caps' release : 6.12.6-amd64 version : #1 SMP PREEMPT_DYNAMIC Debian 6.12.6-1 (2024-12-21) hw_caps : bfebfbff:17bae3bf:28100800:00000001:00000001:00000000:00000000:00000100 virt_caps : pv hvm hap shadow gnttab-v1 gnttab-v2 xen_version : 4.19.1 xen_caps : xen-3.0-x86_64 hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_commandline : placeholder
dileks@iniza:~/src/xtf/git$ sudo ./xtf-runner --host test-hvm64-xsa-454 Executing 'xl create -p tests/xsa-454/test-hvm64-xsa-454.cfg' Executing 'xl console test-hvm64-xsa-454' Executing 'xl unpause test-hvm64-xsa-454' --- Xen Test Framework --- Environment: HVM 64bit (Long mode 4 levels) XSA-454 PoC Success: Not vulnerable to XSA-454 Test result: SUCCESS
Combined test results: test-hvm64-xsa-454 SUCCESS
root@iniza:~# LC_ALL=C ll /var/log/xen/*xsa-454*.log -rw-r--r-- 1 root adm 232 Dec 24 17:11 /var/log/xen/qemu-dm-test-hvm64-xsa-454.log -rw-r--r-- 1 root adm 232 Dec 24 17:11 /var/log/xen/xl-test-hvm64-xsa-454.log
root@iniza:~# cat /var/log/xen/qemu-dm-test-hvm64-xsa-454.log VNC server running on 127.0.0.1:5900 xen-qemu-system-i386: failed to create 'console' device '0': declining to handle console type 'xenconsoled' xen-qemu-system-i386: terminating on signal 1 from pid 6302 (/usr/lib/xen-4.19/bin/xl)
root@iniza:~# cat /var/log/xen/xl-test-hvm64-xsa-454.log Waiting for domain test-hvm64-xsa-454 (domid 144) to die [pid 6302] Domain 144 has shut down, reason code 0 0x0 Action for shutdown reason code 0 is destroy Domain 144 needs to be cleaned up: destroying the domain Done. Exiting now
Due to Debian-Bug #1091360 ("qemu-system-xen: Build against libxen-dev version 4.19.1-1") I am not able to do the full XFT tests.
-Sedat-
With NEW qemu-system-xen/unstable (1:9.2.0+ds-3) both 6.12.6 kernel - Debian and selfmade run with SUCCESS.
Nothing scary in dmesg-log.
Happy XMAS, -Sedat-
linux-stable-mirror@lists.linaro.org
-
Andrew Cooper -
Greg Kroah-Hartman -
Sedat Dilek