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 files.
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 problem.
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.
Thoughts?
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 files.
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 problem.
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.
Thoughts?
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.
-Corey
On 19/12/07 13:51 -0500, Corey Osgood wrote:
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 files.
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 problem.
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.
Thoughts?
I'll be brutally honest: I don't like either one.
Don't for a minute think that I enjoy doing this - -fno-stack-protector is a pain in the tuckus. But, its the world we live in, and if there is one thing I've learned over the years, its that there will _always_ be a "broken" distribution. Today it is Ubuntu, but Redhat/Fedora and SuSE have had their moments in the sun too.
Jordan
On Wed, Dec 19, 2007 at 10:53:44AM -0700, Jordan Crouse wrote:
So I leave it to the community - which solution do we prefer?
I like fixing it in LB.
We already know Config.lb is not optimal, but I don't think it will ever be replaced in v2 so may as well carry on with it.
//Peter
On Dec 19, 2007 9:53 AM, Jordan Crouse jordan.crouse@amd.com wrote:
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 files.
Use this patch. fix it at the source. Fix ALL boards. This would help lots of people.
But CPU_OPT is a non-obvious name for something that fixes -fno-stack-protector. That's the only problem I can see.
We can then fix buildtarget to set CPU_OPT as needed, and fix it from that side too.
ron
On 20/12/07 09:27 -0800, ron minnich wrote:
On Dec 19, 2007 9:53 AM, Jordan Crouse jordan.crouse@amd.com wrote:
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 files.
Use this patch. fix it at the source. Fix ALL boards. This would help lots of people.
But CPU_OPT is a non-obvious name for something that fixes -fno-stack-protector. That's the only problem I can see.
I tried to use existing variables where I could. If we are willing to do the work, we add a new variable instead.
DISTRO_BREAKAGE has a nice ring to it.
We can then fix buildtarget to set CPU_OPT as needed, and fix it from that side too.
Well, if we do it from buildtarget, can we just insert the flag into CFLAGS or something like that automatically? That would solve the whole problem without any additional patches to the Config.lb.
Jordan
Here's where the action is in build_target:
# make sure config.py is up-to-date
export PYTHONPATH=$config_dir $PYTHON $config_py $config_lb $lbpath
exit $?
This is at the end.
So we could, at the end, before exit, compute the distro-specific flags and then append them to $build_dir/Makefile.settings and $build_dir/*/Makefile.settings (I'm sorry for this part, I can only say mea culpa. Somebody got clever). Then all makefiles would pick that up -- they all include it.
That would probably do it.
ron
On 20/12/07 09:50 -0800, ron minnich wrote:
Here's where the action is in build_target:
# make sure config.py is up-to-date
export PYTHONPATH=$config_dir $PYTHON $config_py $config_lb $lbpath
exit $?
This is at the end.
So we could, at the end, before exit, compute the distro-specific flags and then append them to $build_dir/Makefile.settings and $build_dir/*/Makefile.settings (I'm sorry for this part, I can only say mea culpa. Somebody got clever). Then all makefiles would pick that up -- they all include it.
That would probably do it.
This is the right solution - it will fix us now and forever (or until V3, which ever comes first).
but I don't claim to be a buildtarget hacker - if somebody can get a patch going, I'll test.
This is what buildrom does to check for the flag (paraphrasing from the Make syntax):
$(CC) -fno-stack-protector -xc /dev/null -o .$$.tmp > /dev/null 2>&1
If successful then the flag is valid. Error and its not.
Again, hugs and kisses to the gcc guys for making this so easy for us.
Jordan
Try this. This patch to buildtarget 1. sets up cpu opt for the no stack protector thing 2. sets up the makefiles for the target 3. the target builds But it's not picking up CPU_OPT. So we MUST have the other patch that ALWAYS includes CPU_OPT.
That said, I'd rather make the variable DISTRO_CC_OPT or some such.
Thanks
ron
-
Corey Osgood -
Jordan Crouse -
Peter Stuge -
ron minnich