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

Just one of many interesting articles addressing this issue:
http://www.toucan-system.com/research/blackhat2012_brossard_hardware_backdooring.pdf



Best wishes and merry Christmas to everyone


On Wed, Dec 23, 2015 at 11:56 AM, David Renz <[email protected]>
wrote:

> Am 23.12.2015 09:20 schrieb "Arne Babenhauserheide" <[email protected]>:
> >
> > Am Dienstag, 22. Dezember 2015, 18:34:16 schrieb Richard Braun:
> > > On Tue, Dec 22, 2015 at 06:05:07PM +0100, David Renz wrote:
> > > > Unless one would be using an open-hardware/openBIOS based system, I
> don't
> > > …
> > > 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.
> >
> > Taking out all the details in-between it sounds like you pretty much
> > agree (at least on the big picture). If the code on the hardware is a
> > small system of its own, then it should be free software, which means
> > it would run openBIOS.
> >
> > > 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.
> >
> > So you mean that with the Hurd it might be possible to get a trusted
> > system despite having some unfree components?
> >
> > Best wishes,
> > Arne
>
> I didn't want to write this, but that's how it is (concluding that this is
> not possible with some unfree firmware components).
>
> I see two ways out of that:
> 1) One could easily use two separate systems for two different purposes:
> Use one system, which doesn't provide any networking capability, for
> productivity etc. (Or use a system which is online, but keep in mind that
> you shouldn't use it for online communication others shouldn't be able to
> intercept.)
> 2) Use a Raspberry Pi running OpenBSD (just as an example, there would be
> numerous other solutions) for encrypting/decrypting and receiving/sending
> communication.
>
> The other approach would be using a system running openBIOS, so you could
> combine both things. I can't evaluate how realistic this would be, since
> you would also have to think of patchable firmware in PCI etc. components.
> Running openBIOS should be a basic premise for a 'secure' x86 system
> however.
> You can under no circumstances get a secure system running on one or
> multiple "system(s) of its/their own", because - as you have said it very
> precisely - you have no control over this.
>