Hello, On Mon, Feb 06, 2023 at 01:21:05PM -0800, Tony Luck wrote: ... > I'm thinking along these lines: > > 1) Sysadmin creates a cgroup for a "job". Initializes the limits on > how many of these virtual windows can be used (h/w has a fixed number). > Assigns tasks in the job to this cgroup. > > 2) Tasks in the job that want to offer virtual windows call into the > driver to allocate and partially set up windows tagged with "available > to any other process in my cgroup". > > 3) Other tasks in the group ask the driver to complete the h/w > initialization by adding them (their PASID) to the access list > for each window. > > My questions: > > 1) Is this horrible - have I misunderstood cgroups? > 1a) If this is horrible, can it be rescued? I'm not sure whether I fully understand what the virtual windows are but assuming that it's a hardware resource that's limited in number and if you're okay with tying it to cgroup hierarchy, I think it can just be one of the resources that are managed by the misc controller. The tying access domain to the cgroup part is likely the challenging part. cgroup hierarchy is primarily composed according to the innate usage hierarchy of the system and this might not match what you need. I can't tell. > 2) Will it work - is "membership in a cgroup" a valid security mechanism? Again, I can't tell without knowing about the specifics but it gets used that way in some cases - e.g. devcg in cgroup1 or the BPF counterpart in ecgroup2 are used to enforce raw device access restrictions based on cgroup membership. > 3) Has someone done something similar before (so I can learn from their code)? For limiting the number available to a part of a system, the misc controller - kernel/cgroup/misc.c. > 4) Is there an existing exported API to help. I see task_cgroup_path() > which looks generally helpful (though I'd prefer a task_cgroup() that > just takes a task and gives me the cgroup to which it belongs.) task_dfl_cgroup(). However, please note that everything in cgroup is supposed to be hierarchical, so that's something to keep on mind when defining an external security mechanism based on cgroup membership. The flip side is that on vast majority of configurations, cgroup hierarchy more or less coincides with process tree which has the benefit of being available regardless of cgroups, so in a lot of cases, it can be better to just go the traditional way and tie these things to the process tree. Thanks. -- tejun
