linux-kernel - usermode-helper code oddity query..

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

Message-ID: <CAHk-=whjmfvccPgFSfbpZ4nQ6fkYwTEAZhqZvfW8=rKMDsZarQ@mail.gmail.com>
Date:   Thu, 2 Mar 2023 15:44:17 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Luis Chamberlain <mcgrof@...nel.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Christoph Hellwig <hch@....de>,
        Kees Cook <keescook@...omium.org>,
        Iurii Zaikin <yzaikin@...gle.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: usermode-helper code oddity query..

So this is a bit out of the blue, but I cleaned up some really old
legacy capability code in commit f122a08b197d ("capability: just use a
'u64' instead of a 'u32[2]' array") and in the process I became the
last person to touch kernel/umh.c.

Tag, I'm clearly it. Not that I want to take that glory away from
PeterZ, who was the previous last person to touch that code. In fact,
I'm just cc'ing everybody who has been touching that file at all in
the last years, and a few /proc sysctl maintainers too.

Anyway, I wanted to try to keep the capability code cleanups clear,
and really only touched the data structure conversion, but I'm just
left staring at that code and wondering why we have those odd CAP_BSET
/ CAP_PI dummy pointers. They've been there since the whole /proc
interface was introduced, but they seem strangely pointless.

It would _seem_ like it would be a lot simpler and more
straightforward to just put the actual pointer to the usermodehelper
capability in there instead, and not have that odd fake pointer
enumeration at all.

IOW, I'm wondering what's wrong with a patch like the attached. I
might be missing something.

I also would have like that array to be an array of "u32" rather than
"unsigned long" (because that is, sadly, the interface we have, like
it or not), but we don't seem to have a proc_dou32vec_minmax(). I
guess "uint" is the same thing, but it's not pretty. Anyway, that's a
separate and independent issue from this.

And no, none of this is important. Just random cleanup of code I
happened to look at for other reasons.

           Linus

View attachment "patch.diff" of type "text/x-patch" (1638 bytes)