NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-arm/60655: vmt(4) probes the VMware backdoor unconditionally on aarch64 and panics the kernel on hypervisors that do not implement it
The following reply was made to PR port-arm/60655; it has been noted by GNATS.
From: Nick Hudson <nick.hudson%gmx.co.uk@localhost>
To: zakinko%snowrabbit.org@localhost,
"gnats-bugs%netbsd.org@localhost" <gnats-bugs%NetBSD.org@localhost>
Cc: "port-arm-maintainer%netbsd.org@localhost" <port-arm-maintainer%NetBSD.org@localhost>,
"netbsd-bugs%netbsd.org@localhost" <netbsd-bugs%NetBSD.org@localhost>,
"gnats-admin%netbsd.org@localhost" <gnats-admin%NetBSD.org@localhost>
Subject: Re: port-arm/60655: vmt(4) probes the VMware backdoor unconditionally
on aarch64 and panics the kernel on hypervisors that do not implement it
Date: Thu, 10 Sep 2026 07:50:57 +0100
--Apple-Mail=_AEE1818F-833B-4FFD-BCBD-5418E5C5662C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 06/09/2026 19:53, zakinko%snowrabbit.org@localhost =
<mailto:zakinko%snowrabbit.org@localhost> wrote:
> Thanks for catching that -- I had missed it. I read the pointer as:
> HypervisorId only exists from FADT revision 6, so the revision (and =
the
> length) should be checked before the field is read. Is that the right
> understanding?
>=20
> Two things I went on to do. I am not confident about either, so I =
would
> be grateful for your view:
>=20
> - The FADT reading moved into a small helper in dev/acpi,
> acpi_fadt_hypervisor_id(), so that the next user of the field need =
not
> copy it.
Not a big fan of this helper, but OK, I guess.
>=20
> - vmt_match() now probes only when the firmware names VMware, rather
> than skipping only when it names something else.
Sounds good.
> The difference shows
> on a hypervisor that traps MDCCSR_EL0 but leaves the field zero: the
> earlier form still panics there (I checked with a QEMU 11.1.0 =
patched
> to write zeros).
Any hypervisor that doesn=E2=80=99t provide a RAZ MDCCSR_EL0 is broken.
> The ACPI 6.0 note for the field reads to me as
> "probe only on a vendor you recognise", but I may be reading too =
much
> into it -- if you would rather keep the old behaviour on a zero =
field,
> it is a single condition to flip.
>=20
I think the code in the message is fine.
> =20
> +#if NACPICA > 0
> + /*
> + =
... A
> + * hypervisor other than VMware is free to answer that read with =
an
> + * undefined instruction trap, which is fatal in kernel mode; =
QEMU
> + * does so once the Apple vGIC is in use.
This is wrong.
QEMU was broken - it is now hopefully fixed with your diff.=
--Apple-Mail=_AEE1818F-833B-4FFD-BCBD-5418E5C5662C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;">
=20
<meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3DUTF-8">
=20
<div><p><br>
</p>
<div class=3D"moz-cite-prefix">On 06/09/2026 19:53,
<a class=3D"moz-txt-link-abbreviated" =
href=3D"mailto:zakinko%snowrabbit.org@localhost";>zakinko%snowrabbit.org@localhost</a> =
wrote:<br>
</div>
<blockquote type=3D"cite" =
cite=3D"mid:20260906175344.36CA7C9311%bambi.snowrabbit.org@localhost">
<pre wrap=3D"" class=3D"moz-quote-pre">Thanks for catching that -- =
I had missed it. I read the pointer as:
HypervisorId only exists from FADT revision 6, so the revision (and the
length) should be checked before the field is read. Is that the right
understanding?
Two things I went on to do. I am not confident about either, so I would
be grateful for your view:
- The FADT reading moved into a small helper in dev/acpi,
acpi_fadt_hypervisor_id(), so that the next user of the field need not
copy it.</pre>
</blockquote><p>Not a big fan of this helper, but OK, I guess.</p>
<blockquote type=3D"cite" =
cite=3D"mid:20260906175344.36CA7C9311%bambi.snowrabbit.org@localhost">
<pre wrap=3D"" class=3D"moz-quote-pre">
- vmt_match() now probes only when the firmware names VMware, rather
than skipping only when it names something =
else.</pre></blockquote>Sounds good.<br><blockquote type=3D"cite" =
cite=3D"mid:20260906175344.36CA7C9311%bambi.snowrabbit.org@localhost"><pre wrap=3D""=
class=3D"moz-quote-pre"> The difference shows
on a hypervisor that traps MDCCSR_EL0 but leaves the field zero: the
earlier form still panics there (I checked with a QEMU 11.1.0 patched
to write zeros).</pre></blockquote><div><br></div>Any hypervisor that =
doesn=E2=80=99t provide a RAZ MDCCSR_EL0 is =
broken.</div><div><br><blockquote type=3D"cite" =
cite=3D"mid:20260906175344.36CA7C9311%bambi.snowrabbit.org@localhost"><pre wrap=3D""=
class=3D"moz-quote-pre"> The ACPI 6.0 note for the field reads to me =
as
"probe only on a vendor you recognise", but I may be reading too much
into it -- if you would rather keep the old behaviour on a zero field,
it is a single condition to flip.
</pre></blockquote>I think the code in the message is =
fine.<br><blockquote type=3D"cite" =
cite=3D"mid:20260906175344.36CA7C9311%bambi.snowrabbit.org@localhost"><pre wrap=3D""=
class=3D"moz-quote-pre">=20
+#if NACPICA > 0
+ /*
+ ... =
A
+ * hypervisor other than VMware is free to answer that read with =
an
+ * undefined instruction trap, which is fatal in kernel mode; =
QEMU
+ * does so once the Apple vGIC is in use.</pre></blockquote>This =
is wrong.</div><div><br></div><div>QEMU was broken - it is now hopefully =
fixed with your diff.</div>
</body></html>=
--Apple-Mail=_AEE1818F-833B-4FFD-BCBD-5418E5C5662C--
Home |
Main Index |
Thread Index |
Old Index