help-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Renz
Subject: Re: Combining Hurd and Qubes OS for security reasons? Possible?
Date: Wed, 23 Dec 2015 15:12:55 +0100

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 <sun.kisses.horizon@gmail.com> wrote:

Am 23.12.2015 09:20 schrieb "Arne Babenhauserheide" <arne_bab@web.de>:
>
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]