linux-kernel - Re: [RFC v2] lsm: fs: Use inode_free_callback to free i

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z2N7Ibxnmm-KEvea@dread.disaster.area>
Date: Thu, 19 Dec 2024 12:47:13 +1100
From: Dave Chinner <david@...morbit.com>
To: Song Liu <song@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org,
	linux-xfs@...r.kernel.org, linux-security-module@...r.kernel.org,
	willy@...radead.org, corbet@....net, clm@...com,
	josef@...icpanda.com, dsterba@...e.com, brauner@...nel.org,
	jack@...e.cz, cem@...nel.org, djwong@...nel.org,
	paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com,
	fdmanana@...e.com, johannes.thumshirn@....com, kernel-team@...a.com
Subject: Re: [RFC v2] lsm: fs: Use inode_free_callback to free i_security in
 RCU callback

On Wed, Dec 18, 2024 at 01:16:15PM -0800, Song Liu wrote:
> inode->i_security needes to be freed from RCU callback. A rcu_head was
> added to i_security to call the RCU callback. However, since struct inode
> already has i_rcu, the extra rcu_head is wasteful. Specifically, when any
> LSM uses i_security, a rcu_head (two pointers) is allocated for each
> inode.
> 
> Rename i_callback to inode_free_callback and call security_inode_free_rcu
> from it to free i_security so that a rcu_head is saved for each inode.
> Special care are needed for file systems that provide a destroy_inode()
> callback, but not a free_inode() callback. Specifically, the following
> logic are added to handle such cases:
> 
>  - XFS recycles inode after destroy_inode. The inodes are freed from
>    recycle logic. Let xfs_inode_free_callback() call inode_free_callback.

NACK. That's a massive layering violation.

LSMs are VFS layer functionality. They *must* be removed from the
VFS inode before ->destroy_inode() is called. If a filesystem
supplies ->destroy_inode(), then it -owns- the inode exclusively
from that point onwards. All VFS and 3rd party stuff hanging off the
inode must be removed from the inode before ->destroy_inode() is
called.

Them's the rules, and hacking around LSM object allocation/freeing
to try to handle how filesystems manage inodes -underneath- the VFS
is just asking for problems. LSM object management needs to be
handled entirely by the generic LSM VFS hooks, not tightly coupled
to VFS and/or low level filesystem inode lifecycle management.

-Dave.
-- 
Dave Chinner
david@...morbit.com