[DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Antoine Damhet]

Hello,

We recently found out that some softwares are effectively crashing
when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.

I see no reason not to expose the setting to the user/command-line. A
previous patch has been submitted in 2015[1] but did not get through
because (if I understand correctly) using the IDs on the `SLIC`, `BXPC`
and `RSDT` tables were enough at the time.

If you agree, I am willing to forward port the patches of M. Jones but I
need to ask how it would work `Signed-Off`-wise ?

Thanks in advance for your time,

PS: the softwares will crash if the signature is found in any of the
    exposed tables.

[1]: https://lore.kernel.org/qemu-devel/1441220618-4750-1-git-send-email-rjones@redhat.com/

-- 
Antoine 'xdbob' Damhet

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Richard W.M. Jones]

On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> Hello,
> 
> We recently found out that some softwares are effectively crashing
> when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
> 
> I see no reason not to expose the setting to the user/command-line. A
> previous patch has been submitted in 2015[1] but did not get through
> because (if I understand correctly) using the IDs on the `SLIC`, `BXPC`
> and `RSDT` tables were enough at the time.
> 
> If you agree, I am willing to forward port the patches of M. Jones but I
> need to ask how it would work `Signed-Off`-wise ?

On this point, the patch I sent was actually written by
Michael Tokarev, I was only trying to get them upstream.

Rich.

> Thanks in advance for your time,
> 
> PS: the softwares will crash if the signature is found in any of the
>     exposed tables.
> 
> [1]: https://lore.kernel.org/qemu-devel/1441220618-4750-1-git-send-email-rjones@redhat.com/
> 
> -- 
> Antoine 'xdbob' Damhet

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Michael S. Tsirkin]

On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
> On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > Hello,
> > 
> > We recently found out that some softwares are effectively crashing
> > when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
> > 
> > I see no reason not to expose the setting to the user/command-line. A
> > previous patch has been submitted in 2015[1] but did not get through
> > because (if I understand correctly) using the IDs on the `SLIC`, `BXPC`
> > and `RSDT` tables were enough at the time.
> > 
> > If you agree, I am willing to forward port the patches of M. Jones but I
> > need to ask how it would work `Signed-Off`-wise ?
> 
> On this point, the patch I sent was actually written by
> Michael Tokarev, I was only trying to get them upstream.
> 
> Rich.

I think at least one of the issues is that e.g. UEFI at least
seems to assume unique OEM table IDs e.g. for SSDTs.

So let's try to be more specific please, which software
crashes, what does it want to see and in which table.


> > Thanks in advance for your time,
> > 
> > PS: the softwares will crash if the signature is found in any of the
> >     exposed tables.
> > 
> > [1]: https://lore.kernel.org/qemu-devel/1441220618-4750-1-git-send-email-rjones@redhat.com/
> > 
> > -- 
> > Antoine 'xdbob' Damhet
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Antoine Damhet]

On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
> > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > > Hello,
> > > 
> > > We recently found out that some softwares are effectively crashing
> > > when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
> > > 
> > > I see no reason not to expose the setting to the user/command-line. A
> > > previous patch has been submitted in 2015[1] but did not get through
> > > because (if I understand correctly) using the IDs on the `SLIC`, `BXPC`
> > > and `RSDT` tables were enough at the time.
> > > 
> > > If you agree, I am willing to forward port the patches of M. Jones but I
> > > need to ask how it would work `Signed-Off`-wise ?
> > 
> > On this point, the patch I sent was actually written by
> > Michael Tokarev, I was only trying to get them upstream.
> > 
> > Rich.
> 
> I think at least one of the issues is that e.g. UEFI at least
> seems to assume unique OEM table IDs e.g. for SSDTs.
> 
> So let's try to be more specific please, which software
> crashes, what does it want to see and in which table.

I'm sorry I cannot give you the name of the crashing software due to a
company policy. But I can tell you that if either `BOCHS ` or `BXPC` is
present in any of the tables it will crash. Any (or at least the few
that I threw at it) other string will work so it seems it's some kind
of DRM-related hypervisor detection.

As for the uniqueness of the table IDs, I guess it would be sane to keep
the same pattern (id+table sig) but allowing the first 4 bytes to be
overridden.

[...]

-- 
Antoine 'xdbob' Damhet

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Michael S. Tsirkin]

On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> > On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
> > > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > > > Hello,
> > > > 
> > > > We recently found out that some softwares are effectively crashing
> > > > when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
> > > > 
> > > > I see no reason not to expose the setting to the user/command-line. A
> > > > previous patch has been submitted in 2015[1] but did not get through
> > > > because (if I understand correctly) using the IDs on the `SLIC`, `BXPC`
> > > > and `RSDT` tables were enough at the time.
> > > > 
> > > > If you agree, I am willing to forward port the patches of M. Jones but I
> > > > need to ask how it would work `Signed-Off`-wise ?
> > > 
> > > On this point, the patch I sent was actually written by
> > > Michael Tokarev, I was only trying to get them upstream.
> > > 
> > > Rich.
> > 
> > I think at least one of the issues is that e.g. UEFI at least
> > seems to assume unique OEM table IDs e.g. for SSDTs.
> > 
> > So let's try to be more specific please, which software
> > crashes, what does it want to see and in which table.
> 
> I'm sorry I cannot give you the name of the crashing software due to a
> company policy. But I can tell you that if either `BOCHS ` or `BXPC` is
> present in any of the tables it will crash. Any (or at least the few
> that I threw at it) other string will work so it seems it's some kind
> of DRM-related hypervisor detection.

Hmm I'm not sure how far we want to go with this. If software vendors
want to detect a hypervisor there will always be a way.
How are we sure we are not starting an arms race here?

Also which of the IDs matter?  OEMID? OEM Table ID? Creator ID?


> As for the uniqueness of the table IDs, I guess it would be sane to keep
> the same pattern (id+table sig) but allowing the first 4 bytes to be
> overridden.
> 
> [...]

It's certainly possible, it's just very specific to just this DRM scheme.
Not sure what's a better way to do it:
  qemu -acpidefault oem_id=ABCD,oem_table_id=EFGHIJKL
is probably going too far since then table IDs are not unique.

Also I'd probably use machine properties for this, the need here
is baroque enough that we don't want a dedicated option.

> 
> -- 
> Antoine 'xdbob' Damhet

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Antoine Damhet]

On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> > On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> > > On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
> > > > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:

[...]

> > 
> > I'm sorry I cannot give you the name of the crashing software due to a
> > company policy. But I can tell you that if either `BOCHS ` or `BXPC` is
> > present in any of the tables it will crash. Any (or at least the few
> > that I threw at it) other string will work so it seems it's some kind
> > of DRM-related hypervisor detection.
> 
> Hmm I'm not sure how far we want to go with this. If software vendors
> want to detect a hypervisor there will always be a way.
> How are we sure we are not starting an arms race here?

We can't but IMHO, as long as we stay within the specs we should be OK.
There are far more obvious checks like the `CPUID[0x1].ECX[31]` which
would destroy most of the PV features in a proprietary OS like Windows
if disabled.

Worst case scenario they would do timing-based detection and that would
be insane to defeat. As for the `Shadow` virtual machines we try to
"play" fair by exposing deterministic values (for example `Shadow` and
`Blade` are clearly exposed in SMBIOS) and don't hide the fact that we
are a virtual machine, so we are easy to ban if the vendor really wishes
to.

> 
> Also which of the IDs matter?  OEMID? OEM Table ID? Creator ID?

I just checked for the Creator ID and it also crash, my guess is that
they dump the tables and look for `BOSH` and `BXPC` patterns anywhere.

PS: we reached-out to the software-vendor which did not acknowledge
    banning VMs but added an entry to their FAQ saying that VMs were not
    supported.

> 
> 
> > As for the uniqueness of the table IDs, I guess it would be sane to keep
> > the same pattern (id+table sig) but allowing the first 4 bytes to be
> > overridden.
> > 
> > [...]
> 
> It's certainly possible, it's just very specific to just this DRM scheme.
> Not sure what's a better way to do it:
>   qemu -acpidefault oem_id=ABCD,oem_table_id=EFGHIJKL
> is probably going too far since then table IDs are not unique.
> 
> Also I'd probably use machine properties for this, the need here
> is baroque enough that we don't want a dedicated option.
> 
> > 
> > -- 
> > Antoine 'xdbob' Damhet
> 

-- 
Antoine 'xdbob' Damhet

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Michael S. Tsirkin]

On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:
> On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> > > On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> > > > On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
> > > > > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> 
> [...]
> 
> > > 
> > > I'm sorry I cannot give you the name of the crashing software due to a
> > > company policy. But I can tell you that if either `BOCHS ` or `BXPC` is
> > > present in any of the tables it will crash. Any (or at least the few
> > > that I threw at it) other string will work so it seems it's some kind
> > > of DRM-related hypervisor detection.
> > 
> > Hmm I'm not sure how far we want to go with this. If software vendors
> > want to detect a hypervisor there will always be a way.
> > How are we sure we are not starting an arms race here?
> 
> We can't but IMHO, as long as we stay within the specs we should be OK.
> There are far more obvious checks like the `CPUID[0x1].ECX[31]` which
> would destroy most of the PV features in a proprietary OS like Windows
> if disabled.
>
> Worst case scenario they would do timing-based detection and that would
> be insane to defeat. As for the `Shadow` virtual machines we try to
> "play" fair by exposing deterministic values (for example `Shadow` and
> `Blade` are clearly exposed in SMBIOS) and don't hide the fact that we
> are a virtual machine, so we are easy to ban if the vendor really wishes
> to.
> 
> > 
> > Also which of the IDs matter?  OEMID? OEM Table ID? Creator ID?
> 
> I just checked for the Creator ID and it also crash, my guess is that
> they dump the tables and look for `BOSH` and `BXPC` patterns anywhere.
> 
> PS: we reached-out to the software-vendor which did not acknowledge
>     banning VMs but added an entry to their FAQ saying that VMs were not
>     supported.

Exactly so I ask myself whether it's worth it, their next version
will check CPUID and then where are we?
But maybe it's time we just changed all these IDs to e.g. QEMU.
We are very far from bochs generated tables by now.
Question is will this cause annoyances with e.g. windows guests?
Igor what's your experience with this?

> 
> > 
> > 
> > > As for the uniqueness of the table IDs, I guess it would be sane to keep
> > > the same pattern (id+table sig) but allowing the first 4 bytes to be
> > > overridden.
> > > 
> > > [...]
> > 
> > It's certainly possible, it's just very specific to just this DRM scheme.
> > Not sure what's a better way to do it:
> >   qemu -acpidefault oem_id=ABCD,oem_table_id=EFGHIJKL
> > is probably going too far since then table IDs are not unique.
> > 
> > Also I'd probably use machine properties for this, the need here
> > is baroque enough that we don't want a dedicated option.
> > 
> > > 
> > > -- 
> > > Antoine 'xdbob' Damhet
> > 
> 
> -- 
> Antoine 'xdbob' Damhet

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Antoine Damhet]

On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:
> > On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> > > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> > > > On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> > > > > On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
> > > > > > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:

[...]

> Exactly so I ask myself whether it's worth it, their next version
> will check CPUID and then where are we?

Then I guess they will have to admit that they are purposefully blocking
VM use and it's not our problem anymore.

> But maybe it's time we just changed all these IDs to e.g. QEMU.
> We are very far from bochs generated tables by now.

That's a good idea, but I still think they should be user override-able
(unless you think it would be a heavy maintenance burden, in that case
you are king in your castle :D )

> Question is will this cause annoyances with e.g. windows guests?

Windows 10 guests seems unaffected, I cannot say for the other
versions/servers editions.

> Igor what's your experience with this?

[...]

-- 
Antoine 'xdbob' Damhet

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Michael S. Tsirkin]

On Thu, Nov 26, 2020 at 05:34:50PM +0100, Antoine Damhet wrote:
> On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote:
> > On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:
> > > On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> > > > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> > > > > On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> > > > > > On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
> > > > > > > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> 
> [...]
> 
> > Exactly so I ask myself whether it's worth it, their next version
> > will check CPUID and then where are we?
> 
> Then I guess they will have to admit that they are purposefully blocking
> VM use and it's not our problem anymore.
> 
> > But maybe it's time we just changed all these IDs to e.g. QEMU.
> > We are very far from bochs generated tables by now.
> 
> That's a good idea, but I still think they should be user override-able
> (unless you think it would be a heavy maintenance burden, in that case
> you are king in your castle :D )
> 
> > Question is will this cause annoyances with e.g. windows guests?
> 
> Windows 10 guests seems unaffected, I cannot say for the other
> versions/servers editions.

unaffected yes, but what about things like reactivation,
warning about system changes at boot or reinstalling
drivers? changing acpi significantly does this sometimes ...

> > Igor what's your experience with this?
> 
> [...]
> 
> -- 
> Antoine 'xdbob' Damhet

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Igor Mammedov]

On Thu, 26 Nov 2020 12:05:27 -0500
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Thu, Nov 26, 2020 at 05:34:50PM +0100, Antoine Damhet wrote:
> > On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote:  
> > > On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:  
> > > > On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:  
> > > > > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:  
> > > > > > On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:  
> > > > > > > On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:  
> > > > > > > > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:  
> > 
> > [...]
> >   
> > > Exactly so I ask myself whether it's worth it, their next version
> > > will check CPUID and then where are we?  
> > 
> > Then I guess they will have to admit that they are purposefully blocking
> > VM use and it's not our problem anymore.
> >   
> > > But maybe it's time we just changed all these IDs to e.g. QEMU.
> > > We are very far from bochs generated tables by now.  
> > 
> > That's a good idea, but I still think they should be user override-able
> > (unless you think it would be a heavy maintenance burden, in that case
> > you are king in your castle :D )
> >   
> > > Question is will this cause annoyances with e.g. windows guests?  
> > 
> > Windows 10 guests seems unaffected, I cannot say for the other
> > versions/servers editions.  
> 
> unaffected yes, but what about things like reactivation,
> warning about system changes at boot or reinstalling
> drivers? changing acpi significantly does this sometimes ...

that's what I'd think might happen, with some old Windows version
but I don't have any proof wrt it.

> 
> > > Igor what's your experience with this?  
> > 
> > [...]
> > 
> > -- 
> > Antoine 'xdbob' Damhet  
> 
> 

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Michael S. Tsirkin]

On Thu, Nov 26, 2020 at 05:34:50PM +0100, Antoine Damhet wrote:
> On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote:
> > On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:
> > > On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> > > > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> > > > > On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> > > > > > On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
> > > > > > > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> 
> [...]
> 
> > Exactly so I ask myself whether it's worth it, their next version
> > will check CPUID and then where are we?
> 
> Then I guess they will have to admit that they are purposefully blocking
> VM use and it's not our problem anymore.
> 
> > But maybe it's time we just changed all these IDs to e.g. QEMU.
> > We are very far from bochs generated tables by now.
> 
> That's a good idea, but I still think they should be user override-able
> (unless you think it would be a heavy maintenance burden, in that case
> you are king in your castle :D )

Fundamentally there's a chance that if you get unlucky
with your OEM ID some software somewhere will look for
it and try to activate some vendor specific behaviour.
So giving users full control here isn't all that safe ...

Question btw, are you also supplying a SLIC table?


> > Question is will this cause annoyances with e.g. windows guests?
> 
> Windows 10 guests seems unaffected, I cannot say for the other
> versions/servers editions.
> 
> > Igor what's your experience with this?
> 
> [...]
> 
> -- 
> Antoine 'xdbob' Damhet

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Antoine Damhet]

On Thu, Nov 26, 2020 at 12:09:13PM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 26, 2020 at 05:34:50PM +0100, Antoine Damhet wrote:
> > On Thu, Nov 26, 2020 at 08:29:41AM -0500, Michael S. Tsirkin wrote:
> > > On Thu, Nov 26, 2020 at 01:50:12PM +0100, Antoine Damhet wrote:
> > > > On Thu, Nov 26, 2020 at 06:09:11AM -0500, Michael S. Tsirkin wrote:
> > > > > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> > > > > > On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> > > > > > > On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
> > > > > > > > On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> > 
> > [...]
> > 
> > > Exactly so I ask myself whether it's worth it, their next version
> > > will check CPUID and then where are we?
> > 
> > Then I guess they will have to admit that they are purposefully blocking
> > VM use and it's not our problem anymore.
> > 
> > > But maybe it's time we just changed all these IDs to e.g. QEMU.
> > > We are very far from bochs generated tables by now.
> > 
> > That's a good idea, but I still think they should be user override-able
> > (unless you think it would be a heavy maintenance burden, in that case
> > you are king in your castle :D )
> 
> Fundamentally there's a chance that if you get unlucky
> with your OEM ID some software somewhere will look for
> it and try to activate some vendor specific behaviour.
> So giving users full control here isn't all that safe ...
> 
> Question btw, are you also supplying a SLIC table?

In production we do not, I've only toyed with adding a dummy table to
see if the `oem_id` and `oem_table_id` there were enough.

> 
> 
> > > Question is will this cause annoyances with e.g. windows guests?
> > 
> > Windows 10 guests seems unaffected, I cannot say for the other
> > versions/servers editions.
> > 
> > > Igor what's your experience with this?
> > 
> > [...]
> > 
> > -- 
> > Antoine 'xdbob' Damhet
> 

-- 
Antoine 'xdbob' Damhet

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Laszlo Ersek]

On 11/26/20 12:09, Michael S. Tsirkin wrote:
> On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
>> On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
>>> On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
>>>> On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
>>>>> Hello,
>>>>>
>>>>> We recently found out that some softwares are effectively crashing
>>>>> when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
>>>>>
>>>>> I see no reason not to expose the setting to the user/command-line. A
>>>>> previous patch has been submitted in 2015[1] but did not get through
>>>>> because (if I understand correctly) using the IDs on the `SLIC`, `BXPC`
>>>>> and `RSDT` tables were enough at the time.
>>>>>
>>>>> If you agree, I am willing to forward port the patches of M. Jones but I
>>>>> need to ask how it would work `Signed-Off`-wise ?
>>>>
>>>> On this point, the patch I sent was actually written by
>>>> Michael Tokarev, I was only trying to get them upstream.
>>>>
>>>> Rich.
>>>
>>> I think at least one of the issues is that e.g. UEFI at least
>>> seems to assume unique OEM table IDs e.g. for SSDTs.
>>>
>>> So let's try to be more specific please, which software
>>> crashes, what does it want to see and in which table.
>>
>> I'm sorry I cannot give you the name of the crashing software due to a
>> company policy. But I can tell you that if either `BOCHS ` or `BXPC` is
>> present in any of the tables it will crash. Any (or at least the few
>> that I threw at it) other string will work so it seems it's some kind
>> of DRM-related hypervisor detection.
> 
> Hmm I'm not sure how far we want to go with this. If software vendors
> want to detect a hypervisor there will always be a way.
> How are we sure we are not starting an arms race here?
> 
> Also which of the IDs matter?  OEMID? OEM Table ID? Creator ID?
> 
> 
>> As for the uniqueness of the table IDs, I guess it would be sane to keep
>> the same pattern (id+table sig) but allowing the first 4 bytes to be
>> overridden.
>>
>> [...]
> 
> It's certainly possible, it's just very specific to just this DRM scheme.
> Not sure what's a better way to do it:
>   qemu -acpidefault oem_id=ABCD,oem_table_id=EFGHIJKL
> is probably going too far since then table IDs are not unique.
> 
> Also I'd probably use machine properties for this, the need here
> is baroque enough that we don't want a dedicated option.

Minimally, I dislike the partial overlap with the existent "-acpitable"
switch.

Thanks
Laszlo

> 
>>
>> -- 
>> Antoine 'xdbob' Damhet
> 

Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.

[Michael S. Tsirkin]

On Thu, Nov 26, 2020 at 01:51:43PM +0100, Laszlo Ersek wrote:
> On 11/26/20 12:09, Michael S. Tsirkin wrote:
> > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> >> On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> >>> On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
> >>>> On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> >>>>> Hello,
> >>>>>
> >>>>> We recently found out that some softwares are effectively crashing
> >>>>> when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
> >>>>>
> >>>>> I see no reason not to expose the setting to the user/command-line. A
> >>>>> previous patch has been submitted in 2015[1] but did not get through
> >>>>> because (if I understand correctly) using the IDs on the `SLIC`, `BXPC`
> >>>>> and `RSDT` tables were enough at the time.
> >>>>>
> >>>>> If you agree, I am willing to forward port the patches of M. Jones but I
> >>>>> need to ask how it would work `Signed-Off`-wise ?
> >>>>
> >>>> On this point, the patch I sent was actually written by
> >>>> Michael Tokarev, I was only trying to get them upstream.
> >>>>
> >>>> Rich.
> >>>
> >>> I think at least one of the issues is that e.g. UEFI at least
> >>> seems to assume unique OEM table IDs e.g. for SSDTs.
> >>>
> >>> So let's try to be more specific please, which software
> >>> crashes, what does it want to see and in which table.
> >>
> >> I'm sorry I cannot give you the name of the crashing software due to a
> >> company policy. But I can tell you that if either `BOCHS ` or `BXPC` is
> >> present in any of the tables it will crash. Any (or at least the few
> >> that I threw at it) other string will work so it seems it's some kind
> >> of DRM-related hypervisor detection.
> > 
> > Hmm I'm not sure how far we want to go with this. If software vendors
> > want to detect a hypervisor there will always be a way.
> > How are we sure we are not starting an arms race here?
> > 
> > Also which of the IDs matter?  OEMID? OEM Table ID? Creator ID?
> > 
> > 
> >> As for the uniqueness of the table IDs, I guess it would be sane to keep
> >> the same pattern (id+table sig) but allowing the first 4 bytes to be
> >> overridden.
> >>
> >> [...]
> > 
> > It's certainly possible, it's just very specific to just this DRM scheme.
> > Not sure what's a better way to do it:
> >   qemu -acpidefault oem_id=ABCD,oem_table_id=EFGHIJKL
> > is probably going too far since then table IDs are not unique.
> > 
> > Also I'd probably use machine properties for this, the need here
> > is baroque enough that we don't want a dedicated option.
> 
> Minimally, I dislike the partial overlap with the existent "-acpitable"
> switch.
> 
> Thanks
> Laszlo

Well the existing -acpitable is very powerful and easy to break guests
with, it can not really be fully supported.

> > 
> >>
> >> -- 
> >> Antoine 'xdbob' Damhet
> >