lkml.org 
[lkml]   [2021]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] x86/sgx: Add accounting for tracking overcommit
From
Date
On 12/20/21 2:48 PM, Borislav Petkov wrote:
> On Mon, Dec 20, 2021 at 01:35:03PM -0800, Kristen Carlson Accardi wrote:
>> So, in your proposal you would first change the calculated number of
>> maximum available backing pages to be based on total system RAM rather
>> than EPC memory, got it.
>
> This was just an example. My point is to try to make it automatic and
> not introduce another knob. And to decide on the limits and behavior
> by using common sense and addressing the common use cases first.

The common case is clearly a few enclaves on systems where the
overcommit levels are modest. The "100%" limit will work great there.

I'd personally be fine with just enforcing that limit as the default and
ignoring everything else. It makes me a bit nervous, though, because
suddenly enforcing a limit is an ABI break. The tunable effectively
gives us a way out if we screw up either the limit's quantity or someone
needs the old ABI back.

That said, we don't *need* it to be tunable, boot parameter or not. If
you're concerned about the tunable, I think we should drop it and not
look back.

> Imagine you're a sysadmin. Or a general, common system user if there
> ever is one.
>
> When your system starts thrashing and you're running a bunch of
> enclaves, how do you find out there even is a knob which might
> potentially help you?

I'm selfish. The tunable isn't for end users. It's for me.

The scenario I envisioned is that a user upgrades to a new kernel and
their enclaves start crashing. They'll eventually find us, the
maintainers of the SGX code, and we'll have a tool as kernel developers
to help them. The tunable helps _me_ in two ways:
1. It help me easily get user back to pre-5.17 (or whatever) behavior
2. If we got the "100%" value wrong, end users can help us experiment to
help find a better value.

BTW, all the chat about "malicious" enclaves and so forth... I
*totally* agree that this is a problem and one worth solving. It just
can't be solved today. We need real cgroup support. It's coming soon.

\
 
 \ /
  Last update: 2021-12-21 16:54    [W:0.058 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site