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

[PATCH v9 0/5] 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 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 v9:
- Patch 1: new patch in v9 to fix the patch submitted separately in v8.
- Rebased to next-20260821.
- Link to v8: https://lore.kernel.org/r/20260723-pvh-kasan-inline-v8-0-c1f62c156f52@igalia.com

Changes in v8:
- Patch 2 in v7 was submitted separately as requested, and the
  rest of this series was rebased on top of it (Borislav Petkov).
  Link: https://lore.kernel.org/all/20260723-x86-memcmp-asm-v2-1-d93ecb43797f@igalia.com/
- Patch 2 in v8:
  - Mention 'No functional changes' (Borislav Petkov).
  - Remove comment at the top of the header (Borislav Petkov).
- Link to v7: https://lore.kernel.org/r/20260721-pvh-kasan-inline-v7-0-38979a50cef0@igalia.com

Changes in v7:
- Patch 2 (added):
  - Address pre-existing issues in 'asm' (Borislav Petkov, Sashiko).
- Link to v6: https://lore.kernel.org/r/20260701-pvh-kasan-inline-v6-0-ba99045dfa9f@igalia.com

Changes in v6:
- Patch 1:
  - Explain the return value difference between __inline_memcmp() and memcmp().
- Patch 2 (added):
  - Group __inline string functions in <asm/shared/string.h>.
- Link to v5: https://lore.kernel.org/r/20260630-pvh-kasan-inline-v5-0-52afc979be81@igalia.com

Changes in v5:
- Create a minimal separate header in <asm/shared/string.h> instead,
  to be used by 'boot/setup.c' and <asm/string.h> (Borislav Petkov).
- Patch 1 (in v4/v3) is no longer needed; removed.
- Patch 1 (in v5):
  - Briefly mention there are issues with <asm/string.h>.
  - Remove 'Reviewed-by: Jurgen Gross' to be conservative
    (same code change and result, but the means changed).
- Link to v4: https://lore.kernel.org/r/20260526-pvh-kasan-inline-v4-0-a310e6a25ecd@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 (5):
      x86/boot: Remove "cc" clobber from memcmp()
      x86/asm, x86/boot: expose inline memcmp()
      x86/asm: group inline string functions
      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               | 13 ++--------
 arch/x86/include/asm/cpuid/api.h     |  2 +-
 arch/x86/include/asm/shared/string.h | 47 ++++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/string.h        | 21 +---------------
 arch/x86/platform/pvh/enlighten.c    |  3 ++-
 5 files changed, 53 insertions(+), 33 deletions(-)
---
base-commit: 903c1cf6dff9964e71eda98a39e2e5d442050472
change-id: 20260422-pvh-kasan-inline-6efac77f1b27

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

[PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[Mauricio Faria de Oliveira]

According to the GCC documentation, conditions in the flags register
(e.g., "=@ccnz") are output operands [1] and the compiler is aware [2].

Also, clobbers (e.g., "cc") may not overlap with an output operand [2].

Thus, remove the "cc" clobber as it is redudant, and overlaps with, the
"=@ccnz" output operand.

    """
    6.11.2.4 Flag Output Operands

        On some targets, a special form of output operand exists by which
        conditions in the flags register may be outputs of the asm. [...]

    6.11.2.6 Clobbers and Scratch Registers

        While the compiler is aware of changes to entries listed in the
        output operands, [...]

        Clobber descriptions may not in any way overlap with an input or
        output operand. [...]
    """

Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Link: https://lore.kernel.org/all/5e19b195-0ca2-4510-81cb-497b40e4aaf5@zytor.com/
Fixes: a8c171c107c0 ("x86/boot: Add volatile, clobbers and zero-length test in memcmp()")
Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands [1]
Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers-1 [2]
---
 arch/x86/boot/string.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
index 1632d40e1f545ae0665597069b568ea6b6c263e5..03278b4393887cb71cb063818d3378c4f52b06f8 100644
--- a/arch/x86/boot/string.c
+++ b/arch/x86/boot/string.c
@@ -40,7 +40,7 @@ int memcmp(const void *s1, const void *s2, size_t len)
 	asm volatile("test %3, %3\n\t"
 		     "repe cmpsb"
 		     : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len)
-		     : : "cc", "memory");
+		     : : "memory");
 	return diff;
 }
 

-- 
2.47.3

[PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp()

[Mauricio Faria de Oliveira]

Move the inline memcmp function currently only available in 'boot/string.c'
into the shared string function header <asm/shared/string.h> to be reused.

This is not done through <asm/string.h> to avoid pulling unnecessary code
in 'boot/string.c' that causes build errors in 'boot/compressed/string.c'
and 'purgatory/purgatory.ro'.

No functional changes.

Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>

---

Thanks to David Laight for noticing the return value difference between
inline and regular memcmp().
---
 arch/x86/boot/string.c               | 13 ++-----------
 arch/x86/include/asm/shared/string.h | 26 ++++++++++++++++++++++++++
 2 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
index 03278b4393887cb71cb063818d3378c4f52b06f8..be454a6864225f3a972c3e81826b77ed4e8a57fe 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/shared/string.h>
 #include "ctype.h"
 #include "string.h"
 
@@ -31,17 +32,7 @@
 
 int memcmp(const void *s1, const void *s2, size_t len)
 {
-	bool diff;
-
-	/*
-	 * Make sure ZF is properly set in the len==0 case because in it,
-	 * RCX==0 and the REPE; CMPSB won't get executed.
-	 */
-	asm volatile("test %3, %3\n\t"
-		     "repe cmpsb"
-		     : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len)
-		     : : "memory");
-	return diff;
+	return __inline_memcmp(s1, s2, len);
 }
 
 /*
diff --git a/arch/x86/include/asm/shared/string.h b/arch/x86/include/asm/shared/string.h
new file mode 100644
index 0000000000000000000000000000000000000000..06c1d5e5013e4d59cfb49866d10e164362d2c4cc
--- /dev/null
+++ b/arch/x86/include/asm/shared/string.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_SHARED_STRING_H
+#define _ASM_X86_SHARED_STRING_H
+
+/*
+ * This inline memcmp() returns 0 (equal) or 1 (not equal).
+ * The regular memcmp() returns <0 (less than), 0 (equal), or >0 (greater than)
+ * to indicate ordering as well.
+ */
+static __always_inline int __inline_memcmp(const void *s1, const void *s2, size_t len)
+{
+	bool diff;
+
+	/*
+	 * Make sure ZF is properly set in the len==0 case because in it,
+	 * RCX==0 and the REPE; CMPSB won't get executed.
+	 */
+	asm volatile("test %3, %3\n\t"
+		     "repe cmpsb"
+		     : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len)
+		     : : "memory");
+
+	return diff;
+}
+
+#endif /* _ASM_X86_SHARED_STRING_H */

-- 
2.47.3

[PATCH v9 3/5] x86/asm: group inline string functions

[Mauricio Faria de Oliveira]

Group the __inline string functions in the same header.

Use <asm/shared/string.h> since __inline_memcmp() must remain there for use
by arch/x86/boot/string.c.

No functional changes.

Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
---
 arch/x86/include/asm/shared/string.h | 21 +++++++++++++++++++++
 arch/x86/include/asm/string.h        | 21 +--------------------
 2 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/shared/string.h b/arch/x86/include/asm/shared/string.h
index 06c1d5e5013e4d59cfb49866d10e164362d2c4cc..ab033d27c581e44ba3f5a494ca29e31776be51f2 100644
--- a/arch/x86/include/asm/shared/string.h
+++ b/arch/x86/include/asm/shared/string.h
@@ -2,6 +2,27 @@
 #ifndef _ASM_X86_SHARED_STRING_H
 #define _ASM_X86_SHARED_STRING_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;
+}
+
 /*
  * This inline memcmp() returns 0 (equal) or 1 (not equal).
  * The regular memcmp() returns <0 (less than), 0 (equal), or >0 (greater than)
diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h
index 9cb5aae7fba9ffcf0f5af8f939d30467750ccaa9..dbf59f0d4cca71e2ddce0d8764aeec8782236669 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/shared/string.h>
 
 #endif /* _ASM_X86_STRING_H */

-- 
2.47.3

[PATCH v9 4/5] 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.47.3

[PATCH v9 5/5] 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.

Switch the builtin to the inline implementation to address it.

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.47.3

Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[Jan Beulich]

On 22.08.2026 20:33, Mauricio Faria de Oliveira wrote:
> According to the GCC documentation, conditions in the flags register
> (e.g., "=@ccnz") are output operands [1] and the compiler is aware [2].
> 
> Also, clobbers (e.g., "cc") may not overlap with an output operand [2].
> 
> Thus, remove the "cc" clobber as it is redudant, and overlaps with, the
> "=@ccnz" output operand.
> 
>     """
>     6.11.2.4 Flag Output Operands
> 
>         On some targets, a special form of output operand exists by which
>         conditions in the flags register may be outputs of the asm. [...]
> 
>     6.11.2.6 Clobbers and Scratch Registers
> 
>         While the compiler is aware of changes to entries listed in the
>         output operands, [...]
> 
>         Clobber descriptions may not in any way overlap with an input or
>         output operand. [...]
>     """
> 
> Reported-by: "H. Peter Anvin" <hpa@zytor.com>
> Link: https://lore.kernel.org/all/5e19b195-0ca2-4510-81cb-497b40e4aaf5@zytor.com/
> Fixes: a8c171c107c0 ("x86/boot: Add volatile, clobbers and zero-length test in memcmp()")
> Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
> Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands [1]
> Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers-1 [2]

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> --- a/arch/x86/boot/string.c
> +++ b/arch/x86/boot/string.c
> @@ -40,7 +40,7 @@ int memcmp(const void *s1, const void *s2, size_t len)
>  	asm volatile("test %3, %3\n\t"
>  		     "repe cmpsb"
>  		     : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len)
> -		     : : "cc", "memory");
> +		     : : "memory");

In fact I'm using a modified gcc which properly rejects such conflicting
uses of output and clobber. ("cc" clobbers are redundant on x86 anyway.)

Jan

Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[Borislav Petkov]

On Sat, Aug 22, 2026 at 03:33:17PM -0300, Mauricio Faria de Oliveira wrote:
> According to the GCC documentation, conditions in the flags register
> (e.g., "=@ccnz") are output operands [1] and the compiler is aware [2].
> 
> Also, clobbers (e.g., "cc") may not overlap with an output operand [2].
> 
> Thus, remove the "cc" clobber as it is redudant, and overlaps with, the
> "=@ccnz" output operand.
> 
>     """
>     6.11.2.4 Flag Output Operands
> 
>         On some targets, a special form of output operand exists by which
>         conditions in the flags register may be outputs of the asm. [...]
> 
>     6.11.2.6 Clobbers and Scratch Registers
> 
>         While the compiler is aware of changes to entries listed in the
>         output operands, [...]
> 
>         Clobber descriptions may not in any way overlap with an input or
>         output operand. [...]
>     """
> 
> Reported-by: "H. Peter Anvin" <hpa@zytor.com>
> Link: https://lore.kernel.org/all/5e19b195-0ca2-4510-81cb-497b40e4aaf5@zytor.com/
> Fixes: a8c171c107c0 ("x86/boot: Add volatile, clobbers and zero-length test in memcmp()")
> Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
> Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands [1]
> Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers-1 [2]
> ---
>  arch/x86/boot/string.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/boot/string.c b/arch/x86/boot/string.c
> index 1632d40e1f545ae0665597069b568ea6b6c263e5..03278b4393887cb71cb063818d3378c4f52b06f8 100644
> --- a/arch/x86/boot/string.c
> +++ b/arch/x86/boot/string.c
> @@ -40,7 +40,7 @@ int memcmp(const void *s1, const void *s2, size_t len)
>  	asm volatile("test %3, %3\n\t"
>  		     "repe cmpsb"
>  		     : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len)
> -		     : : "cc", "memory");
> +		     : : "memory");
>  	return diff;
>  }

So far, so good.

But then I'd expect that gcc would enforce that. I know it can't have it when
the clobbers contain input or output regs:

In function ‘__memcmp’,
    inlined from ‘main’ at memcmp.c:25:6:
memcmp.c:11:9: error: ‘asm’ operand has impossible constraints or there are not enough registers
   11 |         asm volatile("test %3, %3\n\t"
      |         ^~~

but with "cc" clobbers it works.

That's gcc-16 btw.

Micha, Richi?

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[David Laight]

On Tue, 1 Sep 2026 15:16:58 +0200
Jan Beulich <jbeulich@suse.com> wrote:

> On 22.08.2026 20:33, Mauricio Faria de Oliveira wrote:
> > According to the GCC documentation, conditions in the flags register
> > (e.g., "=@ccnz") are output operands [1] and the compiler is aware [2].
> > 
> > Also, clobbers (e.g., "cc") may not overlap with an output operand [2].
> > 
> > Thus, remove the "cc" clobber as it is redudant, and overlaps with, the
> > "=@ccnz" output operand.
> > 
> >     """
> >     6.11.2.4 Flag Output Operands
> > 
> >         On some targets, a special form of output operand exists by which
> >         conditions in the flags register may be outputs of the asm. [...]
> > 
> >     6.11.2.6 Clobbers and Scratch Registers
> > 
> >         While the compiler is aware of changes to entries listed in the
> >         output operands, [...]
> > 
> >         Clobber descriptions may not in any way overlap with an input or
> >         output operand. [...]
> >     """
> > 
> > Reported-by: "H. Peter Anvin" <hpa@zytor.com>
> > Link: https://lore.kernel.org/all/5e19b195-0ca2-4510-81cb-497b40e4aaf5@zytor.com/
> > Fixes: a8c171c107c0 ("x86/boot: Add volatile, clobbers and zero-length test in memcmp()")
> > Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
> > Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands [1]
> > Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers-1 [2]  
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
> > --- a/arch/x86/boot/string.c
> > +++ b/arch/x86/boot/string.c
> > @@ -40,7 +40,7 @@ int memcmp(const void *s1, const void *s2, size_t len)
> >  	asm volatile("test %3, %3\n\t"
> >  		     "repe cmpsb"
> >  		     : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len)
> > -		     : : "cc", "memory");
> > +		     : : "memory");  
> 
> In fact I'm using a modified gcc which properly rejects such conflicting
> uses of output and clobber. ("cc" clobbers are redundant on x86 anyway.)

And, if "cc" clobber wasn't redundant, you'd need clobbers for the cc flags
that weren't being used as output values.

David

> 
> Jan
> 

Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[Michael Matz]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

Hello,

On Tue, 1 Sep 2026, Borislav Petkov wrote:

> On Sat, Aug 22, 2026 at 03:33:17PM -0300, Mauricio Faria de Oliveira wrote:
> > According to the GCC documentation, conditions in the flags register
> > (e.g., "=@ccnz") are output operands [1] and the compiler is aware [2].
> > 
> > Also, clobbers (e.g., "cc") may not overlap with an output operand [2].
> > 
> > Thus, remove the "cc" clobber as it is redudant, and overlaps with, the
> > "=@ccnz" output operand.

Strictly speaking, on x86, the '=@ccXY' constraints are register outputs 
into normal random integer registers (though they are of course 
initialized in a funny way), while the 'cc' clobber is not a register at 
all, but rather a fuzzy idea of "state" in old cc0-based compilers (which 
the x86 backend isn't anymore since, ... well, about forever, 1999).  As 
such they both really don't conflict and ...

> But then I'd expect that gcc would enforce that. I know it can't have it 
> when the clobbers contain input or output regs:
> 
> In function ‘__memcmp’,
>     inlined from ‘main’ at memcmp.c:25:6:
> memcmp.c:11:9: error: ‘asm’ operand has impossible constraints or there are not enough registers
>    11 |         asm volatile("test %3, %3\n\t"
>       |         ^~~
> 
> but with "cc" clobbers it works.

... hence there's nothing to report.  In fact what an explicit 'cc' 
clobber once meant in cc0 backends (that indiscriminated flag "state") is 
manufactured by the non-cc0 backends (all of them now) automatically 
whenever an asm has no flag output constraints at all.  (On x86 that means 
it adds the "flags" register (internal name for the collection of flag 
status bits) to the clobber set automatically when there are no =@ccXY 
constraints).

You can regard all 'cc' clobbers as pure source compatibility, they have 
no meaning anymore.  But as they are so ubiquitous (even in our own docu), 
they remain recognized.


Ciao,
Michael.

Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[Mauricio Faria de Oliveira]

On 2026-09-02 10:29, Michael Matz wrote:
> Hello,
> 
> On Tue, 1 Sep 2026, Borislav Petkov wrote:
> 
>> On Sat, Aug 22, 2026 at 03:33:17PM -0300, Mauricio Faria de Oliveira wrote:
>> > According to the GCC documentation, conditions in the flags register
>> > (e.g., "=@ccnz") are output operands [1] and the compiler is aware [2].
>> > 
>> > Also, clobbers (e.g., "cc") may not overlap with an output operand [2].
>> > 
>> > Thus, remove the "cc" clobber as it is redudant, and overlaps with, the
>> > "=@ccnz" output operand.
> 
> Strictly speaking, on x86, the '=@ccXY' constraints are register outputs 
> into normal random integer registers (though they are of course 
> initialized in a funny way), while the 'cc' clobber is not a register at 
> all, but rather a fuzzy idea of "state" in old cc0-based compilers (which 
> the x86 backend isn't anymore since, ... well, about forever, 1999).  As 
> such they both really don't conflict and ...
> 
>> But then I'd expect that gcc would enforce that. I know it can't have it 
>> when the clobbers contain input or output regs:
>> 
>> In function ‘__memcmp’,
>>     inlined from ‘main’ at memcmp.c:25:6:
>> memcmp.c:11:9: error: ‘asm’ operand has impossible constraints or there are not enough registers
>>    11 |         asm volatile("test %3, %3\n\t"
>>       |         ^~~
>> 
>> but with "cc" clobbers it works.
> 
> ... hence there's nothing to report.  In fact what an explicit 'cc' 
> clobber once meant in cc0 backends (that indiscriminated flag "state") is 
> manufactured by the non-cc0 backends (all of them now) automatically 
> whenever an asm has no flag output constraints at all.  (On x86 that means 
> it adds the "flags" register (internal name for the collection of flag 
> status bits) to the clobber set automatically when there are no =@ccXY 
> constraints).
> 
> You can regard all 'cc' clobbers as pure source compatibility, they have 
> no meaning anymore.  But as they are so ubiquitous (even in our own docu), 
> they remain recognized.

Michael, thanks for the detailed explanation; that's very nice to know.

Boris, I guess this may be added as clarification in the commit message.
Would you prefer another version with it?

Thanks,

> 
> 
> Ciao,
> Michael.

-- 
Mauricio

Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[H. Peter Anvin]

On September 2, 2026 1:33:54 AM PDT, David Laight <david.laight.linux@gmail.com> wrote:
>On Tue, 1 Sep 2026 15:16:58 +0200
>Jan Beulich <jbeulich@suse.com> wrote:
>
>> On 22.08.2026 20:33, Mauricio Faria de Oliveira wrote:
>> > According to the GCC documentation, conditions in the flags register
>> > (e.g., "=@ccnz") are output operands [1] and the compiler is aware [2].
>> > 
>> > Also, clobbers (e.g., "cc") may not overlap with an output operand [2].
>> > 
>> > Thus, remove the "cc" clobber as it is redudant, and overlaps with, the
>> > "=@ccnz" output operand.
>> > 
>> >     """
>> >     6.11.2.4 Flag Output Operands
>> > 
>> >         On some targets, a special form of output operand exists by which
>> >         conditions in the flags register may be outputs of the asm. [...]
>> > 
>> >     6.11.2.6 Clobbers and Scratch Registers
>> > 
>> >         While the compiler is aware of changes to entries listed in the
>> >         output operands, [...]
>> > 
>> >         Clobber descriptions may not in any way overlap with an input or
>> >         output operand. [...]
>> >     """
>> > 
>> > Reported-by: "H. Peter Anvin" <hpa@zytor.com>
>> > Link: https://lore.kernel.org/all/5e19b195-0ca2-4510-81cb-497b40e4aaf5@zytor.com/
>> > Fixes: a8c171c107c0 ("x86/boot: Add volatile, clobbers and zero-length test in memcmp()")
>> > Signed-off-by: Mauricio Faria de Oliveira <mfo@igalia.com>
>> > Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands [1]
>> > Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers-1 [2]  
>> 
>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> 
>> > --- a/arch/x86/boot/string.c
>> > +++ b/arch/x86/boot/string.c
>> > @@ -40,7 +40,7 @@ int memcmp(const void *s1, const void *s2, size_t len)
>> >  	asm volatile("test %3, %3\n\t"
>> >  		     "repe cmpsb"
>> >  		     : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len)
>> > -		     : : "cc", "memory");
>> > +		     : : "memory");  
>> 
>> In fact I'm using a modified gcc which properly rejects such conflicting
>> uses of output and clobber. ("cc" clobbers are redundant on x86 anyway.)
>
>And, if "cc" clobber wasn't redundant, you'd need clobbers for the cc flags
>that weren't being used as output values.
>
>David
>
>> 
>> Jan
>> 
>

No. The condition codes aren't orthogonal like that. There is only one flags register. 

(On x86 I believe asm statements are assumed to clobber the flags unconditionally, because it is so common.)

Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[Borislav Petkov]

On Wed, Sep 02, 2026 at 03:29:44PM +0200, Michael Matz wrote:
> Strictly speaking, on x86, the '=@ccXY' constraints are register outputs 
> into normal random integer registers (though they are of course 
> initialized in a funny way), while the 'cc' clobber is not a register at 
> all, but rather a fuzzy idea of "state" in old cc0-based compilers (which 
> the x86 backend isn't anymore since, ... well, about forever, 1999).  As 
> such they both really don't conflict and ...
> 
> > But then I'd expect that gcc would enforce that. I know it can't have it 
> > when the clobbers contain input or output regs:
> > 
> > In function ‘__memcmp’,
> >     inlined from ‘main’ at memcmp.c:25:6:
> > memcmp.c:11:9: error: ‘asm’ operand has impossible constraints or there are not enough registers
> >    11 |         asm volatile("test %3, %3\n\t"
> >       |         ^~~
> > 
> > but with "cc" clobbers it works.
> 
> ... hence there's nothing to report. 

Aaaha, so the enforcement is solely documentation-based. :-)

> In fact what an explicit 'cc' clobber once meant in cc0 backends (that
> indiscriminated flag "state") is manufactured by the non-cc0 backends (all
> of them now) automatically whenever an asm has no flag output constraints at
> all.  (On x86 that means it adds the "flags" register (internal name for the
> collection of flag status bits) to the clobber set automatically when there
> are no =@ccXY constraints).
> 
> You can regard all 'cc' clobbers as pure source compatibility, they have 
> no meaning anymore.  But as they are so ubiquitous (even in our own docu), 
> they remain recognized.

Ah ok, I see. so we'll simply forget them.

Thanks Micha!

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[Borislav Petkov]

On Wed, Sep 02, 2026 at 10:48:14AM -0300, Mauricio Faria de Oliveira wrote:
> Boris, I guess this may be added as clarification in the commit message.
> Would you prefer another version with it?

Yeah, I'd actually prefer it in the code itself so that we can find it easier.
This file is as good as any.

Something like this:

/*
 * Summarized explanation that "cc" clobbers don't have a meaning
 *
 */
 
and leave the "cc" clobber there but commented out:

 /* "cc" ... */

so that we can grep for it easier later.

Thanks!

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[Mauricio Faria de Oliveira]

On 2026-09-02 21:01, Borislav Petkov wrote:
> On Wed, Sep 02, 2026 at 10:48:14AM -0300, Mauricio Faria de Oliveira wrote:
>> Boris, I guess this may be added as clarification in the commit message.
>> Would you prefer another version with it?
> 
> Yeah, I'd actually prefer it in the code itself so that we can find it easier.
> This file is as good as any.
> 
> Something like this:
> 
> /*
>  * Summarized explanation that "cc" clobbers don't have a meaning
>  *
>  */
>  
> and leave the "cc" clobber there but commented out:
> 
>  /* "cc" ... */
> 
> so that we can grep for it easier later.
> 
> Thanks!

Sure, will do in the next version.

The rest of this series is OK to you?
I can wait for further feedback and combine it with this change.

Thanks!

-- 
Mauricio

Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[Borislav Petkov]

On Wed, Sep 02, 2026 at 09:07:07PM -0300, Mauricio Faria de Oliveira wrote:
> The rest of this series is OK to you?
> I can wait for further feedback and combine it with this change.

Please wait - I haven't gone through the rest.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[David Laight]

On Wed, 2 Sep 2026 17:01:32 -0700
Borislav Petkov <bp@alien8.de> wrote:

> On Wed, Sep 02, 2026 at 10:48:14AM -0300, Mauricio Faria de Oliveira wrote:
> > Boris, I guess this may be added as clarification in the commit message.
> > Would you prefer another version with it?  
> 
> Yeah, I'd actually prefer it in the code itself so that we can find it easier.
> This file is as good as any.
> 
> Something like this:
> 
> /*
>  * Summarized explanation that "cc" clobbers don't have a meaning
>  *
>  */
>  
> and leave the "cc" clobber there but commented out:
> 
>  /* "cc" ... */
> 
> so that we can grep for it easier later.

Why would you need to?
Apart from a scan to just remove them all...

David

> 
> Thanks!
>