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]

Message-ID: <fe8940ff-9deb-1b2b-8f30-2ecfe26ce27b@amazon.com>
Date:   Mon, 27 Apr 2020 12:22:15 +0300
From:   "Paraschiv, Andra-Irina" <andraprs@...zon.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Alexander Graf <graf@...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 25/04/2020 19:05, Paolo Bonzini wrote:
>
> On 24/04/20 21:11, Alexander Graf wrote:
>> What I was saying above is that maybe code is easier to transfer that
>> than a .txt file that gets lost somewhere in the Documentation directory
>> :).
> whynotboth.jpg :D

:) Alright, I added it to the list, in addition to the sample we've been 
talking before, with the basic flow of the ioctl interface usage.

>
>>>> To answer the question though, the target file is in a newly invented
>>>> file format called "EIF" and it needs to be loaded at offset 0x800000 of
>>>> the address space donated to the enclave.
>>> What is this EIF?
>> It's just a very dumb container format that has a trivial header, a
>> section with the bzImage and one to many sections of initramfs.
>>
>> As mentioned earlier in this thread, it really is just "-kernel" and
>> "-initrd", packed into a single binary for transmission to the host.
> Okay, got it.  So, correct me if this is wrong, the information that is
> needed to boot the enclave is:
>
> * the kernel, in bzImage format
>
> * the initrd
>
> * a consecutive amount of memory, to be mapped with
> KVM_SET_USER_MEMORY_REGION

Yes, the kernel bzImage, the kernel command line, the ramdisk(s) are 
part of the Enclave Image Format (EIF); plus an EIF header including 
metadata such as magic number, eif version, image size and CRC.

>
> Off list, Alex and I discussed having a struct that points to kernel and
> initrd off enclave memory, and have the driver build EIF at the
> appropriate point in enclave memory (the 8 MiB ofset that you mentioned).
>
> This however has two disadvantages:
>
> 1) having the kernel and initrd loaded by the parent VM in enclave
> memory has the advantage that you save memory outside the enclave memory
> for something that is only needed inside the enclave

Here you wanted to say disadvantage? :)Wrt saving memory, it's about 
additional memory from the parent / primary VM needed for handling the 
enclave image sections (such as the kernel, ramdisk) and setting the EIF 
at a certain offset in enclave memory?

>
> 2) it is less extensible (what if you want to use PVH in the future for
> example) and puts in the driver policy that should be in userspace.
>
>
> So why not just start running the enclave at 0xfffffff0 in real mode?
> Yes everybody hates it, but that's what OSes are written against.  In
> the simplest example, the parent enclave can load bzImage and initrd at
> 0x10000 and place firmware tables (MPTable and DMI) somewhere at
> 0xf0000; the firmware would just be a few movs to segment registers
> followed by a long jmp.
>
> If you want to keep EIF, we measured in QEMU that there is no measurable
> difference between loading the kernel in the host and doing it in the
> guest, so Amazon could provide an EIF loader stub at 0xfffffff0 for
> backwards compatibility.

Thanks for info.

Andra

>
>>> Again, I cannot provide a sensible review without explaining how to use
>>> all this.  I understand that Amazon needs to do part of the design
>>> behind closed doors, but this seems to have the resulted in issues that
>>> reminds me of Intel's SGX misadventures. If Amazon has designed NE in a
>>> way that is incompatible with open standards, it's up to Amazon to fix
>> Oh, if there's anything that conflicts with open standards here, I would
>> love to hear it immediately. I do not believe in security by obscurity  :).
> That's great to hear!
>
> Paolo
>




Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.