[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181220180835.GL23599@brightrain.aerifal.cx>
Date: Thu, 20 Dec 2018 13:08:35 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Data structures defined by both linux and musl
On Thu, Dec 20, 2018 at 11:33:59AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2018-12-19 19:30:44 -0500]:
> > On Tue, Dec 18, 2018 at 08:41:53PM +0100, Arnd Bergmann wrote:
> > > I recently discussed with Rich about the work needed to get 64-bit time_t
> > > support into musl. One of the first steps he identified was to find out which
> > > interfaces we would want to abstract or wrap for a new ABI given that we
> > > have to make a binary incompatible interface anyway.
> > >
> > > I have found all the data structures that are provided by both the kernel
> > > headers and the musl headers now, and annotated what I think we the
> > > path forward could be. I already provided the same list on IRC, but
> > > here is a (slightly updated) copy for everyone else.
> >
> > Thank you. For those just joining now, the context of this is that
> > support for 64-bit time_t on 32-bit archs probably requires, and at
> > least is best done with, a new ABI, so far known as the ".2" ABI
> > (because the ldso would end in ".2" instead of ".1"). This would be an
> > opportunity to fix lots of ABI mistakes where extensibility of even
> > support for current functionality is lacking. If done, this would not
> > be a fork of musl and would not be dropping existing ABIs. Rather,
> > internal refactoring would eliminate the assumption that the
> > ABI-with-application types match the ABI-with-kernel/syscall types,
> > performing translation back and forth where needed. On the existing
> > ".1" ABIs, this translation would mostly be the identity
> > transformation, but on archs where we're already doing some hacks to
> > fix up kernel ABI bugs (sysvipc on big endian, mips stat structure,
> > x32 stuff, etc.) the hacks could be replaced by used of this
> > translation infrastructure.
>
> lesson of ilp32 was that libc cannot generally translate between
> a user and kernel abi (otherwise it could be done in userspace).
Part of the purpose of this research/this thread is to determine what
the affected interfaces are and how/whether to fix them. This may
inform the choice of which additional types to abstract away and
translate. The only things that absolutely have to change are
structures containing time_t.
> the problematic cases are when user talks to the kernel directly
> using libc types in a way that the libc cannot do the translation.
>
> interfaces where the libc does not know the type, just an opaque
> pointer: ioctl, fcntl, getsockopt, setsockopt, raw syscall
Ultimately all of these *can* be translated just by enumerating all
the broken interfaces and special-casing them. It's not pretty,
though. What would probably happen (Arnd, do you know?) would be
redefining the ioctl numbers etc. to "time64" versions of the
interfaces, and for interfaces which are actually "important" to have
work on old kernels, including translations to/from the corresponding
old ioctl. Depending on the scope, that might be all or nearly all of
them.
> interfaces where translation would require malloc, but should be
> as-safe and not fail with ENOMEM: sendmmsg, readv, writev,...
IOV_MAX is 1024 so it's reasonable to do on-stack and simply fail
requests that are too large. But we don't have to translate iovecs
anyway.
> direct communication channel to the kernel that may expose the
> abi incompatibility: netlink, sysfs, procfs
Netlink is the worst here since it's "hidden" behind normal read/write
calls where the data is abstract bytes. If there's anything that needs
to be fixed at the netlink layer it probably just requires redefining
part of the _API_ to use fixed-width types rather than time_t or such.
> types related to signal handling that may require sighandler
> wrapping to translate: siginfo_t, ucontext_t
Yes. I'm not proposing we do sighandler wrapping/translation now or in
the future because it's a pain, but there are some good motivations to
do it, so I'd like to keep the option open.
> time_t may not be affected by these, but it shows that translation
> is fragile in general, i wonder if we can ensure correct behaviour
> in all cases. there is also the problem of linux headers which may
> use and redefine libc types and user code may need to use those.
Redefining libc types is already broken, and the kernel headers that
do it can't be used from userspace when libc headers are included.
This issue is independent of type sizes/layouts matching.
I don't think any kernel headers _use_ libc types either. They
generally use their own stuff.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
