Summary: | sys-boot/grub-0.97 - pci.c:143: error: can't find a register in class `BREG' while reloading `asm' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Maciej Grela <thermal> |
Component: | Hardened | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | alanh, bertrand, blueness, bugs.gentoo.org, gengor, hardened, oliver, vapier |
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
workaround for netboot compilation
grub-0.97-pie-safety.patch Add -fno-PIE to CFLAGS |
Description
Maciej Grela
2006-07-05 02:28:50 UTC
*** Bug 146354 has been marked as a duplicate of this bug. *** 0.97-r2 builds fine in hardened env Yes, 0.97-r2 does build fine without the "netboot" USE flag, but doesn't build with it. Have you tried with the "netboot" use flag ? *** Bug 146354 has been marked as a duplicate of this bug. *** Not fixed, reopening. It makes no sense to try to build netboot with PIE. pxeboot and nbgrub are standalone executables - completely standalone; no kernel let alone libc. You could do something like: if use netboot; then SAVE_CFLAGS=${CFLAGS} filter-flags -fPIE ... econf ... emake ... make clean CFLAGS=${SAVE_CFLAGS} fi in the netboot compilation section. that wont help ... grub already ignores CFLAGS the pie crap is coming from the specs (In reply to comment #7) > that wont help ... grub already ignores CFLAGS No it doesn't. It clears environment CFLAGS unless USE=custom-cflags, however CFLAGS set in the build where I suggested has the expected effect. > the pie crap is coming from the specs I know where the default PIE comes from, and calling it "pie crap" is not helpful. However, it also needs ssp disabled (for the same reasons) but even then it falls over as it can't find __outw and friends for reasons I don't have time right now to discover. The easiest thing to do for now would be to force the vanilla compiler for this package - something like: [[ -f $($(tc-getCC) -print-search-dirs | awk '$1=="install:" { print $2 }')/vanilla.specs ]] && export GCC_SPECS="vanilla.specs" at the start of src_compile(). > No it doesn't. It clears environment CFLAGS unless USE=custom-cflags, however
> CFLAGS set in the build where I suggested has the expected effect.
and if you're using USE=custom-cflags and grub fails to emerge: NOTABUG
(In reply to comment #9) > > No it doesn't. It clears environment CFLAGS unless USE=custom-cflags, however > > CFLAGS set in the build where I suggested has the expected effect. > > and if you're using USE=custom-cflags and grub fails to emerge: NOTABUG What does that have to do with it? My point was that (_regardless_ whether USE=custom-cflags or not) if CFLAGS is set inside the ebuild then it _does_ get passed to the compiler, which you had asserted was not the case. So, this is still a problem - is there a real solution ??? Curious myself also, bumped into this problem too. Is there a workaround for it (without compromising the stability or security of the server grub is being installed on)? I wanted to setup my server as a PXE server to be able to serve gentoo install images or memtest images etc. so the security of the clients doesn't matter as much as the security of server itself. you're really worrying over nothing grub is the bootloader so worrying about buffer overflows in grub is pointless from a security point of view I agree here too, but it'd just be nice to be able to build grub with the "netboot" use flag. Created attachment 106175 [details, diff]
workaround for netboot compilation
Although not the best approach, it works around the netboot problem for now.
Due to the fact that pci.c uses inline assembly to do it's work and that's why building fails, we can avoid these inline assembly calls by going direct using the --enable-pci-direct.
The attached patch does that when netboot is enabled. So it may not work for everyone.
any progress/news on this one? Anyone ??? i'm using the attached workaround. also, i'm just using the netboot flag on my chrooted env. which isn't hardened so it's all good for me. it's still 'broken' though. I had this same problem and solved it by emergeing grub-static instead. Would this be correct ? It'd be considered a workaround, i'll work, but it won't be 'optimized' for your arch and what not. Hi all I has same error "error: can't find a register in class `BREG' while reloading `asm'" when compiling some packages. I find solution how to write rite code for x86&amd64 for building using gcc’s -fPIC flag in this and similar situations: http://sam.zoy.org/blog/2007-04-13-shlib-with-non-pic-code-have-inline-assembly-and-pic-mix-well Can any body write patch, ask for that developers of grub, or try me? *** Bug 250808 has been marked as a duplicate of this bug. *** Created attachment 195840 [details, diff]
grub-0.97-pie-safety.patch
Please apply this patch to the sources and test it.
Should apply on top of all the other patches.
Grub does compile with it, but I don't have a hardened system to test if the generated grub is still bootable.
hardened: please test the patch I attached in the last comment, then I can include it into a final -r10 of Grub1. Marking the grub version in the bug so it can be tracked specifically. Please test the patch! The patch allows =sys-boot/grub-0.97-r9 to compile with USE="netboot" on hardened amd64 and x86. The resultant grub still boots from local disk fine. However, I do not have the means to test PXE booting at this time, which is what really matters. Thankfully a hardened contributor on IRC is able to test the PXE aspect and report here shortly. Thanks Robin and to everyone else who has worked this bug. I compiled grub-0.97-r9 with this patch on both x86 and amd64. It does compile on both but the resulting pxegrub leads to a kernel stack fault. I tested this on a vmware virtual machine (emulating e1000), on an HP t5135 thin client (via-rhine) and on a desktop (forcedeth). In each case, as soon as control is passed to pxegrub, the cpu does a hard reset and the system reboots. Ok, so my patch is fail. If you can trace which function is causing it, that would be nice, but I think it's going to be really hard to do :-(. Patch now unqueued. Created attachment 197595 [details, diff]
Add -fno-PIE to CFLAGS
Thanx for testing Anthony Basile.
Robin, any objections to the -fno-PIE build patch? *** This bug has been marked as a duplicate of bug 281246 *** |