zlacker

>>jerhei+(OP)
An excellent point that applies to almost any system:

The inconvenient and somehow embarrassing truth for us – the malware experts – is that there does not exist any reliable method to determine if a given system is not compromised.

>>hackus+NI1
This is true for x86-based desktops Qubes targets. You might get past this if you can tolerate a console-like experience with lower-risk hardware. One example is where the state is read-only without physical modification of the machine such as changing a jumper or flipping a switch. Alternatively a combo of ROM and flash where the ROM is immutable but loads signed flash with a correct-by-construction, heavily-pentested module. Apply to various chips in the design. Read-only memory for firmware protection dates back to a mainframe in the 1970's where you had to physically pull old one out and put new one in. OS was built on top of the "Nucleus" API in that for consistency. Microsoft mostly copied that in VerveOS's Nucleus but minus read-only firmware.

An old trick that researchers and implementors should breath more life into. The hardware companies like the more mutable storage for financial reasons. Customers aren't big on replacing hardware but security-focused ones might go with pluggable ROM's long as ROM's aren't changed often. Hence, correct-by-construction approaches that cause few to no defects.

>>nickps+eJ1
> One example is where the state is read-only without physical modification of the machine such as changing a jumper or flipping a switch.

Joanna Rutkowska, the main developer of Qubes OS, has an article about it and probably is working hard on the implementation for x86 laptops:

https://blog.invisiblethings.org/2015/12/23/state_harmful.ht...