linux-kernel - Re: [RFC PATCH] fs: allow open(dir, O

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: <CA+55aFyxoAtJMGhLtz9qND-k4ADexTrE9buG---=vOXTEoovyA@mail.gmail.com>
Date:	Thu, 30 Oct 2014 17:59:23 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Eric Rannaud <e@...ocritical.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH] fs: allow open(dir, O_TMPFILE|..., 0) with mode 0

On Thu, Oct 30, 2014 at 5:01 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> Uh, because it's glibc?

Yeah. Bloated, over-engineered, and stupid.

> Or because it's trying not to screw up and on
> some system where overrunning va_arg is terrible?

No. On 99% of architectures the third argument is in a register
anyway, and traditionally it's not even va_arg, although glibc has
made it so (traditionally it's just pre-ANSI C with three arguments
and one of them might be missing - gcc has had hacks for avoiding
warnings for traditional C things like that: look at the whole
transparent union thing for another traditional "C without prototypes"
calling convention case).

But even if you make it va_arg, I can't think of a single architecture
where that makes sense. Outside of assembly trampolines, you *always*
have enough stack space that you can just access a word under the
stack anyway.

But yes, I could imagine some well-meaning - but not overly smart -
glibc developer deciding that doing the va_arg thing conditionally
would be a "feature". Despite making the code slower, bigger, and
buggier.

I guess I'll fetch the git tree and see if they document this braindamage..

[ time passes ]

Ugh. It seems to predate even the imported history (going back all the
way to 1995 - I don't know if that was SVN or CVS and whether there is
some even older historical archives that were never imported).

Anyway, since the beginning of time, the "stub/open.c" file is a True
Work of Art (TM)(also sarcasm), and has an old-style C declaration
(not ANSI) for __libc_open(), and uses a conditional va_arg() to get
the third parameter *despite* not even being a variadic function (not
varargs, not stdarg). So it's not even portable or correct *anyway*,
and it unnecessarily generates bad code and seems to have been
mindlessly copied into all the actual real non-stub implementations.
Most of them seem to have made their definitions match the declaration
in the process, so they then really do have the variadic part. Goodie,
I guess, except for this all being unnecessary crap and stupid.

Oh well. What a cock-up.

The code is insane in other ways too. The actual real Linux version of
__libc_open() ends up (for no good reason except to compete with
cat-ladies in the "crazy person of the year" award) using
"openat(AT_FDCWD)", just so you can make sure that the result doesn't
possibly work on old versions of the kernel even by mistake. I
certainly cannot possibly see any actual *advantage* to using
"openat()", but them I'm not a homeless cat-lady.  It also has some
magic "LIBC_CANCEL_ASYNC()/LIBC_CANCEL_RESET()" stuff around it, which
I'm sure is entirely sane.

I can't take it any more. That code is crazy.

                        Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/