Re: [PATCH] y2038: fix socket.h header inclusion
* Arnd Bergmann: > Ok, so not '__fds_bits'. > > Is '__kernel_fds_bits' ok? I would prefer to keep at least the > name __kernel_ namespace that we have for typedefs and the > occasional struct tag. glibc should be okay with that. We use __kernel_ in the math libraries for something completely different, but those files do not (or should not) include UAPI headers, and in any case, the set of such identifiers is really small.
Re: [PATCH] y2038: fix socket.h header inclusion
On Mon, Mar 18, 2019 at 2:12 PM Florian Weimer wrote: > > On Mon, Mar 18, 2019 at 10:25 AM Florian Weimer wrote: > >> > >> * Arnd Bergmann: > >> > >> > Should we just remove __kernel_fd_set from the exported headers and > >> > define the internal fd_set directly in include/linux/types.h? (Adding the > >> > folks from the old thread to Cc). > >> > >> The type is used in the sanitizers, but incorrectly. They assume that > >> FD_SETSIZE is always 1024. (The existence of __kernel_fd_set is > >> itself somewhat questionable because it leads to such bugs.) > >> Moving around the type could cause a build failure in the sanitizers, but > >> I'm > >> not entirely clear how the UAPI headers are included there. > > > > It looks like sanitizer_platform_limits_posix.cc includes > > linux/posix_types.h to ensure that __kernel_fd_set is the same > > size as __sanitizer___kernel_fd_set, and then it uses the > > latter afterwards. > > > > What I don't see here is what kind of operation is actually done > > on the data, I only see a cast to void. > > I think it is used to assert that the select family of system calls > writes to the 1024 bits for each of the passed pointers. Yes, that is what I expected to see in libsanitizer, I just couldn't find any code that actually does this check. > Which is not actually true—the write size is controlled by the > file descriptor count argument. Yes, of course. In fact, I see multiple possible problems that - kernel reading uninitialized data if 'FD_ZERO()' was used with a shorter size than the count argument. - kernel writing beyond the fd_set data on stack when the declaration had a shorter size than the count argument. Each one could happen either because __FD_SETSIZE is smaller than 'count', or because kernel and user space disagree on the element size (32 vs 64 bit on x32). > > If libsanitizer actually does > > anything interesting here, we should definitely fix it to use the > > correct size, especially since this is actually something that > > can trigger a buffer overflow in subtle ways when used carelessly. > > See for example [1], which we still have not addressed > > The footnote is missing. Sorry, I meant [1] https://patchwork.kernel.org/patch/10245053/ > > For this specific use (and probably others like it), renaming the > > fds_bits member to __kernel_fds_bits or something like that > > would keep user space still compiling. That would only break > > if someone was using __kernel_fd_set, and actually doing > > bit operations on it. glibc uses '__fds_bits' unless __USE_XOPEN > > is set, so maybe we should use use that name unconditionally. > > Please use something that is more obviously Linux-specific. Ok, so not '__fds_bits'. Is '__kernel_fds_bits' ok? I would prefer to keep at least the name __kernel_ namespace that we have for typedefs and the occasional struct tag. Arnd
Re: [PATCH] y2038: fix socket.h header inclusion
* Arnd Bergmann: > On Mon, Mar 18, 2019 at 10:25 AM Florian Weimer wrote: >> >> * Arnd Bergmann: >> >> > Should we just remove __kernel_fd_set from the exported headers and >> > define the internal fd_set directly in include/linux/types.h? (Adding the >> > folks from the old thread to Cc). >> >> The type is used in the sanitizers, but incorrectly. They assume that >> FD_SETSIZE is always 1024. (The existence of __kernel_fd_set is >> itself somewhat questionable because it leads to such bugs.) >> Moving around the type could cause a build failure in the sanitizers, but I'm >> not entirely clear how the UAPI headers are included there. > > It looks like sanitizer_platform_limits_posix.cc includes > linux/posix_types.h to ensure that __kernel_fd_set is the same > size as __sanitizer___kernel_fd_set, and then it uses the > latter afterwards. > > What I don't see here is what kind of operation is actually done > on the data, I only see a cast to void. I think it is used to assert that the select family of system calls writes to the 1024 bits for each of the passed pointers. Which is not actually true—the write size is controlled by the file descriptor count argument. > If libsanitizer actually does > anything interesting here, we should definitely fix it to use the > correct size, especially since this is actually something that > can trigger a buffer overflow in subtle ways when used carelessly. > See for example [1], which we still have not addressed The footnote is missing. > For this specific use (and probably others like it), renaming the > fds_bits member to __kernel_fds_bits or something like that > would keep user space still compiling. That would only break > if someone was using __kernel_fd_set, and actually doing > bit operations on it. glibc uses '__fds_bits' unless __USE_XOPEN > is set, so maybe we should use use that name unconditionally. Please use something that is more obviously Linux-specific.
Re: [PATCH] y2038: fix socket.h header inclusion
* Arnd Bergmann: > Should we just remove __kernel_fd_set from the exported headers and > define the internal fd_set directly in include/linux/types.h? (Adding the > folks from the old thread to Cc). The type is used in the sanitizers, but incorrectly. They assume that FD_SETSIZE is always 1024. (The existence of __kernel_fd_set is itself somewhat questionable because it leads to such bugs.) Moving around the type could cause a build failure in the sanitizers, but I'm not entirely clear how the UAPI headers are included there. Otherwise, I couldn't find any uses.
Re: [PATCH] y2038: fix socket.h header inclusion
On Sun, Mar 17, 2019 at 7:20 PM Deepa Dinamani wrote:
> On Fri, Mar 15, 2019 at 2:20 PM Florian Weimer wrote:
> > > On Thu, Mar 14, 2019 at 7:41 PM Florian Weimer wrote:
> > >> > diff --git a/arch/alpha/include/uapi/asm/socket.h
> > >> > b/arch/alpha/include/uapi/asm/socket.h
> > >> > index 0d0fddb7e738..976e89b116e5 100644
> > >> > --- a/arch/alpha/include/uapi/asm/socket.h
> > >> > +++ b/arch/alpha/include/uapi/asm/socket.h
> > >> > @@ -2,8 +2,8 @@
> > >> > #ifndef _UAPI_ASM_SOCKET_H
> > >> > #define _UAPI_ASM_SOCKET_H
> > >> >
> > >> > +#include
> > >> > #include
> > >> > -#include
> > >>
> > >> This breaks POSIX conformance in glibc because the
> > >> header is not namespace clean. It contains the
> > >> identifiers fds_bits and val:
> > >>
> > >> unsigned long fds_bits[__FD_SETSIZE / (8 * sizeof(long))];
> > >>
> > >> int val[2];
> > >
> > > What is problematic about the struct members here? I had thought that
> > > only the struct names have to be in a namespace to be usable here,
> > > but not the members.
> >
> > According POSIX, a user can do this:
> >
> > #define fds_bits 1024
> >
> > before including the header file. Similarly for val.
> >
> > Since glibc pulls in indirectly, the result is a parse
> > error, even though the programmer did nothing wrong (fds_bits is not
> > an identifier used by POSIX, nor is it in the implementation
> > namespace, ans is a POSIX header).
Ok, I see. Thanks for the explanation!
> > > We could use asm/posix_types.h instead of linux/posix_types.h,
> > > would that address your concern?
> >
> > It should fix the fds_bits case, I think. But
> > still uses val, so that part of the issue
> > remains.
>
> Would moving kernel namespace types(__kernel prefix) to a different
> header file(kernel_types.h?) and then including this from
> linux/posix_types.h.
> And, for socket.h just including kernel_types.h make sense?
I fear we have considered linux/posix_types.h to be something that
can be included anywhere for a long time, so it may be better to
ensure that this is actually the case, and avoid the problem with those
two structures but leave the rest untouched.
I think we can move __kernel_fsid_t into include/uapi/asm-generic/statfs.h,
which is the only thing that needs it anyway. We have two definitions of
it today, the non-generic one being for mips32, but incidentally there was
a patch the other day to remove that and use the generic one instead.
With that done, we can change asm/socket.h to just use asm/posix_types.h.
I would still prefer to solve the problem for linux/posix_types.h as well,
but I'm not sure even how __kernel_fd_set is used today in
user space, if at all. Commit 8ded2bbc1845 ("posix_types.h: Cleanup
stale __NFDBITS and related definitions") removed most of the fd_set
definition after a long discussion [1], and since then it has been
basically impossible to use 'struct fd_set' from the kernel in a
meaningful way without including the libc headers or duplicating
them.
Should we just remove __kernel_fd_set from the exported headers and
define the internal fd_set directly in include/linux/types.h? (Adding the
folks from the old thread to Cc).
Arnd
[1] https://lore.kernel.org/lkml/20120724181209.ga10...@zod.bos.redhat.com/t/
