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
| ||
|
Message-ID: <CAHk-=wiTEQ31V6HLgOJ__DEAEK4DR7HdhwfmK3jiTKM4egeONg@mail.gmail.com> Date: Wed, 13 Nov 2024 15:07:38 -0800 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Amir Goldstein <amir73il@...il.com> Cc: Josef Bacik <josef@...icpanda.com>, kernel-team@...com, linux-fsdevel@...r.kernel.org, jack@...e.cz, brauner@...nel.org, linux-xfs@...r.kernel.org, linux-btrfs@...r.kernel.org, linux-mm@...ck.org, linux-ext4@...r.kernel.org Subject: Re: [PATCH v7 05/18] fsnotify: introduce pre-content permission events On Wed, 13 Nov 2024 at 14:35, Amir Goldstein <amir73il@...il.com> wrote: > > Sure for new hooks with new check-on-open semantics that is > going to be easy to do. The historic reason for the heavy inlining > is trying to optimize out indirect calls when we do not have the > luxury of using the check-on-open semantics. Right. I'm not asking you to fix the old cases - it would be lovely to do, but I think that's a different story. The compiler *does* figure out the oddities, so usually generated code doesn't look horrible, but it's really hard for a human to understand. And honestly, code that "the compiler can figure out, but ordinary humans can't" isn't great code. And hey, we have tons of "isn't great code". Stuff happens. And the fsnotify code in particular has this really odd history of inotify/dnotify/unification and the VFS layer also having been modified under it and becoming much more complex. I really wish we could just throw some of the legacy cases away. Oh well. But because I'm very sensitive to the VFS layer core code, and partly *because* we have this bad history of horridness here (and particularly in the security hooks), I just want to make really sure that the new cases do *not* use the same completely incomprehensible model with random conditionals that make no sense. So that's why I then react so strongly to some of this. Put another way: I'm not expecting the fsnotify_file() and fsnotify_parent() horror to go away. But I *am* expecting new interfaces to not use them, and not write new code like that again. Linus
Powered by blists - more mailing lists