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.
