Path: csiph.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.glorb.com!usenet.stanford.edu!not-for-mail From: Richard Braun Newsgroups: gnu.hurd.help Subject: Re: Combining Hurd and Qubes OS for security reasons? Possible? Date: Tue, 22 Dec 2015 18:34:16 +0100 Lines: 50 Approved: help-hurd@gnu.org Message-ID: References: <20151219222843.GQ4287@var.home> <20151222155935.GA24599@shattrath> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: usenet.stanford.edu 1450805662 18095 208.118.235.17 (22 Dec 2015 17:34:22 GMT) X-Complaints-To: action@cs.stanford.edu Cc: help-hurd@gnu.org, Samuel Thibault To: David Renz Envelope-to: help-hurd@gnu.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:41d0:c:ada::1 X-BeenThere: help-hurd@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Hurd List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.hurd.help:357 On Tue, Dec 22, 2015 at 06:05:07PM +0100, David Renz wrote: > The ACPI system is a subsystem of the BIOS, which itself is patchable > firmware. I would never exclude the chance that ACPI code could get > executed, no matter which OS one is using actually - There are also PCI > devices containing (patchable) firmware etc. > > Unless one would be using an open-hardware/openBIOS based system, I don't > think that security could be achieved on modern (x64) hardware with all its > patchable firmware components. You can only 'limit the attack surface' > otherwise - That approach might work or not. I'm certainly not a fan of > Shuttleworth, but in my opinion he summarizes this whole issue quite well: > https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Security_risks > > As far as I know, the Raspberry PI does not contain any hardware component, > whose firmware could be 'patched' without having physical access to it, so > maybe that would be a starting point (or any other system, where this is > applicable). > > Then you would still have to deal with software based exploits, but at > least one could fix those once having detected them. But if your system > contains hardware with 'patched' firmware, this would be far more difficult > if not even impossible. 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. You just can't prevent firmwares from doing all sorts of things unless you also accept to severly restrict what future updates can do. The real problem is actually not the firmware itself. The problem is that the firmware often has access to more than it needs, on the basis that, as a hardware component, it is considered part of the trusted computing base. This means it can access all physical memory. The real solution for this problem, which mixes very well with a multi-server design such as the Hurd, is to use IOMMUs. In the Hurd world, an I/O server would provide access to memory ranges through capabilities and mappings, programming the IOMMU accordingly, in a way very similar to the classic MMU with per-process mappings, so that devices are restricted in what they can access. 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. -- Richard Braun