Bug 78312 - Microsoft Surface tablet detected as Virtual Machine through sysfs DMI string
Summary: Microsoft Surface tablet detected as Virtual Machine through sysfs DMI string
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-05 21:42 UTC by Reyad Attiyat
Modified: 2014-05-24 06:40 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
[PATCH] Remove Microsft DMI string from virtual detection (1.03 KB, text/plain)
2014-05-05 21:42 UTC, Reyad Attiyat
Details

Description Reyad Attiyat 2014-05-05 21:42:25 UTC
Created attachment 98517 [details]
[PATCH] Remove Microsft DMI string from virtual detection

I have a Microsoft Surface 2 table and it is being detected as a virtual machine with the Visualization attribute set to "microsoft". It is my understanding that Microsoft offers virtuosity support via Hyper-V, and systemd detects for this by checking cpuinfo and /sys/class/dmi/id/ sysinfo strings. 

These heuristics incorrectly identity my device as a virtual machine because the string "Microsoft Corporation\0" is found in /sys/class/dmi/id/board_vendor and sys_vendor.

I have attached the a patch that removes this string from the array dmi_vendor_table[]. Other possible solutions might be to send a kernel command argument, or do more sophisticated DMI testing to ensure Hyper-V presence and not a real hw device.

The only negative side effects I experienced by this bug were gnome-settings-daemon would disable suspend but there might be other services that act differently because of this.
Comment 1 David Strauss 2014-05-06 00:13:21 UTC
It seems like this patch would switch the bug to failing to detect Hyper-V when present, unless there's reason to believe this check is redundant.
Comment 2 Reyad Attiyat 2014-05-06 05:49:03 UTC
Sorry about the initial comment it contains so many wording/spelling errors.

(In reply to comment #1)
> It seems like this patch would switch the bug to failing to detect Hyper-V
> when present, unless there's reason to believe this check is redundant.

I have tested Fedora 20 in a Hyper-V VM and it gets detected by the cpuid x86 instructions and does not ever check the DMI values. These Microsoft hypervisor detection steps can be found here (link found in source code comment):
http://www.microsoft.com/en-ca/download/details.aspx?id=39289
as well as here:
http://lwn.net/Articles/301888/

Should this cpuid method be enough to detect Hyper-V? I can't really think of any other device that would have a Microsoft BIOS/EFI.

I also checked the DMI information in the Hyper-V VM. The /sys/class/dmi/id/bios_vendor reads "American Megatrends Inc." on both the surface tablet and virtual machine. I was hoping this could be used to differentiate virtual from real hardware. The values that did differ were /sys/class/dmi/id/product_name and /sys/class/dmi/id/board_name. They read "Virtual Machine" when on the vm. Would it make more sense, instead of deleting the DMI Microsoft vendor string , to also check if board_name is equal to "Virtual Machine"?
Comment 3 David Strauss 2014-05-06 19:14:37 UTC
> Would it make more sense, instead of deleting the DMI Microsoft vendor string, to also check if board_name is equal to "Virtual Machine"?

This isn't my normal area of systemd to work in, but that seems like a higher confidence fix than removing the check entirely. It's unlikely to have any false positives, and it may have fewer false negatives.
Comment 4 Lennart Poettering 2014-05-24 06:40:25 UTC
Applied! Thanks!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.