aesmd availability

aesmd availability

[Jarkko Sakkinen]

I noticed that with aesmd the only feasible way to host it is to make a
VM for it because:

- A beter predictable round-trip time for attestation.
- In the worst case, attestation could be potentially blocked.

Should the driver have a page locking mechanism to make this more robust,
or do we want to satisfy to this? I'm not 100% sure what'd be the right
path forward, just pointing out a potential availability issue.

BR, Jarkko

Re: aesmd availability

[Jarkko Sakkinen]

On Fri, Jan 28, 2022 at 12:08:07PM +0200, Jarkko Sakkinen wrote:
> I noticed that with aesmd the only feasible way to host it is to make a
> VM for it because:
> 
> - A beter predictable round-trip time for attestation.
> - In the worst case, attestation could be potentially blocked.
> 
> Should the driver have a page locking mechanism to make this more robust,
> or do we want to satisfy to this? I'm not 100% sure what'd be the right
> path forward, just pointing out a potential availability issue.

Probably makes sense to spread just a bit :-)

BR, Jarkko

Re: aesmd availability

[Haitao Huang]

Hi Jarkko

On Fri, 28 Jan 2022 05:50:22 -0600, Jarkko Sakkinen <jarkko@kernel.org>  
wrote:

> On Fri, Jan 28, 2022 at 12:08:07PM +0200, Jarkko Sakkinen wrote:
>> I noticed that with aesmd the only feasible way to host it is to make a
>> VM for it because:
>>
>> - A beter predictable round-trip time for attestation.
>> - In the worst case, attestation could be potentially blocked.
>>

I don't fully understand your description here. Based on what you said  
below, I think you are talking about how to improve (control of) EPC  
allocation for apps in case of over-subscription (i.e., when EPC runs  
out). My comments below are with this understanding.

In case you think there are limitations of aesmd implementation that  
prevent aesmd from being hosted in other than a separate VM, please create  
an issue on the corresponding GitHub.

>> Should the driver have a page locking mechanism to make this more  
>> robust,
>> or do we want to satisfy to this? I'm not 100% sure what'd be the right
>> path forward, just pointing out a potential availability issue.
>

Current swapping would ensure the last active pages be loaded so it gives  
some level of insurance that aesmd would be able to run as long as there  
is swapping RAM and other apps are not super active during attestation.

I think SGX cgroups support should help address this concern in a general  
way, which was discussed before and I think is in plan.

Not sure if lock works better, could you explain how it work?

Re: aesmd availability

[Jarkko Sakkinen]

On Tue, Feb 01, 2022 at 10:15:04AM -0600, Haitao Huang wrote:
> Hi Jarkko
> 
> On Fri, 28 Jan 2022 05:50:22 -0600, Jarkko Sakkinen <jarkko@kernel.org>
> wrote:
> 
> > On Fri, Jan 28, 2022 at 12:08:07PM +0200, Jarkko Sakkinen wrote:
> > > I noticed that with aesmd the only feasible way to host it is to make a
> > > VM for it because:
> > > 
> > > - A beter predictable round-trip time for attestation.
> > > - In the worst case, attestation could be potentially blocked.
> > > 
> 
> I don't fully understand your description here. Based on what you said
> below, I think you are talking about how to improve (control of) EPC
> allocation for apps in case of over-subscription (i.e., when EPC runs out).
> My comments below are with this understanding.
> 
> In case you think there are limitations of aesmd implementation that prevent
> aesmd from being hosted in other than a separate VM, please create an issue
> on the corresponding GitHub.
> 
> > > Should the driver have a page locking mechanism to make this more
> > > robust,
> > > or do we want to satisfy to this? I'm not 100% sure what'd be the right
> > > path forward, just pointing out a potential availability issue.
> > 
> 
> Current swapping would ensure the last active pages be loaded so it gives
> some level of insurance that aesmd would be able to run as long as there is
> swapping RAM and other apps are not super active during attestation.
> 
> I think SGX cgroups support should help address this concern in a general
> way, which was discussed before and I think is in plan.
> 
> Not sure if lock works better, could you explain how it work?

I agree that since cgroups is coming eventually it will address these
concerns.

BR, Jarkko