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

Haitao Huang
2023-10-11T15:02:36Z

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

> On Tue, Oct 10, 2023, Haitao Huang wrote:
>> On Mon, 09 Oct 2023 21:23:12 -0500, Huang, Kai <kai.huang@intel.com>
>> 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@google.com> 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