[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BUG] x86emul/test: avoid assertion in emul_test_read_xcr() when XSAVE is absent
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Precious <andrewprecious388@xxxxxxxxx>
- Date: Fri, 21 Aug 2026 12:24:44 +0300
- Arc-authentication-results: i=1; mx.google.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=E4nRm5b1hbQERUTszUQ51KBYoIjLDjCPQXKWoXXPZq4=; fh=SygEH9Z7MBlxPm51gae5A7uhhF1jD0TC8uv8zGf6b6I=; b=nTw2u7HAbswSSSAQ3WrnlJ7RusPE3k24v6bfwFaeoWEmVNMW4nR04lXyyneo0Q/b8Z Vrc6XceKIlC81eO5aMUcP2b2u4GXZ3iN4c7YyR80US/AzCiijvRV9WssqiAMARmErtZP Ntu7rT+T6yLufYJw9RxpA3s8UK1mDQWI3rgY+Bf4p6FueLtPquy6gO9mScLzYORmsgMB 3+09Eov+aGFTXIaxI0OeoopmL+mznoD+XRQOC61UKvvgajFkLH+InNbz6Kt9Pe6tWYZf Wev8Hu8HZ3jozrASSoymJkHbmBFs92kpGkvMRxXgQ7Q0Zu8gHZuuAO6ov3H9hOSXaw1h NWgA==; darn=lists.xenproject.org
- Arc-seal: i=1; a=rsa-sha256; t=1787304295; cv=none; d=google.com; s=arc-20260327; b=PUdZuYt0Gpv4mFYislA0tzERfE11BIQRgBZft4+NwLQyQh1sX5e5N437XUu2S9yvNO OwzwT85M6i46zRTV+HN/h6GtwnM3UL6d22rozfLePv+8iv49MCjMIdFDC6GOfcITTew8 IsvXtCjEynYILIRjD6BZFP8UrZZn34smI6Q6D1yUBpkYH1KBFXR7e5g4rhWrl1RJz15X z+2xXYzXx9xasBygHvteh3yA2EMGznLoSWGWRKnCUAXq5lZh5cdSanJXq2zSdChbMFoK BePGbk8tKSsU0gET3/5oc9K39rT14FiReCvLQFGRIOJWybqulZGS7xV/NmALI2d8sHmB U2jg==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
- Cc: andrew.cooper3@xxxxxxxxxx, roger@xxxxxxxxxxxxxx, teddy.astie@xxxxxxxxxx, anthony.perard@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Fri, 21 Aug 2026 09:25:14 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
My thinking before was that the fuzzer mutated some bytes that made the emulator think cpu_has_xsave was false.
But now I believe that this was caused by an environment issue caused by the default QEMU virtual cpu model.
The VM has no OSXSAVE flag(but the host does), x86_cpu_policy_fill_native() initializes with the OSXSAVE bit cleared,hits the assert(cpu_has_xsave) which then aborts the fuzzer.
On 20.08.2026 14:30, Andrew Precious wrote:
> I just realized that I attached the binary result without the fuzzer error.
> To generate the previous assertion error I would have to rerun the fuzzer
> again which took many hours(~18hrs). Though that was the only error I found
> after that long.
>
> VM machine that I performed the fuzzing on:
> - A VM running Debian GNU/Linux 13 (trixie)
> - x86_64,QEMU Virtual CPU version 2.5
What does that mean CPUID-wise, seeing that ...
> On Thu, Aug 20, 2026 at 11:45 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>> On 19.08.2026 20:07, Andrew Mbugua wrote:
>>> While running the x86_instruction_emulator fuzzer via AFL, I encountered
>> an assertion failure in the emul_test_read_xcr() function.
>>
>> Thanks for the report.
>>
>>> The fuzzer is able to generate a CPU state where cpu_has_xsave is false.
>>
>> I'm having trouble here: cpu_policy isn't populated from fuzzing input, and
>>
>> /* Intentionally checking OSXSAVE here. */
>> #define cpu_has_xsave (cpu_policy.basic.raw[1].c & (1u << 27))
>>
>> would mean that upon filling cpu_policy (emul_test_init() ->
>> x86_cpu_policy_fill_native()) the OSXSAVE bit would be clear. Are you
>> suggesting you did the fuzzing on some really old hardware?
... there was this aspect that I couldn't understand?
Jan
|
