genkernel 3.0.1c makes use of dietlibc-0.27 which doesn't build on uclibc. Previous versions of genkernel used a patched dietlibc-0.26 which worked well. Two solutions to solve this regression: keep the patched 0.26 if there is no reason to switch to 0.27, or try to get 0.27 to work under uclibc...
Koon can you paste the error please?
I swear I made it so... USE=diet (was optional)
I masked >3.1.0a to move on, but it was the usual guard symbol not found error. So it's more an hardened thing than an embedded one, I think :) I suspect the 0.27 used in genkernel doesn't have the dietlibc-0.26-ssp.patch. I will try again soon and post the error here if you need it.
This is the error I get when emerging dietlibc: bin-i386/dietlibc.a(errno_location.o)(.text+0xa): In function `__errno_location': : undefined reference to `__guard' bin-i386/dietlibc.a(errno_location.o)(.text+0x21): In function `__errno_location': : undefined reference to `__stack_smash_handler' bin-i386/dietlibc.a(execvp.o)(.text+0xb): In function `execvp': : undefined reference to `__guard' bin-i386/dietlibc.a(execvp.o)(.text+0x199): In function `execvp': : undefined reference to `__guard' bin-i386/dietlibc.a(execvp.o)(.text+0x1ac): In function `execvp': : undefined reference to `__stack_smash_handler' bin-i386/dietlibc.a(memmove.o)(.text+0xe): In function `memmove': : undefined reference to `__guard' bin-i386/dietlibc.a(memmove.o)(.text+0x55): In function `memmove': : undefined reference to `__guard' bin-i386/dietlibc.a(memmove.o)(.text+0x64): In function `memmove': : undefined reference to `__stack_smash_handler' bin-i386/dietlibc.a(strstr.o)(.text+0xd): In function `strstr': : undefined reference to `__guard' bin-i386/dietlibc.a(strstr.o)(.text+0x7b): In function `strstr': : undefined reference to `__stack_smash_handler' bin-i386/dietlibc.a(exec_lib.o)(.text+0xb): In function `__exec_shell': : undefined reference to `__guard' bin-i386/dietlibc.a(exec_lib.o)(.text+0x66): In function `__exec_shell': : undefined reference to `__guard' bin-i386/dietlibc.a(exec_lib.o)(.text+0x75): In function `__exec_shell': : undefined reference to `__stack_smash_handler' collect2: ld returned 1 exit status make: *** [bin-i386/diet] Error 1 I have the hardened flag set, and get the same error when running genkernel.
Oh, my dietlibc problem shows up on genkernel 3.1.0c. I mixed up the numbers. Sorry for that. Should I open this in a separate bug?
No, your error is the same as mine (both on 3.1.0c using dietlibc-0.27), ne need to open a separate bug. The workaround for hardened is to add >sys-kernel/genkernel-3.1.0a to your package.mask file.
This is not embedded-related but rather hardened-related.
This appears to be the change which broke things. diff -u dietlibc-0.26-r1.ebuild dietlibc-0.27.ebuild - if use x86 ; then - # Ok so let's make dietlibc ssp aware (Aug 7 2004) -solar - ebegin "Making dietlibc ssp aware" - cp ${FILESDIR}/ssp.c ${S}/lib/ || die "Failed to copy ssp.c into lib for compile" - eend $? - - # start with sparc/sparc64/x86_64/i386 for now. - epatch ${FILESDIR}/dietlibc-0.26-ssp.patch - append-flags -D__dietlibc__ - # end ssp block code - fi + # ${FILESDIR}/ssp.c is integrated with upstream as of dietlibc-0.26 + # - robbat2 (Oct 01 2004) + + # start with sparc/sparc64/x86_64/i386 for now. + # apply to all arches for crazy cross-compiling - robbat2 (Oct 01 2004) + epatch ${FILESDIR}/dietlibc-0.26-ssp.patch + append-flags -D__dietlibc__ + # end ssp block code + Adding robbat2@ to CC: list to find out why he thinks " ${FILESDIR}/ssp.c has been integrated with upstream as of dietlibc-0.26"
Created attachment 45338 [details, diff] dietlibc-0.27-20041205-solar.patch I confirmed the problem existed with 0.9.27 Commited update to CVS KEYWORDS="~x86 ~ppc ~sparc ~alpha ~arm ~hppa ~amd64 ~mips" ------------------------------------------------------------------------------ - Fixed misc ssp problems introduced from dietlibc-0.26-r1 -> dietlibc-0.27-r0 which were causing genkernel failures for hardened users. bug #73112 ------------------------------------------------------------------------------ Confirmed working. Glibc: solar@simple vuln $ cc vuln.c -o vuln -fstack-protector solar@simple vuln $ ./vuln 0x155ba8cc main(argc=0x59b395b0, argv=0x59b395b4, envp=0x59b395b8, auxv=0x59b395bc) __guard=0x27db5364 (Stack) Triggering an overflow by copying [20] of data into [10] of space vuln: stack smashing attack in function main() Aborted (core dumped) Dietlibc: solar@simple vuln $ diet cc vuln.c -o vuln -fstack-protector solar@simple vuln $ ./vuln 0x8048124 main(argc=0x5a81e714, argv=0x5a81e718, envp=0x5a81e71c, auxv=0x5a81e720) __guard=0x804c064 (Stack) Triggering an overflow by copying [20] of data into [10] of space dietapp: stack smashing attack in function main() Aborted (core dumped)
tar xvfj dietlibc-0.26.tar.bz2 (see the one bundled with genkernel for eg) md5sum ./files/ssp.c ./dietlibc-0.26/lib/ssp.c 8dcca4f3b79565a3c205dbb0ef2d20bd ./files/ssp.c 8dcca4f3b79565a3c205dbb0ef2d20bd ./dietlibc-0.26/lib/ssp.c that looks identical to me... but strangely seeing .27, the file isn't there.
bin-i386/dietlibc.a(exec_lib.o)(.text+0x74): In function `__exec_shell': : undefined reference to `__guard' bin-i386/dietlibc.a(exec_lib.o)(.text+0x8d): In function `__exec_shell': : undefined reference to `__stack_smash_handler' collect2: ld returned 1 exit status make: *** [bin-i386/diet] Error 1 * Gentoo Linux Genkernel; Version 3.1.0c * ERROR: Failed to compile the "prefix=/var/tmp/genkernel/diet" target... Using a portage snapshot built last night, using catalyst to try to make a livecd. I can snap another when there's a fix (gimme the ebuild and patch to overlay) and try again, though it'll take several hours. :) Seems to be the same bug as here.
Robin: The dietlibc-0.26 tarball shipped with genkernel-3.1.0a is a patched tarball, that's why the ssp.c file in there is the correct one, that's not because that made it upstream. genkernel directly uses the included tarball, it does not use the ebuild or add patches. That's why all needed patches must be included in the 0.27 tarball shipped with genkernel to fix it.
Re comment #12 from (Koon) Think that's why we still see the problem as listed in comment #11 from (John Moser) ?
Sure. The only way to test is to roll out a new genkernel tarball with a fully-patched-dietlibc tarball in it, and bump the ebuild so that it fetches the right tarball. Using an uptodate portage snapshot won't solve anything :) I might roll out a patched version later today for everyone to test.
Created attachment 45438 [details] genkernel-3.0.1d test ebuild This ebuild fetches a genkernel tarball which contains a dietlibc-0.27 tarball repacked with all current patches applied.
John: could you test it and report back here ?
*yawns* *wakes up* *blinks* *12:30pm* o.o . . . . hi o.o oh, sure, I'll inject that into my portage tree and have my script snapshot and rebuild livecd-stage1/2. I'll report back when it's done.
Created attachment 45491 [details] genkernel.log from last try ok what the. . . hum. The new ebuild let me get . . .FARTHER! :D b0rken der pr0grammen teh brake
Now your problem is with udev + klibc. Somebody other than myself that actually likes udev/2.6 will probably have to provide a patch to provide the stubs for this. (just hack up the cut down version used for dietlibc)
Yes, udev+hardened+genkernel do not play nice yet, and never did. You should disable udev by passing --no-udev as a gk_kernargs. As far as this bug is concerned (the regression in genkernel-3.1.0c), the 3.1.0d tarball appears to solve it. plasmaroo: how about putting this one in the tree (masked if you prefer) ? The only diff is the version in "genkernel" and the patched dietlibc tarball (I tarred up the current dietlibc-0.27.ebuild src_unpack result directory).
re comment #20: Is there a way to do that in the livecd-stage2 catalyst spec, or should I open a catalyst bug?
Re comment #21 Passing --no-udev as gk_kernargs in livecd-stage2.spec should do it : Example : -----------------------snip------------------------------ boot/kernel/gentoo/gk_kernargs: --no-bootsplash --no-udev -----------------------snip------------------------------
*** Bug 74527 has been marked as a duplicate of this bug. ***
Fixed in genkernel-3.1.0d; please reopen this bug if you have any problems. Thanks!
