lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 11 Jun 2021 14:43:34 +0000 From: Quentin Perret <qperret@...gle.com> To: Qais Yousef <qais.yousef@....com> Cc: mingo@...hat.com, peterz@...radead.org, vincent.guittot@...aro.org, dietmar.eggemann@....com, rickyiu@...gle.com, wvw@...gle.com, patrick.bellasi@...bug.net, xuewen.yan94@...il.com, linux-kernel@...r.kernel.org, kernel-team@...roid.com Subject: Re: [PATCH v2 3/3] sched: Make uclamp changes depend on CAP_SYS_NICE On Friday 11 Jun 2021 at 15:17:37 (+0100), Qais Yousef wrote: > On 06/11/21 13:49, Quentin Perret wrote: > > Thinking about it a bit more, a more involved option would be to have > > this patch as is, but to also introduce a new RLIMIT_UCLAMP on top of > > it. The semantics could be: > > > > - if the clamp requested by the non-privileged task is lower than its > > existing clamp, then allow; > > - otherwise, if the requested clamp is less than UCLAMP_RLIMIT, then > > allow; > > - otherwise, deny, > > > > And the same principle would apply to both uclamp.min and uclamp.max, > > and UCLAMP_RLIMIT would default to 0. > > > > Thoughts? > > That could work. But then I'd prefer your patch to go as-is. I don't think > uclamp can do with this extra complexity in using it. Sorry I'm not sure what you mean here? > We basically want to specify we want to be paranoid about uclamp CAP or not. In > my view that is simple and can't see why it would be a big deal to have > a procfs entry to define the level of paranoia the system wants to impose. If > it is a big deal though (would love to hear the arguments); Not saying it's a big deal, but I think there are a few arguments in favor of using rlimit instead of a sysfs knob. It allows for a much finer grain configuration -- constraints can be set per-task as well as system wide if needed, and it is the standard way of limiting resources that tasks can ask for. > requiring apps that > want to self regulate to have CAP_SYS_NICE is better approach. Rlimit wouldn't require that though, which is also nice as CAP_SYS_NICE grants you a lot more power than just clamps ...
Powered by blists - more mailing lists