[LinuxBIOS] Possible stack protect solutions
corey.osgood at gmail.com
Wed Dec 19 19:51:02 CET 2007
Jordan Crouse wrote:
> I need a community vote. There is an lingering stack protect issue
> in LinuxBIOS, and it hits us when we port new platforms. The problem is
> that not all of the lines in the various Config.lb files that compile
> code also include the $(CPU_OPT) variable that we use to pass in the
> -fno-stack-protector from buildrom.
> So I offer these two possible solutions. One is a patch to buildrom that
> changes how we pass in the -fno-stack-protect flag (thanks to Marc for
> the patch). The other is a patch to LinuxBIOS itself to fix the actual
> problem and pass $(CPU_OPT) where appropriate in the mainboard Config.lb
> So I leave it to the community - which solution do we prefer? One one
> hand, the buildrom solution only affects targets when built by buildrom,
> so abuild and other tools aren't affected, though it glosses over the real
> On the other hand, any tools who may find CPU_OPT useful for their own
> uses will hit this too, but it is far more likely to break things.
I'll be brutally honest: I don't like either one. The buildrom patch, as
you've said, only affects buildrom, so it still leaves the issue of
manually building (an easy fix, but nonetheless an annoying one) and
also abuild. IMO, the best test will be when we can do abuild on stock
ubuntu with a fresh checkout.
The linuxbios patch only fixes cache-as-ram based boards, but is much
more promising IMO. If we can extend that into ROMCC without breaking
anything fragile, it'll be good. But there's always the if ;)
BTW, I'm happy to say I've finally gotten rid of ubuntu on both my main
machines, and am much happier with opensuse, until something breaks. I
do still have one machine left that I can test any patches you want to
throw out with.
More information about the coreboot