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