On Sat, Dec 9, 2023 at 1:30 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > > On 12/8/2023 1:06 AM, Yafang Shao wrote: > > In a containerized environment, independent memory binding by a user can > > lead to unexpected system issues or disrupt tasks being run by other users > > on the same server. If a user genuinely requires memory binding, we will > > allocate dedicated servers to them by leveraging kubelet deployment. > > > > At present, users have the capability to bind their memory to a specific > > node without explicit agreement or authorization from us. Consequently, a > > new LSM hook is introduced to mitigate this. This implementation allows us > > to exercise fine-grained control over memory policy adjustments within our > > container environment > > I wonder if security_vm_enough_memory() ought to be reimplemented as > an option to security_set_mempolicy(). I'm not convinced either way, > but I can argue both. The function security_vm_enough_memory() serves to verify the permissibility of a new memory map, while security_set_mempolicy() comes into play post-memory map allocation. Expanding security_vm_enough_memory() to include memory policy checks might potentially lead to regressions. Therefore, I would prefer to introduce a new function, security_set_mempolicy(), to handle these checks separately. -- Regards Yafang
