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 for Android: free password hash cracker in your pocket

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

Message-ID: <702b2eaa-e425-204e-e19d-649282bfe170@amazon.com>
Date:   Thu, 30 Apr 2020 13:21:08 +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 12:34, Paolo Bonzini wrote:
> 
> On 28/04/20 17:07, Alexander Graf wrote:
>>
>> Why don't we build something like the following instead?
>>
>>    vm = ne_create(vcpus = 4)
>>    ne_set_memory(vm, hva, len)
>>    ne_load_image(vm, addr, len)
>>    ne_start(vm)
>>
>> That way we would get the EIF loading into kernel space. "LOAD_IMAGE"
>> would only be available in the time window between set_memory and start.
>> It basically implements a memcpy(), but it would completely hide the
>> hidden semantics of where an EIF has to go, so future device versions
>> (or even other enclave implementers) could change the logic.
> 
> Can we add a file format argument and flags to ne_load_image, to avoid
> having a v2 ioctl later?

I think flags along should be enough, no? A new format would just be a flag.

That said, any of the commands above should have flags IMHO.

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

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 in a nutshell, for a PV virtual machine spawning interface, I think 
it would make sense to have memory fully owned by the parent. In the 
enclave world, I would rather not like to give the parent too much 
control over what memory actually means, outside of donating a bucket of it.

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