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]
Date:	Wed, 8 Aug 2012 15:43:14 +0300
From:	Ozan Çağlayan <ozancag@...il.com>
To:	"Luis R. Rodriguez" <mcgrof@...jolero.org>
Cc:	Ubuntu Kernel Team <kernel-team@...ts.ubuntu.com>,
	linux-kernel@...r.kernel.org,
	linux-wireless <linux-wireless@...r.kernel.org>,
	Hauke Mehrtens <hauke@...ke-m.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: Using vanilla kernels headers to do backport testing -- issues
 with memcpy()

On Tue, Aug 7, 2012 at 10:28 PM, Luis R. Rodriguez <mcgrof@...jolero.org> wrote:
> A while ago we reviewed the idea of whether or not to use a set of
> distribution vanilla kernels to allow us to do compilation testing of
> modules on the compat backport project [0] with the benefit being that
> at least one Linux distribution was doing this work already and given
> that this work was using plain vanilla kernels directly from
> kernel.org, with no modifications. The other option that existed was
> that each distro could provide their own set of kernel packages along
> with their own kernel headers but it didn't seem like other Linux
> distributions were doing this and the information was not easy to
> gather. So we went with the Ubuntu vanilla kernels and Ozan later
> figured out a way to extract deb packages in a distribution agnostic
> manner [1] and later added an option to enable a way to install and
> use this for ckmake which test compiles against 21 kernels without
> requiring root [2].
>
> This works swell as it allows anyone on any Linux distribution to test
> compile against a series of older kernels, today 21 older kernels and
> all vanilla kernels which means we get to focus and prioritize
> upstream.
>
> This has started working well except for the fact that as of the >=
> v3.4 vanilla kernel releases, there are a few files which are binary
> in the kernel headers which use dynamic libraries. Of interest to us
> here are the ones required to build external modules. An example:
>
> /lib/modules/3.4.4-030404-generic/build/scripts/genksyms/genksyms
>
> It just so happens to be that the folks building these packages are
> using a glibc >= 2.14 and although the *only* symbol I see being
> required from glibc >= 2.14 being memcpy():
>
> mcgrof@...banzo ~/compat (git::master)$ objdump -T
> /home/mcgrof/compat-ksrc/lib/modules/3.4.4-030404-generic/build/scripts/genksyms/genksyms
>
> /home/mcgrof/compat-ksrc/lib/modules/3.4.4-030404-generic/build/scripts/genksyms/genksyms:
>     file format elf64-x86-64
>
> DYNAMIC SYMBOL TABLE:
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.3.4 __snprintf_chk
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 free
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.3.4 __vfprintf_chk
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __errno_location
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 ferror
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 isatty
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fread
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fclose
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 strlen
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.4   __stack_chk_fail
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 getopt_long
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 strchr
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 _IO_putc
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fputs
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fgetc
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fputc
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __strdup
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __libc_start_main
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 strcmp
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 feof
> 0000000000000000  w   D  *UND*  0000000000000000              __gmon_start__
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 strtol
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 clearerr
>
>
> Bleh:
>
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.14  memcpy
>
>
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fileno
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 malloc
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 _IO_getc
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 ungetc
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 realloc
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.3.4 __printf_chk
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fopen
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 perror
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 exit
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 fwrite
> 0000000000000000      DF *UND*  0000000000000000  GLIBC_2.3.4 __fprintf_chk
> 000000000060b160 g    DO .bss   0000000000000008  GLIBC_2.2.5 stdout
> 000000000060b168 g    DO .bss   0000000000000008  GLIBC_2.2.5 stdin
> 000000000060b178 g    DO .bss   0000000000000008  GLIBC_2.2.5 stderr
> 000000000060b170 g    DO .bss   0000000000000008  GLIBC_2.2.5 optarg
>
> It would be reasonable to simply require the users of ckmake to update
> their libc version but even Debian sid does not yet seem to have libc
>>= 2.14, not sure of others. The gains for requiring a glibc >= 2.14
> only for memcpy() would seem rather small for this particular case so
> I wanted to review the options to fix this.

Can't we just rebuild genksyms in compat? I already have glibc 2.15 on
my system so I can't test this but normally this should adapt to the
build environment as it rebuilds and relinks the binary.

[root@...yfedora compat]# make -C
/lib/modules/2.6.36-02063604-generic/build M=scripts/genksyms
make: Entering directory `/usr/src/linux-headers-2.6.36-02063604-generic'
  HOSTCC  scripts/genksyms/genksyms.o
  HOSTCC  scripts/genksyms/lex.o
  HOSTCC  scripts/genksyms/parse.o
  HOSTLD  scripts/genksyms/genksyms
  Building modules, stage 2.
  MODPOST 0 modules
make: Leaving directory `/usr/src/linux-headers-2.6.36-02063604-generic'

One other thing that I have found is to force linking memcpy to a
hard-coded (namely GLIBC_2.2.5) memcpy() symbol. I didn't know about
this so I'm posting this as a reference:

make HOSTCFLAGS="-Wa,--defsym,memcpy=memcpy@...BC_2.2.5" -C
/lib/modules/2.6.36-02063604-generic/build M=scripts/genksyms
--
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/

Powered by blists - more mailing lists