I have a Lenovo ThinkPad P16 Gen2 with two hard disks. One of them has Windows 10 installed and the other one Qubes OS. Are there any securities implications using this configuration?
I would want to avoid untrusted software (Windows 10) from being able to tamper with the bootloader used by Qubes. Maybe you could move the bootloader used by Qubes to an external disk that is not plugged in when Windows 10 is running. How to secure the boot process is a very big and highly nuanced problem on its own. Where that problem is thoroughly solved, Windows 10 (or any other malware) is a nuisance at best.
Would running Windows 10 in a qube work for you? If not, please share (if you are in a position to) why not so others can find a fix or workaround.
If you are trying to play games, that’s understandable, the advice you’ll get from more experienced IT security people is if you want to run Windows to play games you should dedicate a separate computer for that.
Yes:
The main reason I want windows running on a separate hard disk is for bios and firmware updates, through lenovo vantage application, and because I do not want to install any software in dom0. As far as I understand, to run windows vm properly you need to install some piece of codes in dom0, does it?
P.D. Thanks for your reply.
Thanks for the info
See if you can download firmware updates from the OEM’s site. Sometimes an OEM has a bootable ISO you can dd of=some_usb_stick
. Some other OEM (like Dell) release firmware as a file to be placed on a FAT32 filesystem on a GPT disk slice (of any name/label) that is then read by the existing firmware.
In most cases you can update firmware without Windows. Some machine owners intentionally want the chipset to not accept firmware updates from whatever operating system is running. Some do firmware updates manually to avoid unwanted updates.
If you are using Qubes because you want a reasonably secure OS, you may also want to put some serious consideration on how well OEM-distributed firmware performs in that area. The trust issue is a big issue on its own. In my view the performance of OEM-provided firmware is not satisfactory in most cases.
You may want to know https://www.dasharo.com/ and GitHub - oreboot/oreboot: oreboot is a fork of coreboot, with C removed, written in Rust. exist.
Also noteworthy: Open OS Platform Interoperability - Asahi Linux Documentation