[PATCH v4 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN)

[PATCH v4 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN)

[Mauricio Faria de Oliveira]

The issue of unbootable VMs with CONFIG_PVH due to CONFIG_KASAN is back.

Booting directly from vmlinux (instead of bzImage) now fails with gcc-14/15
(but works with gcc-12/13) if CONFIG_KASAN_GENERIC is set, on Ubuntu 25.10.

The PVH code is required/supposed not to use the KASAN memory access check
in the kernel entry point as KASAN has not yet been setup, or an exception
is hit and the boot fails.

This was previously described and addressed with __builtin_mem{cmp,set}():
- commit 661362e3dcab ("xen, pvh: fix unbootable VMs (PVH + KASAN - AMD_MEM_ENCRYPT)")
- commit 416a33c9afce ("x86/cpu: fix unbootable VMs by inlining memcmp() in hypervisor_cpuid_base()")
- commit fbe5a6dfe492 ("xen, pvh: fix unbootable VMs by inlining memset() in xen_prepare_pvh()")

However, even with __builtin the compiler may decide to use the out of line
function instead of the inline implementation. So, that does not really fix
the issue unconditionally; see details below.

In order to address this, it's required to switch to inline implementations
that do not depend on the compiler.

There's such a memset() in <asm/string.h> and memcmp() in 'boot/string.c'.
Use them instead of builtins in PVH entry.

Testing:

- Booting from vmlinux (fixed) and bzImage (still works) using
  allnoconfig + CONFIG_PVH + CONFIG_KASAN with gcc-12/13/14/15.

- Building with CONFIG_KEXEC_FILE, CONFIG_CFI and !CONFIG_KASAN with LLVM 20
  (check for a build error related to <asm/string.h>, not caught previously).

Details/Debugging:

- Only CONFIG_PVH (works):

  make allnoconfig
  ./scripts/config \
    -e 64BIT -e HYPERVISOR_GUEST -e PVH \
    -e SERIAL_8250 -e SERIAL_8250_CONSOLE
  make olddefconfig
  make -j$(nproc) vmlinux

  qemu-system-x86_64 \
    -accel kvm -nodefaults -nographic -serial stdio \
    -kernel vmlinux -append 'console=ttyS0'
  ...
  SeaBIOS (version ...)
  Booting from ROM...
  Linux version ...
  ...
  <Ctrl-C>

- With CONFIG_KASAN (fails)

  ./scripts/config -e KASAN
  make olddefconfig
  make -j$(nproc) vmlinux

  qemu-system-x86_64 \
    -accel kvm -nodefaults -nographic -serial stdio \
    -kernel vmlinux -append 'console=ttyS0'
  ...
  SeaBIOS (version ...)
  Booting from ROM...
  <QEMU reboot loop, flashing the text above>

- Debugging:

  Enable debug info and rebuild.

  QEMU: enable and wait for GDB, stop rebooting, remain running.

  qemu-system-x86_64 \
    -s -S -no-reboot -no-shutdown \
    <other options>

  gdb vmlinux
  (gdb) target remote localhost:1234
  ...
  (gdb) c
  ...
  Thread 2 received signal SIGQUIT, Quit.
  ...
  (gdb) info threads
    Id   Target Id                    Frame
    1    Thread 1.1 (CPU#0 [running]) bytes_is_nonzero (
      start=0xfffffbfff031eebe <error: Cannot access memory at address 0xfffffbfff031eebe>, size=1)
      at .../linux/mm/kasan/generic.c:98
  * 2    Thread 1.2 (CPU#1 [halted ]) 0x00000000000fd0a9 in ?? ()
  ...
  (gdb) thr 1
  ...
  (gdb) bt
  #0  bytes_is_nonzero (start=0xfffffbfff031eebe <error: Cannot access memory at address 0xfffffbfff031eebe>, size=1)
      at .../linux/mm/kasan/generic.c:98
  #1  memory_is_nonzero (start=0xfffffbfff031eebe, end=0xfffffbfff031eebf) at .../linux/mm/kasan/generic.c:115
  #2  memory_is_poisoned_n (addr=0xffffffff818f75f0, size=8) at .../linux/mm/kasan/generic.c:140
  #3  memory_is_poisoned (addr=0xffffffff818f75f0, size=8) at .../linux/mm/kasan/generic.c:172
  #4  check_region_inline (addr=0xffffffff818f75f0, size=8, write=false, ret_ip=18446744071585002062)
      at .../linux/mm/kasan/generic.c:191
  #5  kasan_check_range (addr=addr@entry=0xffffffff818f75f0, size=size@entry=8, write=write@entry=false,
      ret_ip=18446744071585002062) at .../linux/mm/kasan/generic.c:200
  #6  0xffffffff813eb283 in __asan_loadN (addr=addr@entry=0xffffffff818f75f0, size=size@entry=8)
      at .../linux/mm/kasan/generic.c:278
  #7  0xffffffff815df24e in memcmp (cs=cs@entry=0xffffffff818f75f0, ct=ct@entry=0x1be2fe4, count=<optimized out>,
      count@entry=12) at .../linux/lib/string.c:683
  #8  0xffffffff81ba2323 in cpuid_base_hypervisor (sig=0xffffffff818f75f0 "XenVMMXenVMM", leaves=2)
      at .../linux/arch/x86/include/asm/cpuid/api.h:206
  #9  xen_cpuid_base () at .../linux/arch/x86/include/asm/xen/hypervisor.h:46
  #10 xen_prepare_pvh () at .../linux/arch/x86/platform/pvh/enlighten.c:119
  #11 0x0000000001ba2588 in ?? ()
  #12 0x0000000000000000 in ?? ()
  (gdb)

  Frames #7-#8 show the non-builtin memcmp() (lib/string.c) was called
  even with __builtin_memcmp() being used in cpuid_base_hypervisor().

Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
---
Changes in v4:
- Patch 1: address Juergen's feedback:
  - s/In next patch/In a future patch/.
  - Move footnote (Reasons not to include...) after "---".
- Add 'Reviewed-by: Juergen Gross' in patches 1 and 2 as well.
- Link to v3: https://lore.kernel.org/r/20260520-pvh-kasan-inline-v3-0-bede769c6ec7@igalia.com

Changes in v3:
- Create and use a separate header for inline string functions
  to fix a build error reported by kernel test robot (patch 1).
- That also removes '#ifndef _SETUP/#endif' in <asm/string.h>.
- Link to v2: https://lore.kernel.org/r/20260427-pvh-kasan-inline-v2-0-2c57b8dcff6a@igalia.com

Changes in v2:
- Add comment about the return value of __inline_memcmp() in patch 1. (v3: now 2)
- Add 'Reviewed-by: Juergen Gross' in patches 2 and 3 (v3: now 3 and 4).
- Link to v1: https://lore.kernel.org/r/20260422-pvh-kasan-inline-v1-0-7e6194344c92@igalia.com

---
Mauricio Faria de Oliveira (4):
      x86/asm: move inline string functions to <asm/string_inline.h>
      x86/asm, x86/boot: expose inline memcmp
      x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base()
      x86/pvh: fix unbootable VMs by really inlining memset() in xen_prepare_pvh()

 arch/x86/boot/string.c               |  6 ++----
 arch/x86/include/asm/cpuid/api.h     |  2 +-
 arch/x86/include/asm/string.h        | 21 +-------------------
 arch/x86/include/asm/string_inline.h | 37 ++++++++++++++++++++++++++++++++++++
 arch/x86/platform/pvh/enlighten.c    |  3 ++-
 5 files changed, 43 insertions(+), 26 deletions(-)
---
base-commit: d387b06f7c15b4639244ad66b4b0900c6a02b430
change-id: 20260422-pvh-kasan-inline-6efac77f1b27

Best regards,
-- 
Mauricio Faria de Oliveira <mfo@igalia.com>

[PATCH v4 1/4] x86/asm: move inline string functions to <asm/string_inline.h>

[Mauricio Faria de Oliveira]

In a future patch, 'boot/string.c' will include inline string functions.

Using the header <asm/string.h> is problematic for a couple of reasons
(i.e., build errors), which can be addressed, but introduce unnecessary
complexity and regression risk (beyond these _found_ couple of reasons).

Using a new header <asm/string_inline.h> is simpler and transparent to
existing users of <asm/string.h>, with less changes to 'boot/string.c'
and its users (eg 'boot/compressed/string.c' and 'purgatory/purgatory.ro'),
which minimize regression risk.

No functional change intended.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605140922.q7IlUv7o-lkp@intel.com/
Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
Reviewed-by: Juergen Gross <jgross@suse.com>

---
(*) Reasons not to include <asm/string.h> in 'boot/string.c':

1) 'boot/string.c' is built for 16-bit/real mode thus some type and word
size errors happen when <asm/string.h> include, e.g., <asm/string_64.h>.

This can be addressed with '#ifndef _SETUP' (defined by 'boot/Makefile').

2) 'boot/string.c' is included by 'boot/compressed/string.c' which is
the source of 'purgatory/string.o', linked by 'purgatory/purgatory.ro'
(CONFIG_KEXEC_FILE).

In 64BIT, <asm/string.h> includes <asm/string_64.h>, which references
__memset() and __memmove() with KCFI_REFERENCE(), ie, __ADDRESSABLE();
however, 'purgatory/purgatory.ro' is not linked with implementations.

So, CONFIG_KEXEC_FILE and CONFIG_CFI without CONFIG_KASAN hit errors:

  >> ld.lld: error: undefined symbol: __memset
     >>> referenced by string.c
     >>>               arch/x86/purgatory/purgatory.ro:\
                       (__UNIQUE_ID_addressable___memset_0)
  --
  >> ld.lld: error: undefined symbol: __memmove
     >>> referenced by string.c
     >>>               arch/x86/purgatory/purgatory.ro:\
                       (__UNIQUE_ID_addressable___memmove_1)

(Note: this is not hit with CONFIG_KASAN because 'boot/compressed/string.c'
adds aliases __memset()/__memmove() to memset()/memmove() in that case.)

This can be addressed with 'CFLAGS_string.o := -D__DISABLE_EXPORTS' so to
disable KCFI_REFERENCE() in 'purgatory/Makefile' (it removes CC_FLAGS_CFI
anyway).

...

However, since a change in this series would need more changes to address
errors it causes, it is reasonable to change the series not to cause them,
by using a separate header with _just_ inline string functions.
---
 arch/x86/include/asm/string.h        | 21 +--------------------
 arch/x86/include/asm/string_inline.h | 26 ++++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h
index 9cb5aae7fba9ffcf0f5af8f939d30467750ccaa9..8a849bb5d0c7100a2a1820ec0af9fc9f850727fd 100644
--- a/arch/x86/include/asm/string.h
+++ b/arch/x86/include/asm/string.h
@@ -8,25 +8,6 @@
 # include <asm/string_64.h>
 #endif
 
-static __always_inline void *__inline_memcpy(void *to, const void *from, size_t len)
-{
-	void *ret = to;
-
-	asm volatile("rep movsb"
-		     : "+D" (to), "+S" (from), "+c" (len)
-		     : : "memory");
-	return ret;
-}
-
-static __always_inline void *__inline_memset(void *s, int v, size_t n)
-{
-	void *ret = s;
-
-	asm volatile("rep stosb"
-		     : "+D" (s), "+c" (n)
-		     : "a" ((uint8_t)v)
-		     : "memory");
-	return ret;
-}
+#include <asm/string_inline.h>
 
 #endif /* _ASM_X86_STRING_H */
diff --git a/arch/x86/include/asm/string_inline.h b/arch/x86/include/asm/string_inline.h
new file mode 100644
index 0000000000000000000000000000000000000000..ffcfa6583d2bc7b91d078888518d0e80248af940
--- /dev/null
+++ b/arch/x86/include/asm/string_inline.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_STRING_INLINE_H
+#define _ASM_X86_STRING_INLINE_H
+
+static __always_inline void *__inline_memcpy(void *to, const void *from, size_t len)
+{
+	void *ret = to;
+
+	asm volatile("rep movsb"
+		     : "+D" (to), "+S" (from), "+c" (len)
+		     : : "memory");
+	return ret;
+}
+
+static __always_inline void *__inline_memset(void *s, int v, size_t n)
+{
+	void *ret = s;
+
+	asm volatile("rep stosb"
+		     : "+D" (s), "+c" (n)
+		     : "a" ((uint8_t)v)
+		     : "memory");
+	return ret;
+}
+
+#endif /* _ASM_X86_STRING_INLINE_H */

-- 
2.51.0

[PATCH v4 2/4] x86/asm, x86/boot: expose inline memcmp

[Mauricio Faria de Oliveira]

Move the inline memcmp function currently only available in 'boot/string.c'
and its users (eg, 'boot/compressed/string.c' and 'purgatory/purgatory.ro')
into the inline string functions header <asm/string_inline.h> to be reused.

Note that the inline memcmp() returns 0/1, not -1/0/1 as regular memcmp()
(reported by David Laight <david.laight.linux@gmail.com>), which is not
caused or changed by this commit; this will be addressed separately.

Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/boot/string.c               |  6 ++----
 arch/x86/include/asm/string_inline.h | 11 +++++++++++
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
index ac0f900ebc47efa81c92e1bb2010ea41677899c4..544681d046c3f87101309ffaca0c90512a244856 100644
--- a/arch/x86/boot/string.c
+++ b/arch/x86/boot/string.c
@@ -15,6 +15,7 @@
 #include <linux/errno.h>
 #include <linux/limits.h>
 #include <asm/asm.h>
+#include <asm/string_inline.h>
 #include "ctype.h"
 #include "string.h"
 
@@ -31,10 +32,7 @@
 
 int memcmp(const void *s1, const void *s2, size_t len)
 {
-	bool diff;
-	asm("repe cmpsb"
-	    : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len));
-	return diff;
+	return __inline_memcmp(s1, s2, len);
 }
 
 /*
diff --git a/arch/x86/include/asm/string_inline.h b/arch/x86/include/asm/string_inline.h
index ffcfa6583d2bc7b91d078888518d0e80248af940..91ed89bfdfa9b148002441e94f48039b17f70391 100644
--- a/arch/x86/include/asm/string_inline.h
+++ b/arch/x86/include/asm/string_inline.h
@@ -23,4 +23,15 @@ static __always_inline void *__inline_memset(void *s, int v, size_t n)
 	return ret;
 }
 
+/* Note: this memcmp() returns 0/1, not -1/0/1 as regular memcmp(). */
+static __always_inline int __inline_memcmp(const void *s1, const void *s2, size_t len)
+{
+	bool diff;
+
+	asm("repe cmpsb"
+	    : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len));
+
+	return diff;
+}
+
 #endif /* _ASM_X86_STRING_INLINE_H */

-- 
2.51.0

[PATCH v4 3/4] x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base()

[Mauricio Faria de Oliveira]

Even with __builtin the compiler may decide to use the out of line function
instead of the inline implementation.

The existing code is broken with gcc-14/15 but not gcc-12/13 (Ubuntu 25.10)
and vmlinux no longer boots with CONFIG_PVH if CONFIG_KASAN_GENERIC is set.

For testing purposes, if the size argument is reduced from 12 to 8 then the
compiler decides to use the inline implementation; that shows results vary.

Switch the builtin to the inline implementation to address it.

Fixes: 416a33c9afce ("x86/cpu: fix unbootable VMs by inlining memcmp() in hypervisor_cpuid_base()")
Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/include/asm/cpuid/api.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
index 82eddfa2347b32b76c2ea9b85f005ca5416ac71f..2d9f3d4d63de6e721f275d9e80d372edbdfedf30 100644
--- a/arch/x86/include/asm/cpuid/api.h
+++ b/arch/x86/include/asm/cpuid/api.h
@@ -204,7 +204,7 @@ static inline u32 cpuid_base_hypervisor(const char *sig, u32 leaves)
 		 * from PVH early boot code before instrumentation is set up
 		 * and memcmp() itself may be instrumented.
 		 */
-		if (!__builtin_memcmp(sig, signature, 12) &&
+		if (!__inline_memcmp(sig, signature, 12) &&
 		    (leaves == 0 || ((eax - base) >= leaves)))
 			return base;
 	}

-- 
2.51.0

[PATCH v4 4/4] x86/pvh: fix unbootable VMs by really inlining memset() in xen_prepare_pvh()

[Mauricio Faria de Oliveira]

Even with __builtin the compiler may decide to use the out of line function
instead of the inline implementation.

This particular one (still) generated the inline implementation as expected
(at least in these compiler versions), but this is not guaranteed to remain
the case, as seen with the previous commit.

Switch the builtin to the inline implementation to prevent a similar issue.

Fixes: fbe5a6dfe492 ("xen, pvh: fix unbootable VMs by inlining memset() in xen_prepare_pvh()")
Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
 arch/x86/platform/pvh/enlighten.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index f2053cbe9b0ce3d2178938269607c652ae8f528e..cb442cbd9d828619421babb281bfe9759edbca8a 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -8,6 +8,7 @@
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
 #include <asm/x86_init.h>
+#include <asm/string.h>
 
 #include <asm/xen/interface.h>
 
@@ -129,7 +130,7 @@ void __init xen_prepare_pvh(void)
 	 * This must not compile to "call memset" because memset() may be
 	 * instrumented.
 	 */
-	__builtin_memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
+	__inline_memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
 
 	hypervisor_specific_init(xen_guest);
 

-- 
2.51.0

Re: [PATCH v4 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN)

[Borislav Petkov]

On Tue, May 26, 2026 at 11:52:32AM -0300, Mauricio Faria de Oliveira wrote:
> The issue of unbootable VMs with CONFIG_PVH due to CONFIG_KASAN is back.

... and we care about that particular configuration because...?

>  arch/x86/boot/string.c               |  6 ++----
>  arch/x86/include/asm/cpuid/api.h     |  2 +-
>  arch/x86/include/asm/string.h        | 21 +-------------------
>  arch/x86/include/asm/string_inline.h | 37 ++++++++++++++++++++++++++++++++++++
>  arch/x86/platform/pvh/enlighten.c    |  3 ++-
>  5 files changed, 43 insertions(+), 26 deletions(-)

I fail to see justification for those gymnastics.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v4 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN)

[Mauricio Faria de Oliveira]

Thanks for having a look at this.

On 2026-05-27 17:47, Borislav Petkov wrote:
> On Tue, May 26, 2026 at 11:52:32AM -0300, Mauricio Faria de Oliveira wrote:
>> The issue of unbootable VMs with CONFIG_PVH due to CONFIG_KASAN is back.
> 
> ... and we care about that particular configuration because...?

PVH and KASAN can be enabled independently for their own purposes
(startup entry point and debugging), but when combined, KASAN might
break booting via the PVH entry point. There are precedents for
disabling KASAN instrumentation in specific code paths, including this
one (see listed commits), so addressing this issue/regression seems
reasonable.

In this instance, the use case is to speed up the dev-test cycle when
debugging on VMs: PVH allows booting directly from vmlinux, avoiding the
need to build/compress and decompress bzImage, while KASAN helps detect
issues early.

> 
>>  arch/x86/boot/string.c               |  6 ++----
>>  arch/x86/include/asm/cpuid/api.h     |  2 +-
>>  arch/x86/include/asm/string.h        | 21 +-------------------
>>  arch/x86/include/asm/string_inline.h | 37 ++++++++++++++++++++++++++++++++++++
>>  arch/x86/platform/pvh/enlighten.c    |  3 ++-
>>  5 files changed, 43 insertions(+), 26 deletions(-)
> 
> I fail to see justification for those gymnastics.

Briefly, this is a side effect of reusing code from 'boot/string.c'
through <asm/string.h>, which introduces additional complications;
please see patch 1 for details.

These complications could be avoided by not reusing that code and
instead adding slightly duplicated code [1] directly to <asm/string.h>,
if that is preferred. 

Please let me know your thoughts.

Thanks,

[1]
https://lore.kernel.org/all/324ef97b16f52e0ccc72f6381d1b5dd2@igalia.com/

-- 
Mauricio

Re: [PATCH v4 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN)

[Borislav Petkov]

On Sat, May 30, 2026 at 03:25:25PM -0300, Mauricio Faria de Oliveira wrote:
> In this instance, the use case is to speed up the dev-test cycle when
> debugging on VMs: PVH allows booting directly from vmlinux, avoiding the
> need to build/compress and decompress bzImage, while KASAN helps detect
> issues early.

Makes sense in itself. And you can't do your use case with KVM? It has to be
Xen?

> Briefly, this is a side effect of reusing code from 'boot/string.c'
> through <asm/string.h>, which introduces additional complications;
> please see patch 1 for details.
> 
> These complications could be avoided by not reusing that code and
> instead adding slightly duplicated code [1] directly to <asm/string.h>,
> if that is preferred.

I'll take a look.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v4 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN)

[Mauricio Faria de Oliveira]

On 2026-05-30 19:04, Borislav Petkov wrote:
> On Sat, May 30, 2026 at 03:25:25PM -0300, Mauricio Faria de Oliveira wrote:
>> In this instance, the use case is to speed up the dev-test cycle when
>> debugging on VMs: PVH allows booting directly from vmlinux, avoiding the
>> need to build/compress and decompress bzImage, while KASAN helps detect
>> issues early.
> 
> Makes sense in itself. And you can't do your use case with KVM? It has to be
> Xen?

It uses KVM, actually. 

IIUIC, the PVH entry point was originally developed for Xen, but later
QEMU support was added for KVM as well.
(found this blog post [1] with a nice summary and links about it.)

>> Briefly, this is a side effect of reusing code from 'boot/string.c'
>> through <asm/string.h>, which introduces additional complications;
>> please see patch 1 for details.
>> 
>> These complications could be avoided by not reusing that code and
>> instead adding slightly duplicated code [1] directly to <asm/string.h>,
>> if that is preferred.
> 
> I'll take a look.

Ok, thanks!

> 
> Thx.

-- 
Mauricio

Re: [PATCH v4 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN)

[Mauricio Faria de Oliveira]

On 2026-05-30 20:01, Mauricio Faria de Oliveira wrote:
> On 2026-05-30 19:04, Borislav Petkov wrote:
>> On Sat, May 30, 2026 at 03:25:25PM -0300, Mauricio Faria de Oliveira wrote:
>>> In this instance, the use case is to speed up the dev-test cycle when
>>> debugging on VMs: PVH allows booting directly from vmlinux, avoiding the
>>> need to build/compress and decompress bzImage, while KASAN helps detect
>>> issues early.
>> 
>> Makes sense in itself. And you can't do your use case with KVM? It has to be
>> Xen?
> 
> It uses KVM, actually. 
> 
> IIUIC, the PVH entry point was originally developed for Xen, but later
> QEMU support was added for KVM as well.
> (found this blog post [1] with a nice summary and links about it.)

[1]
https://stefano-garzarella.github.io/posts/2019-08-23-qemu-linux-kernel-pvh/

>>> Briefly, this is a side effect of reusing code from 'boot/string.c'
>>> through <asm/string.h>, which introduces additional complications;
>>> please see patch 1 for details.
>>> 
>>> These complications could be avoided by not reusing that code and
>>> instead adding slightly duplicated code [1] directly to <asm/string.h>,
>>> if that is preferred.
>> 
>> I'll take a look.
> 
> Ok, thanks!
> 
>> 
>> Thx.

-- 
Mauricio

Re: [PATCH v4 1/4] x86/asm: move inline string functions to <asm/string_inline.h>

[Borislav Petkov]

On Tue, May 26, 2026 at 11:52:33AM -0300, Mauricio Faria de Oliveira wrote:
> In a future patch, 'boot/string.c' will include inline string functions.
> 
> Using the header <asm/string.h> is problematic for a couple of reasons
> (i.e., build errors), which can be addressed, but introduce unnecessary
> complexity and regression risk (beyond these _found_ couple of reasons).
> 
> Using a new header <asm/string_inline.h> is simpler and transparent to
> existing users of <asm/string.h>, with less changes to 'boot/string.c'
> and its users (eg 'boot/compressed/string.c' and 'purgatory/purgatory.ro'),
> which minimize regression risk.
> 
> No functional change intended.
> 
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202605140922.q7IlUv7o-lkp@intel.com/
> Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
> 
> ---
> (*) Reasons not to include <asm/string.h> in 'boot/string.c':
> 
> 1) 'boot/string.c' is built for 16-bit/real mode thus some type and word
> size errors happen when <asm/string.h> include, e.g., <asm/string_64.h>.
> 
> This can be addressed with '#ifndef _SETUP' (defined by 'boot/Makefile').
> 
> 2) 'boot/string.c' is included by 'boot/compressed/string.c' which is
> the source of 'purgatory/string.o', linked by 'purgatory/purgatory.ro'
> (CONFIG_KEXEC_FILE).
> 
> In 64BIT, <asm/string.h> includes <asm/string_64.h>, which references
> __memset() and __memmove() with KCFI_REFERENCE(), ie, __ADDRESSABLE();
> however, 'purgatory/purgatory.ro' is not linked with implementations.
> 
> So, CONFIG_KEXEC_FILE and CONFIG_CFI without CONFIG_KASAN hit errors:
> 
>   >> ld.lld: error: undefined symbol: __memset
>      >>> referenced by string.c
>      >>>               arch/x86/purgatory/purgatory.ro:\
>                        (__UNIQUE_ID_addressable___memset_0)
>   --
>   >> ld.lld: error: undefined symbol: __memmove
>      >>> referenced by string.c
>      >>>               arch/x86/purgatory/purgatory.ro:\
>                        (__UNIQUE_ID_addressable___memmove_1)
> 
> (Note: this is not hit with CONFIG_KASAN because 'boot/compressed/string.c'
> adds aliases __memset()/__memmove() to memset()/memmove() in that case.)
> 
> This can be addressed with 'CFLAGS_string.o := -D__DISABLE_EXPORTS' so to
> disable KCFI_REFERENCE() in 'purgatory/Makefile' (it removes CC_FLAGS_CFI
> anyway).
> 
> ...
> 
> However, since a change in this series would need more changes to address
> errors it causes, it is reasonable to change the series not to cause them,
> by using a separate header with _just_ inline string functions.

This is very long-winded and it meanders across things. Write it more
disciplined, please, and formulate it such that you're writing the commit
message of a standalone patch. It should have merit on its own and not talk
about future patches and so on.

And yes, the intent to have a separate header which doesn't pull in
nasty deps between decompressor and kernel proper, is ok.

For that, we have arch/x86/include/asm/shared/ which contains functionality
shared between the two objects so I think you should move it there. It'll also
make it a "clean" header which contains solely this stuff and doesn't pull in
any other shit.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH v4 1/4] x86/asm: move inline string functions to <asm/string_inline.h>

[Mauricio Faria de Oliveira]

On 2026-05-30 20:48, Borislav Petkov wrote:
> On Tue, May 26, 2026 at 11:52:33AM -0300, Mauricio Faria de Oliveira wrote:
>> In a future patch, 'boot/string.c' will include inline string functions.
>> 
>> Using the header <asm/string.h> is problematic for a couple of reasons
>> (i.e., build errors), which can be addressed, but introduce unnecessary
>> complexity and regression risk (beyond these _found_ couple of reasons).
>> 
>> Using a new header <asm/string_inline.h> is simpler and transparent to
>> existing users of <asm/string.h>, with less changes to 'boot/string.c'
>> and its users (eg 'boot/compressed/string.c' and 'purgatory/purgatory.ro'),
>> which minimize regression risk.
>> 
>> No functional change intended.
>> 
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202605140922.q7IlUv7o-lkp@intel.com/
>> Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
>> Reviewed-by: Juergen Gross <jgross@suse.com>
>> 
>> ---
>> (*) Reasons not to include <asm/string.h> in 'boot/string.c':
>> 
>> 1) 'boot/string.c' is built for 16-bit/real mode thus some type and word
>> size errors happen when <asm/string.h> include, e.g., <asm/string_64.h>.
>> 
>> This can be addressed with '#ifndef _SETUP' (defined by 'boot/Makefile').
>> 
>> 2) 'boot/string.c' is included by 'boot/compressed/string.c' which is
>> the source of 'purgatory/string.o', linked by 'purgatory/purgatory.ro'
>> (CONFIG_KEXEC_FILE).
>> 
>> In 64BIT, <asm/string.h> includes <asm/string_64.h>, which references
>> __memset() and __memmove() with KCFI_REFERENCE(), ie, __ADDRESSABLE();
>> however, 'purgatory/purgatory.ro' is not linked with implementations.
>> 
>> So, CONFIG_KEXEC_FILE and CONFIG_CFI without CONFIG_KASAN hit errors:
>> 
>>   >> ld.lld: error: undefined symbol: __memset
>>      >>> referenced by string.c
>>      >>>               arch/x86/purgatory/purgatory.ro:\
>>                        (__UNIQUE_ID_addressable___memset_0)
>>   --
>>   >> ld.lld: error: undefined symbol: __memmove
>>      >>> referenced by string.c
>>      >>>               arch/x86/purgatory/purgatory.ro:\
>>                        (__UNIQUE_ID_addressable___memmove_1)
>> 
>> (Note: this is not hit with CONFIG_KASAN because 'boot/compressed/string.c'
>> adds aliases __memset()/__memmove() to memset()/memmove() in that case.)
>> 
>> This can be addressed with 'CFLAGS_string.o := -D__DISABLE_EXPORTS' so to
>> disable KCFI_REFERENCE() in 'purgatory/Makefile' (it removes CC_FLAGS_CFI
>> anyway).
>> 
>> ...
>> 
>> However, since a change in this series would need more changes to address
>> errors it causes, it is reasonable to change the series not to cause them,
>> by using a separate header with _just_ inline string functions.
> 
> This is very long-winded and it meanders across things. Write it more
> disciplined, please, and formulate it such that you're writing the commit
> message of a standalone patch. It should have merit on its own and not talk
> about future patches and so on.
> 
> And yes, the intent to have a separate header which doesn't pull in
> nasty deps between decompressor and kernel proper, is ok.
> 
> For that, we have arch/x86/include/asm/shared/ which contains functionality
> shared between the two objects so I think you should move it there. It'll also
> make it a "clean" header which contains solely this stuff and doesn't pull in
> any other shit.

Ack; thanks for the feedback and pointers, I'll take a look.

> 
> Thx.

-- 
Mauricio

Re: [PATCH v4 0/4] x86/pvh: fix unbootable VMs again (PVH + KASAN)

[Mauricio Faria de Oliveira]

On 2026-05-26 11:52, Mauricio Faria de Oliveira wrote:
> The issue of unbootable VMs with CONFIG_PVH due to CONFIG_KASAN is back.
> 
> Booting directly from vmlinux (instead of bzImage) now fails with gcc-14/15
> (but works with gcc-12/13) if CONFIG_KASAN_GENERIC is set, on Ubuntu 25.10.

v5:
https://lore.kernel.org/all/20260601-pvh-kasan-inline-v5-0-c996e92dfe9a@igalia.com

-- 
Mauricio