musl - use of varargs in open and various functions

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADYdroNPnKv4iwOeAUkKKcUyeV25tqUVGM1WPBH2_p=u6yQDsw@mail.gmail.com>
Date: Thu, 11 Apr 2019 16:25:50 +0200
From: Norbert Lange <nolange79@...il.com>
To: musl@...ts.openwall.com
Subject: use of varargs in open and various functions

Hello,

I had some dealings with software that forwards arguments from vararg functions,
the kind with optional but known fixed type.
open, fcntl, ioctl are some examples.

What happens in musl is that the optional argument is optionally or
always retrieved (fcntl).
I think this is pretty much pointless, the only reason to use varags would be:

1.   varying argument types (plainly not possibly to replace with
direct arguments)
2.   different parameter passing than direct arguments (ABI compatibility)
3.   accessing parameters the caller has not provided.

1. disqualifies functions like printf which I am not planning to touch.
2. would need more tests, but I expect this to be true for all modern
architectures,
    atleast its true for most of them.
3. thats a thing for open where the 3rd argument is only accessed if
certain flags are set,
    but most other functions in musl seem to always access "optional" arguments.
    reading theses non-existing arguments could trigger tools like
valgrind, but other
    than that it should not be an issue aslong a couple bytes of stack
is available.

I tested code calling the functions, I believe calls are identical for
varags and normal functions,
for all architectures that are supported by musl. [1]
(sidenote: clang generates absolutely awful code for those varag functions).

So, is there any reason not to make this the default for musl (adding
a fallback option via a define)? I am running a few tools (bash, nano)
compiled with the applied patch and so far I have no adverse effects,
it should not affect ABI for machines satisfying 2. and it gets rid of
some wacky code that in the end just passes in another register (like
open).

Further I would like to add that Torvalds shares a similar view [2].

Kind regards,
Norbert

[1] https://godbolt.org/z/asBT92
[2] https://lkml.org/lkml/2014/10/30/812

PS. why is this a thing in open:
  int fd = __sys_open_cp(filename, flags, mode);
  if (fd>=0 && (flags & O_CLOEXEC))
  __syscall(SYS_fcntl, fd, F_SETFD, FD_CLOEXEC);

Is this to support old kernels?
I thought O_CLOEXEC is used to fight races during a fork,
so if its not supported by the kernel it wont do alot.

View attachment "lessvarargs.patch" of type "text/x-patch" (5933 bytes)

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.