All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Antoine Damhet <antoine.damhet@blade-group.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
	lersek@redhat.com, "Richard W.M. Jones" <rjones@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.
Date: Thu, 26 Nov 2020 08:29:41 -0500	[thread overview]
Message-ID: <20201126082606-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20201126125012.x6yzsou5rmlxagli@tartarus>

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



  reply	other threads:[~2020-11-26 13:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-25 13:27 [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set Antoine Damhet
2020-11-25 13:32 ` Richard W.M. Jones
2020-11-25 16:04   ` Michael S. Tsirkin
2020-11-25 20:13     ` Antoine Damhet
2020-11-26 11:09       ` Michael S. Tsirkin
2020-11-26 12:50         ` Antoine Damhet
2020-11-26 13:29           ` Michael S. Tsirkin [this message]
2020-11-26 16:34             ` Antoine Damhet
2020-11-26 17:05               ` Michael S. Tsirkin
2020-11-26 19:41                 ` Igor Mammedov
2020-11-26 17:09               ` Michael S. Tsirkin
2020-11-26 17:37                 ` Antoine Damhet
2020-11-26 12:51         ` Laszlo Ersek
2020-11-26 13:25           ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201126082606-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=antoine.damhet@blade-group.com \
    --cc=imammedo@redhat.com \
    --cc=lersek@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.