Groups | Search | Server Info | Login | Register


Groups > gnu.hurd.help > #359

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

From Richard Braun <rbraun@sceen.net>
Newsgroups gnu.hurd.help
Subject Re: Combining Hurd and Qubes OS for security reasons? Possible?
Date 2015-12-23 16:35 +0100
Message-ID <mailman.458.1450884943.843.help-hurd@gnu.org> (permalink)
References <CAB=Lj3T9dABDCnfiPFmui45WdZSVvpGs6rMX=PBVR6O94Es-Ug@mail.gmail.com> <CAB=Lj3T9C+fMQm=dLy6OV2zwBE2DpX61+9KV6QCveRjiSABMOQ@mail.gmail.com> <20151222173416.GA13375@shattrath> <36276357.nTXJbVLR9C@fluss>

Show all headers | View raw


On Wed, Dec 23, 2015 at 09:20:37AM +0100, Arne Babenhauserheide wrote:
> 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.

No, I mean people must be aware they can't trust it if it's not open
source. But the same way admins don't trust user processes and use the
kernel to enforce boundaries, your hardware can also do it.

> > 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?

I only mean that the Hurd is more suitable to protect the system from
individual drivers than a monolithic system.

-- 
Richard Braun

Back to gnu.hurd.help | Previous | Next | Find similar


Thread

Re: Combining Hurd and Qubes OS for security reasons? Possible? Richard Braun <rbraun@sceen.net> - 2015-12-23 16:35 +0100

csiph-web