linux-kernel - Re: [GIT PULL] execve updates for v6.8-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: <D01C78AC-830C-4D73-9E9F-7FD38CEF2E82@kernel.org>
Date: Mon, 08 Jan 2024 17:48:38 -0800
From: Kees Cook <kees@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
 Kees Cook <keescook@...omium.org>
CC: linux-kernel@...r.kernel.org, Alexey Dobriyan <adobriyan@...il.com>,
 Josh Triplett <josh@...htriplett.org>
Subject: Re: [GIT PULL] execve updates for v6.8-rc1



On January 8, 2024 4:19:45 PM PST, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>On Mon, 8 Jan 2024 at 10:35, Kees Cook <keescook@...omium.org> wrote:
>>
>> Josh Triplett (1):
>>       fs/exec.c: Add fast path for ENOENT on PATH search before allocating mm
>
>No, we're not doing this.
>
>If you want to open the file before the allocations, then dammit, do
>exactly that.

This was exactly the feedback I had originally and wrote almost what you suggest:

https://lore.kernel.org/lkml/202209161637.9EDAF6B18@keescook/

>Anyway, I want to repeat: this patch is UNTESTED. It compiles for me.
>But that is literally all the testing it has gotten apart from a
>cursory "this patch looks sane".
>
>There might be something seriously wrong with this patch, but it at
>least makes sense, unlike that horror that will look up the filename
>twice.
>
>I bet whatever benchmark did the original was not using long filenames
>with lots of components, or was only testing the ENOENT case.

But the perf testing of my proposed "look it up once" patch showed a net loss to the successful execs which no one could explain. In the end we went with the original proposal.

If you think this is too much of a hack, I'm happy to drop it. My very first reaction was "fix userspace; shells use access() not execve()" but it seems enough other runtimes (Python?) use execve PATH searches that it would make a measurable real-world difference.

-Kees

-- 
Kees Cook