linux-kernel - Re: [PATCH v1 00/15] Add support for Nitro Enclaves

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Apr 2020 13:47:13 +0200
From:   Alexander Graf <graf@...zon.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        "Paraschiv, Andra-Irina" <andraprs@...zon.com>,
        <linux-kernel@...r.kernel.org>
CC:     Anthony Liguori <aliguori@...zon.com>,
        Benjamin Herrenschmidt <benh@...zon.com>,
        Colm MacCarthaigh <colmmacc@...zon.com>,
        Bjoern Doebel <doebel@...zon.de>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Frank van der Linden <fllinden@...zon.com>,
        Martin Pohlack <mpohlack@...zon.de>,
        Matt Wilson <msw@...zon.com>, Balbir Singh <sblbir@...zon.com>,
        Stewart Smith <trawets@...zon.com>,
        Uwe Dannowski <uwed@...zon.de>, <kvm@...r.kernel.org>,
        <ne-devel-upstream@...zon.com>
Subject: Re: [PATCH v1 00/15] Add support for Nitro Enclaves

On 30.04.20 13:38, Paolo Bonzini wrote:
> 
> On 30/04/20 13:21, Alexander Graf wrote:
>>> Also, would you consider a mode where ne_load_image is not invoked and
>>> the enclave starts in real mode at 0xffffff0?
>>
>> Consider, sure. But I don't quite see any big benefit just yet. The
>> current abstraction level for the booted payloads is much higher. That
>> allows us to simplify the device model dramatically: There is no need to
>> create a virtual flash region for example.
> 
> It doesn't have to be flash, it can be just ROM.
> 
>> In addition, by moving firmware into the trusted base, firmware can
>> execute validation of the target image. If you make it all flat, how do
>> you verify whether what you're booting is what you think you're booting?
> 
> So the issue would be that a firmware image provided by the parent could
> be tampered with by something malicious running in the parent enclave?

You have to have a root of trust somewhere. That root then checks and 
attests everything it runs. What exactly would you attest for with a 
flat address space model?

So the issue is that the enclave code can not trust its own integrity if 
it doesn't have anything at a higher level attesting it. The way this is 
usually solved on bare metal systems is that you trust your CPU which 
then checks the firmware integrity (Boot Guard). Where would you put 
that check in a VM model? How close would it be to a normal VM then? And 
if it's not, what's the point of sticking to such terrible legacy boot 
paths?

Alex

Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879