Groups | Search | Server Info | Login | Register
| 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> |
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
Re: Combining Hurd and Qubes OS for security reasons? Possible? Richard Braun <rbraun@sceen.net> - 2015-12-23 16:41 +0100
csiph-web