linux-kernel - Re: [PATCH] fs: remove obsolete comments on member ordering of random layout struct

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: <Y+KSvGl1rPYbMFar@gmail.com>
Date:   Tue, 7 Feb 2023 18:04:44 +0000
From:   Eric Biggers <ebiggers@...nel.org>
To:     Dawei Li <set_pte_at@...look.com>
Cc:     viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs: remove obsolete comments on member ordering of
 random layout struct

On Tue, Feb 07, 2023 at 09:14:08PM +0800, Dawei Li wrote:
> Structures marked with __randomize_layout are supposed to reorder layout
> of members randomly. Although layout is not guranteed to be reordered
> since dependency on hardening config, but let's not make assumption such
> as "member foo is first".
> 
> Signed-off-by: Dawei Li <set_pte_at@...look.com>
> ---
>  include/linux/fs.h | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index c1769a2c5d70..9114c4e44154 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -585,11 +585,6 @@ is_uncached_acl(struct posix_acl *acl)
>  
>  struct fsnotify_mark_connector;
>  
> -/*
> - * Keep mostly read-only and often accessed (especially for
> - * the RCU path lookup and 'stat' data) fields at the beginning
> - * of the 'struct inode'
> - */
>  struct inode {
>  	umode_t			i_mode;
>  	unsigned short		i_opflags;
> @@ -1471,7 +1466,7 @@ struct sb_writers {
>  };
>  
>  struct super_block {
> -	struct list_head	s_list;		/* Keep this first */
> +	struct list_head	s_list;

If these comments are just talking about how the fields are arranged for best
performance (the inode comment definitely is; the super_block one is a bit
ambiguous), rather than for correctness, they are perfectly fine to keep.  It
still makes sense to do those sort of manual structure layout optimizations on
commonly used structures like these, because they still benefit everyone who
doesn't have CONFIG_RANDSTRUCT enabled (i.e., almost everyone).

- Eric