Re: Combining Hurd and Qubes OS for security reasons? Possible?

[Richard Braun]

On Tue, Dec 22, 2015 at 06:05:07PM +0100, David Renz wrote:
> The ACPI system is a subsystem of the BIOS, which itself is patchable
> firmware. I would never exclude the chance that ACPI code could get
> executed, no matter which OS one is using actually - There are also PCI
> devices containing (patchable) firmware etc.
> 
> Unless one would be using an open-hardware/openBIOS based system, I don't
> think that security could be achieved on modern (x64) hardware with all its
> patchable firmware components. You can only 'limit the attack surface'
> otherwise - That approach might work or not. I'm certainly not a fan of
> Shuttleworth, but in my opinion he summarizes this whole issue quite well:
> https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Security_risks
> 
> As far as I know, the Raspberry PI does not contain any hardware component,
> whose firmware could be 'patched' without having physical access to it, so
> maybe that would be a starting point (or any other system, where this is
> applicable).
> 
> Then you would still have to deal with software based exploits, but at
> least one could fix those once having detected them. But if your system
> contains hardware with 'patched' firmware, this would be far more difficult
> if not even impossible.

Not being able to easily update firmwares isn't acceptable nowadays.
Having code running on the hardware is actually perfectly acceptable,
as long as you are aware and accept that these are small systems of
their own. You just can't prevent firmwares from doing all sorts of
things unless you also accept to severly restrict what future updates
can do.

The real problem is actually not the firmware itself. The problem is
that the firmware often has access to more than it needs, on the basis
that, as a hardware component, it is considered part of the trusted
computing base. This means it can access all physical memory. The
real solution for this problem, which mixes very well with a
multi-server design such as the Hurd, is to use IOMMUs. In the Hurd
world, an I/O server would provide access to memory ranges through
capabilities and mappings, programming the IOMMU accordingly, in
a way very similar to the classic MMU with per-process mappings,
so that devices are restricted in what they can access.

In the case of ACPI though, I'm not sure whether IOMMUs actually
enforce access verification in system management mode, but if it
does, a properly implemented multi-server system with IOMMU
hardware should be able to provide a high level of security
despite those shortcomings.

-- 
Richard Braun