linux-kernel - Re: [GIT PULL] execve updates for v6.13-rc1

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]

Message-ID: <Zz-mmg9tEj7EbPlm@kawka3.in.waw.pl>
Date: Thu, 21 Nov 2024 21:31:06 +0000
From: Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Kees Cook <kees@...nel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christophe JAILLET <christophe.jaillet@...adoo.fr>,
	Dan Carpenter <dan.carpenter@...aro.org>,
	Nir Lichtman <nir@...htman.org>,
	syzbot+03e1af5c332f7e0eb84b@...kaller.appspotmail.com,
	Tycho Andersen <tandersen@...flix.com>,
	Vegard Nossum <vegard.nossum@...cle.com>
Subject: Re: [GIT PULL] execve updates for v6.13-rc1

On Thu, Nov 21, 2024 at 11:23:46AM -0800, Linus Torvalds wrote:
> On Thu, 21 Nov 2024 at 10:50, Kees Cook <kees@...nel.org> wrote:
> >
> > The only flip side I can see is that "ps" etc, should just never use comm
> > at all, and instead use argv[0] from cmdline
> 
> Gods people, what are you all on about?
> 
> THIS IS WHAT PS ALREADY DOES.

Nope. 'ps' uses comm, for example in 'ps -C' which is documented as
"select by command name" and quite commonly used.

It does not use it in the default listing, because it shows "COMMAND",
incl. args, which obviously must use /proc//cmdline. But nobody said
that it does. Kees only mentioned that "ps uses comm for the short
name view of a process", which is true. _You_ wrote about ps and showed
an example with COMMAND which is … fine, but not really relevant.

If you wanted, you could ask where is comm used by the userspace?
The ones I'm aware of where it's directly visible:
- 'ps -C' or 'ps -o comm'
- pgrep
- top
- htop

Using sourcegraph.com I see mentions in moby, kubernetes, zsh and
ohmyzsh, earlyoom, vmtop, and pages of more obscure stuff. It's also
exposed via libsystemd's sd_bus_creds and journald's _COMM field.
The generic interfaces are the biggest problem. We could probably
update top/htop/pgrep to use argv[0], but we can't fix scripts
that are out there that either use 'ps -o comm' or look in /proc//comm
directly or filter journalctl output by field.

> Stop this completely inane discussion. It's literally like you don't
> even know what you are talking about.
>
> For user space, comm[] is basically the fallback for when cmdline
> fails for some reason (for example, /proc/*/cmdline will be empty for
> kworkers, but there are other situations too)

As mentioned, this is easily disproved by running e.g. top/htop/pgrep.

> The reason? comm[] has *always* been much too limited for 'ps' output. ALWAYS.
> 
> Yes, you can literally *force* ps to not do that (eg "ps -eo comm")
> but if you do that, you get the very limited comm[] output that nobody
> has ever wanted ps to give exactly because it's so limited.
> 
> People who want 'argv[0]' will typically want argv[1] etc too, because
> argv[0] simply IS NOT SPECIAL.
> 
> And yes, 'top' will give comm[] output because it's so much faster.

Exactly.

> I'm done with this discussion that apparently was brought on by people
> not knowing what the hell they were doing.

You keep disagreeing with things that nobody has said.

The point is that comm _is_ used in many places that matter. I'm not
sure what you're trying to say really, since in the second half of
your mail you actually showed an example where this is true.

Zbyszek