Sure you could spend the rest of your life checking all the firmware and trying to design separate specialized tools for the myriad of devices in a modern PC - and there is a lot more than your simple list, see the presentation Mickey Shkatov and Jesse Michael from Intel did which enumerated some of the attack vectors. The list is much longer than your short list - and some of it is impossible to verify on today's hardware. Or you could build a diagnostic into your kernel and identify problems as a heuristic and aid.
But I get it, it's hard, so you can throw up your hands and give up by saying that's not our problem, not an OS issue. However at the end of the day, it is a user issue, and a system security problem. If you aren't paranoid enough to worry about it, then you've already lost. Cheers, --dr -----Original Message----- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Peter Kay Sent: December 23, 2015 12:37 AM To: Dragos Ruiu <d...@kyx.net>; 'Read, James C' <jcr...@essex.ac.uk>; 'Theo de Raadt' <dera...@cvs.openbsd.org>; Dragos Ruiu <d...@kyx.net>; 'Read, James C' <jcr...@essex.ac.uk>; 'Theo de Raadt' <dera...@cvs.openbsd.org> Cc: 'OpenBSD general usage list' <misc@openbsd.org>; 'OpenBSD general usage list' <misc@openbsd.org> Subject: Re: Boot loader uses INT 13h [WAS BIOS call fallback] On 23 December 2015 02:04:01 GMT+00:00, Dragos Ruiu <d...@kyx.net> wrote: >I would be interested in any code that can knowingly break inside a VM >to verify unvirtualized status, esp. on Skylake. Older processors can >probably use the virtualization bugs in the hardware for this function. Who cares? Yes, there will be processor quirks that can be used, and often hypercalls to verify you're running under a hypervisor. Beyond that, a VM has a large degree of difference from a physical PC - I would not be confident of hiding this from the OS. It's not OpenBSD's problem, though. If you don't know if you're running in a VM the most probable causes are trojaned install media (to the point it verifies the hash) or a hacked BIOS. If it's a BIOS you need to verify the BIOS, the NIC boot ROM, the graphics card ROM, the disk controller ROM, the disk drive itself, and any remote access/baseboard management controller that exists. If you're that paranoid, you need a specific tool to find the source of the issue, not OpenBSD
