linux-kernel - Re: [for-linus][PATCH 1/3] eventfs: Have the inodes all for files and directories all be the same

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]

Date: Mon, 22 Jan 2024 14:37:40 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Geert Uytterhoeven
 <geert@...ux-m68k.org>, Kees Cook <keescook@...omium.org>,
 linux-kernel@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>, Mark
 Rutland <mark.rutland@....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>
Subject: Re: [for-linus][PATCH 1/3] eventfs: Have the inodes all for files
 and directories all be the same

On Mon, 22 Jan 2024 13:27:25 -0500
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> > IOW, this trivial patch seems to be much safer than worrying about
> > some pointer exposure.  
> 
> My only concern about the simple ino_counter static increment is what
> happens in the unlikely scenario of a 32-bit overflow. This is why
> I suggested using a bitmap to track inode allocation. It's compact, and
> we don't care that much about the linear bitmap scan overhead because
> it's far from being a fast path.

The original code use to get its inode via "get_next_ino()" I don't think
there's any reason not to just go back and do that again.

It can still overflow, but it's not anything new that couldn't have happen
to debugfs and tracefs over the last decade.

-- Steve