Message-ID: <CAMuHMdXD0weO4oku8g2du6fj-EzxGaF+0i=zrPScSXwphFAZgg@mail.gmail.com>
Date: Mon, 22 Jan 2024 17:23:29 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org, 
	Masami Hiramatsu <mhiramat@...nel.org>, Mark Rutland <mark.rutland@....com>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Christian Brauner <brauner@...nel.org>, Al Viro <viro@...iv.linux.org.uk>, 
	Ajay Kaher <ajay.kaher@...adcom.com>, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [for-linus][PATCH 1/3] eventfs: Have the inodes all for files and
 directories all be the same

Hi Steven,

On Mon, Jan 22, 2024 at 4:05 PM Steven Rostedt <rostedt@...dmis.org> wrote:
> On Mon, 22 Jan 2024 11:38:52 +0100
> Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> > Hi Stephen,
>
> I don't know who "Stephen" is, but I'll reply to this message.

My apologies (too many different spellings in too many languages)...

> > On Wed, Jan 17, 2024 at 3:37 PM Steven Rostedt <rostedt@...dmisorg> wrote:
> > > From: "Steven Rostedt (Google)" <rostedt@...dmis.org>
> > >
> > > The dentries and inodes are created in the readdir for the sole purpose of
> > > getting a consistent inode number. Linus stated that is unnecessary, and
> > > that all inodes can have the same inode number. For a virtual file system
> > > they are pretty meaningless.
> > >
> > > Instead use a single unique inode number for all files and one for all
> > > directories.
> > >
> > > Link: https://lore.kernel.org/all/20240116133753.2808d45e@gandalf.local.home/
>
> Yeah, Linus wanted me to try this first and see if there's any regressions.
> Well, I guess you just answered that.
>
> The above link has me saying to Linus:
>
>   It was me being paranoid that using the same inode number would break user
>   space. If that is not a concern, then I'm happy to just make it either the
>   same, or maybe just hash the ei and name that it is associated with.
>
> > > Link: https://lore.kernel.org/linux-trace-kernel/20240116211353.412180363@goodmis.org
> > >
> > > Cc: Masami Hiramatsu <mhiramat@...nel.org>
> > > Cc: Mark Rutland <mark.rutland@....com>
> > > Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> > > Cc: Christian Brauner <brauner@...nel.org>
> > > Cc: Al  Viro <viro@...IV.linux.org.uk>
> > > Cc: Ajay Kaher <ajay.kaher@...adcom.com>
> > > Suggested-by: Linus Torvalds <torvalds@...ux-foundation.org>
> > > Signed-off-by: Steven Rostedt (Google) <rostedt@...dmis.org>
> >
> > Thanks for your patch, which is now commit 53c41052ba312176 ("eventfs:
> > Have the inodes all for files and directories all be the same") in
> > v6.8-rc1, to which I have bisected the issue below.

> > This confuses "find".
> > Running "find /sys/" now prints lots of error messages to stderr:
> >
> > find: File system loop detected;
> > ‘/sys/kernel/debug/tracing/events/initcall/initcall_finish’ is part of
> > the same file system loop as
> > ‘/sys/kernel/debug/tracing/events/initcall’.
>
> So at a minimum, the directories need to have unique inode numbers.
>
>
> > find: File system loop detected;
> > ‘/sys/kernel/debug/tracing/events/initcall/initcall_start’ is part of
> > the same file system loop as
> > ‘/sys/kernel/debug/tracing/events/initcall’.
> > find: File system loop detected;
> > ‘/sys/kernel/debug/tracing/events/initcall/initcall_level’ is part of
> > the same file system loop as
> > ‘/sys/kernel/debug/tracing/events/initcall’.
> > [...]
>
> Does this fix it for you? It hashes the eventfs_inode data structure after
> adding some salt to it.
>
> Kees,
>
> I'm using the eventfs_inode pointer to create a unique value for the inode.
> But it's being salted, hashed and then truncated. As it is very easy to
> read inodes (although by default, only root has access to read these
> inodes), the inode numbers themselves shouldn't be able to leak kernel
> addresses via the results of these inode numbers, would it?
>
> -- Steve

Gotya ;-)

>
> diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
> index 6795fda2af19..d54897b84596 100644
> --- a/fs/tracefs/event_inode.c
> +++ b/fs/tracefs/event_inode.c

> @@ -36,6 +37,31 @@ static DEFINE_MUTEX(eventfs_mutex);
>  #define EVENTFS_FILE_INODE_INO         0x12c4e37
>  #define EVENTFS_DIR_INODE_INO          0x134b2f5
>
> +/* Used for making inode numbers */
> +static siphash_key_t inode_key;
> +
> +/* Copied from scripts/kconfig/symbol.c */
> +static unsigned strhash(const char *s)
> +{
> +       /* fnv32 hash */
> +       unsigned hash = 2166136261U;
> +       for (; *s; s++)
> +               hash = (hash ^ *s) * 0x01000193;
> +       return hash;
> +}
> +
> +/* Just try to make something consistent and unique */
> +static int eventfs_dir_ino(struct event_inode *ei, const char *name)

eventfs_inode

> +{
> +       unsigned long sip = (unsigned long)ei;
> +
> +       sip += strhash(name) + EVENTFS_DIR_INODE_INO;
> +       sip = siphash_1u32((int)sip, &inode_key);
> +
> +       /* keep it positive */
> +       return sip & ((1U << 31) - 1);
> +}
> +
>  /*
>   * The eventfs_inode (ei) itself is protected by SRCU. It is released from
>   * its parent's list and will have is_freed set (under eventfs_mutex).

Thanks, find is happy now the directories have different inode numbers.
The files still have identical inodes numbers, I hope that doesn't cause
any issues...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68korg

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists