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

[Alexander Graf]

On 30.04.20 13:58, Paolo Bonzini wrote:
> On 30/04/20 13:47, Alexander Graf wrote:
> > > 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?
>
> In the enclave device driver, I would just limit the attestation to the
> firmware image
>
> So yeah it wouldn't be a mode where ne_load_image is not invoked and
> the enclave starts in real mode at 0xffffff0.  You would still need
> "load image" functionality.
>
> > 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?
>
> The point is that there's already two plausible loaders for the kernel
> (bzImage and ELF), so I'd like to decouple the loader and the image.

The loader is implemented by the enclave device. If it wishes to support 
bzImage and ELF it does that. Today, it only does bzImage though IIRC :).

So yes, they are decoupled? Are you saying you would like to build your 
own code in any way you like? Well, that means we either need to add 
support for another loader in the enclave device or your workloads just 
fakes a bzImage header and gets loaded regardless :).


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