Re: [PATCH v5 12/18] x86/sgx: Add EPC OOM path to forcefully reclaim EPC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 10 Oct 2023 19:01:25 -0500, Sean Christopherson <seanjc@xxxxxxxxxx> wrote:

On Tue, Oct 10, 2023, Haitao Huang wrote:
On Mon, 09 Oct 2023 21:23:12 -0500, Huang, Kai <kai.huang@xxxxxxxxx> wrote:

> On Mon, 2023-10-09 at 20:42 -0500, Haitao Huang wrote:
> > Hi Sean
> >
> > On Mon, 09 Oct 2023 19:23:04 -0500, Sean Christopherson
> > <seanjc@xxxxxxxxxx> wrote:
> > > I can see userspace wanting to explicitly terminate the VM instead of
> > > "silently"
> > > the VM's enclaves, but that seems like it should be a knob in the
> > > virtual EPC
> > > code.
> >
> > If my understanding above is correct and understanding your statement > > above correctly, then don't see we really need separate knob for vEPC
> > code. Reaching a cgroup limit by a running guest (assuming dynamic
> > allocation implemented) should not translate automatically killing
> > the VM.
> > Instead, it's user space job to work with guest to handle allocation
> > failure. Guest could page and kill enclaves.
> >
>
> IIUC Sean was talking about changing misc.max _after_ you launch SGX VMs:
>
> 1) misc.max = 100M
> 2) Launch VMs with total virtual EPC size = 100M	<- success
> 3) misc.max = 50M
>
> 3) will also succeed, but nothing will happen, the VMs will be still
> holding 100M EPC.
>
> You need to somehow track virtual EPC and kill VM instead.
>
> (or somehow fail to do 3) if it is also an acceptable option.)
>
Thanks for explaining it.

There is an error code to return from max_write. I can add that too to the callback definition and fail it when it can't be enforced for any reason.
Would like some community feedback if this is acceptable though.

That likely isn't acceptable. E.g. create a cgroup with both a host enclave and virtual EPC, set the hard limit to 100MiB. Virtual EPC consumes 50MiB, and the host enclave consumes 50MiB. Userspace lowers the limit to 49MiB. The cgroup code would reclaim all of the enclave's reclaimable EPC, and then kill the enclave because it's still over the limit. And then fail the max_write because the cgroup is *still* over the limit. So in addition to burning a lot of cycles, from userspace's perspective its enclave was killed for no reason, as the new limit
wasn't actually set.

I was thinking before reclaiming enclave pages, if we know the untracked vepc pages (current-tracked) is larger than limit, we just return error without enforcing the limit. That way user also knows something is wrong.

But I get that we want to be able to kill VMs to enforce the newer lower limit. I assume we can't optimize efficiency/priority of killing: enclave pages will be reclaimed first no matter what just because they are reclaimable; no good rules to choose victim between enclave and VMs in your example so enclaves could be killed still before VMs.

I think to solve it ultimately, we need be able to adjust 'capacity' of VMs
not to just kill them, which is basically the same as dynamic allocation
support for VMs (being able to increase/decrease epc size when it is
running). For now, we only have static allocation so max can't be enforced
once it is launched.

No, reclaiming virtual EPC is not a requirement. VMM EPC oversubscription is insanely complex, and I highly doubt any users actually want to oversubcribe VMs.

There are use cases for cgroups beyond oversubscribing/swapping, e.g. privileged userspace may set limits on a container to ensure the container doesn't *accidentally* consume more EPC than it was allotted, e.g. due to a configuration bug that created
a VM with more EPC than it was supposed to have.

My comments on virtual EPC vs. cgroups is much more about having sane, well-defined behavior, not about saying the kernel actually needs to support oversubscribing EPC
for KVM guests.

So here are the steps I see now, let me know if this is aligned with your thinking or I'm off track.

0) when all left are enclave VA, SECS pages and VEPC in a cgroup, the OOM kill process starts. 1) The cgroup identifies a victim vepc for OOM kill(this could be before or after enclaves being killed), sets a new flag VEPC_NO_MEMORY in the vepc. 2) call sgx_vepc_remove_all(), ignore failure counts returned. This will perform best effort to eremove all normal pages used by the vepc. 3) Guest may trigger fault again, return SIGBUS in sgx_vepc_fault when VEPC_NO_MEMORY is set. Do the same for mmap. 4) That would eventually cause sgx_vepc_release() before VM dies or killed by user space, which does the final cleanup.

Q: should we reset VEPC_NO_MEMORY flag if #4 never happens and cgroup usage is below limit? I suppose we can do it, but not sure it is sane because VM would try to load as much pages as configured originally.

I'm still thinking about using one unreclaimable list, justification is simplicity and lack of rules to select items from separate lists, but may change my mind if I found it's inconvenient.

Not sure how age/youngness can be accounted for guest pages though Kai indicated we don't need that for first version. So I assume we can deal with it later and add separate list for vEPC if needed
for that reason.

Thanks a lot for your input.
Haitao



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux