linux-kernel - Re: [PATCH 0/3] cgroup/misc: Add hwcap masks to the misc controller

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <075ad534-9a76-4067-97a1-a3219fa4c60e@huaweicloud.com>
Date: Tue, 9 Dec 2025 08:58:37 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Michal Koutný <mkoutny@...e.com>,
 Andrei Vagin <avagin@...il.com>
Cc: Andrei Vagin <avagin@...gle.com>, Kees Cook <kees@...nel.org>,
 linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-mm@...ck.org, cgroups@...r.kernel.org, criu@...ts.linux.dev,
 Tejun Heo <tj@...nel.org>, Johannes Weiner <hannes@...xchg.org>,
 Vipin Sharma <vipinsh@...gle.com>, Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH 0/3] cgroup/misc: Add hwcap masks to the misc controller



On 2025/12/9 0:48, Michal Koutný wrote:
> Hello Andrei.
> 
> On Fri, Dec 05, 2025 at 12:19:04PM -0800, Andrei Vagin <avagin@...il.com> wrote:
>> If we are talking about C/R use cases, it should be configured when
>> container is started. It can be adjusted dynamically, but all changes
>> will affect only new processes. The auxiliary vectors are set on execve.
> 
> The questions by Ridong are getting at the reasons why cgroup API
> doesn't sound like a good match for these values.

Eh, The statement "it can be adjusted dynamically, but all changes will affect only new processes"
means that processes created within the same cgroup could end up with different capabilities. This
does not sound like how cgroups typically operate;

> I understand it's tempting to implement this by simply copying some
> masks from the enclosing cgroup but since there's little to be done upon
> (dynamic) change or a process migration it's overkill.
> 
> So I'd look at how other [1] adjustments between fork-exec are done and
> fit it with them. I guess prctl would be an option as a substitute for
> non-existent setauxval().
> 
> Thanks,
> Michal
> 
> [1] Yes, I admit cgroup migration is among them too. Another one is
> setns(2) which is IMO a closer concept for this modified view of HW, I'm
> not sure whether hardware namespaces had been brought up (and rejected)
> in the past.
> 

-- 
Best regards,
Ridong