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: <20200522134649.lcqgwbgbnqxebcng@wittgenstein>
Date:   Fri, 22 May 2020 15:46:49 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Matthew Blecker <matthewb@...gle.com>,
        Jesse Barnes <jsbarnes@...gle.com>,
        Mike Frysinger <vapier@...gle.com>,
        Christian Brauner <christian@...uner.io>,
        Vineeth Remanan Pillai <vpillai@...italocean.com>,
        vineethrp@...il.com, Peter Zijlstra <peterz@...radead.org>,
        stable <stable@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH RFC] sched/headers: Fix sched_setattr userspace
 compilation issues

On Fri, May 22, 2020 at 09:38:16AM -0400, Joel Fernandes wrote:
> On Fri, May 22, 2020 at 03:13:55PM +0200, Christian Brauner wrote:
> > On Thu, May 21, 2020 at 11:55:21AM -0400, Joel Fernandes wrote:
> > > On Thu, May 21, 2020 at 11:53 AM Joel Fernandes (Google)
> > > <joel@...lfernandes.org> wrote:
> > > >
> > > > On a modern Linux distro, compiling the following program fails:
> > > >  #include<stdlib.h>
> > > >  #include<stdint.h>
> > > >  #include<pthread.h>
> > > >  #include<linux/sched/types.h>
> > > >
> > > >  void main() {
> > > >          struct sched_attr sa;
> > > >
> > > >          return;
> > > >  }
> > > >
> > > > with:
> > > > /usr/include/linux/sched/types.h:8:8: \
> > > >                         error: redefinition of ‘struct sched_param’
> > > >     8 | struct sched_param {
> > > >       |        ^~~~~~~~~~~
> > > > In file included from /usr/include/x86_64-linux-gnu/bits/sched.h:74,
> > > >                  from /usr/include/sched.h:43,
> > > >                  from /usr/include/pthread.h:23,
> > > >                  from /tmp/s.c:4:
> > > > /usr/include/x86_64-linux-gnu/bits/types/struct_sched_param.h:23:8:
> > > > note: originally defined here
> > > >    23 | struct sched_param
> > > >       |        ^~~~~~~~~~~
> > > >
> > > > This is also causing a problem on using sched_attr Chrome. The issue is
> > > > sched_param is already provided by glibc.
> > > >
> > > > Guard the kernel's UAPI definition of sched_param with __KERNEL__ so
> > > > that userspace can compile.
> > > >
> > > > Signed-off-by: Joel Fernandes (Google) <joel@...lfernandes.org>
> > > 
> > > If it is more preferable, another option is to move sched_param to
> > > include/linux/sched/types.h
> > 
> > Might it be worth Ccing libc-alpha here? Seems like one of those classic
> > header conflicts.
> 
> sched_param is defined by POSIX from my reading of the manpage. Is the kernel
> supposed to define it in the UAPI at all? I guarded it with __KERNEL__ as you
> can see.

Your patch is fine of course. :) It's just that conflicts like this
have happened before. Another conflict is e.g. in wait.h where the
kernel has #define P_* and libc has an enum for P_* and it's not at all
guaranteed that they are identical. Plus, sometimes the order of header
inclusion matters because of things like this (or something like this).
That's why having it seen on libc-alpha might help prevent accidentaly
causing bugs where you now include a header that gives you a different
definition than you expected.

> 
> Resent with libc-alpha CC'd per your suggestion.

Thanks!

Christian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ