Какие данные о моем реальном железе знает VirtualBox?

Длинная дискуссия в рассылке на тему того, что и как с этим делать:

Joanna Rutkowska:

I haven't played with it, but see no reasons it should not work. I can imagine we introduce a prefs for VMs (say "generic_cpuid" settable via qvm-prefs) that would be resulting in additional config for cpuid emulation inserted in the config file for such VMs. We would need to agree on good-enough-for-everybody CPUID config and stick to it then. Again, this would be use-able for anon VMs mostly.

However, this will not work for PV VMs, because the CPUID instruction is not a privileged instruction, so malware in a PV VM can always execute this instruction (even if we hooked Xen interface for CPUID-like info to the guest) without trapping into XEN in PV operation.

AFAIU, there are not personal identifying info returned by CPUID, but I can see how this could be used as an additional fingerprinting vector. Thus, perhaps we should consider distributing Whonix workstation template as an HVM template instead of a PVM one? Fortunately we do have templates support for HVMs, so this should be perfectly possible.

However, this will not work for PV VMs, because the CPUID instruction is not a privileged instruction, so malware in a PV VM can always execute this instruction (even if we hooked Xen interface for CPUID-like info to the guest) without trapping into XEN in PV operation.

That's too bad for excluding paravirtualized VMs.

BTW, it should be obvious, but let me point out that any compartmentalizing technology for x86 that is not based on VT-x/AMD-v would be prone to this problem. This is b/c CPUID is an instruction and its execution cannot otherwise be controlled by the OS, other than via VT-x intercept.

A big part of the problem here is that so few people are using Qubes + Whonix, that if 2 AnonVMs got trivially popped (via Firefox, Thunderbird, PDF, IMG, etc) and had the same CPU specs, it would no doubt predictably be the same user/person out in the world using that instance of Qubes + Whonix, since there are probably many more CPU models than such users at this point.

And if there is any personally identifying info/documents/etc inside one of the VMs, then it's a true identity game over for all known AnonVM activity simply tied back to a CPU model.

With GOV netflow and other vast personal activity history, such as technology purchases, software statistics/debug uploads, Qubes HCL report contributions, etc, it only gets easier to filter out key information and potentially infer identity based on 1 single AnonVM compromise.

I'm guessing that this would not limit the speed of the CPU(s) that the HVM is exposed to? Just changes the info/attributes of the AnonVM domain's CPU (including reported MHz?)?

No.

Напишу сюда, чтобы не плодить темы. Посмотрел VirtualBox и заметил несколько неприятных моментов: Кроме уже упомянутой непонятно зачем допущеной разработчиками утечки параметра процессора, утекает и DNS! Я считаю это серьезная уязвимость! Как можно сделать чтобы для VirtualBox DNS был недоступен всегда (как при пустом resolv.conf)?
И общий вопрос: насколько там защищена сеть внутри VirtualBox? То есть когда сеть поднята и доступна одной группе ОС, а в другой, если выключено в конфиге, то реально отрублено без случайных утечек! Тот же вопрос касается маршрутизации, поднимаемой в пределах VirtualBox (как с Whonix).

Намучался я с VB! Кроме упомянутого слива проца, издевается через мышь: Захватывает управление, так что указатель двигается и в хостовой ОС, но кликать можно только в окне какой-то конкретной запущенной в виртуалке ОС. Еще через какое-то время работы фокус указателя мыши сдвигается примерно на размер одного указателя (стрелки) выше. То есть, если, например ткнуть на текст, то курсор окажется строкой выше, хотя, еще раз: указатель ниже! При этом, настройки в закладке мыши (PS2,USB,планшет) никак на этот глюк не влияют(

Ну и кроме этого, как-то странно распределяет ресурсы: На досточно мощном компе, сжирает все! Независимо от процентных полозков ресурсов проца и количества процов. Еще через каждые десять раз запущенные в виртуалке ОС сами по себе вылетают (не закрывается окно, а запущенная ОС либо мертво виснет, либо в этом же окне перезагружается или перезапускается интерфейс).

Я так понимаю, что сама структура виртуалок такова, что этот софт (VB, другие) использует готовые модули в ядре? Такие как: QEMU/KDM и т.п.? А можно ли как-то научиться запускать под этими модулями ОС буквально из консоли? Или может есть какой более легкий (по глюкам) аналог VB?