Groups | Search | Server Info | Login | Register


Groups > gnu.hurd.help > #360

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:41 +0100
Message-ID <mailman.459.1450885266.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> <CAB=Lj3Q7zGnNcPh4FeYhmGFexphugE4eouK=b8SC3vm0d0hdDg@mail.gmail.com>

Show all headers | View raw


On Wed, Dec 23, 2015 at 11:56:23AM +0100, David Renz wrote:
> 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.

That's not what I said. First, you don't run a secure system "on one or
multiple systems of their own". You run one system among multiple ones.
Then, that system must have control over memory access because that's
where the data is and that's what you want to protect. Finally, you
need hardware that can actually restrict memory access from devices that
are external from the point of view of that main system and physical
memory.

After reviewing SMM a bit more, it seems to be an x86 processor operating
mode, giving access to normally inaccessible resources, hidden from the
operating system, which means firmwares using that mode actually run on
the main processor, and are subject to neither IOMMU nor MMU restrictions.

If I'm right, it seems you just can't protect an x86 system from firmware
interference.

-- 
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:41 +0100

csiph-web