On Monday, November 3, 2008 02:22:12 Peter Volkov wrote:
> В Вск, 02/11/2008 в 12:11 -0700, Gordon Malm пишет:
> > You can cry "abuse" all you want. You FAIL to offer any alternatives or
> > solutions. I'll ask again, how do you detect that you are compiling code
> > destined to be run in-kernel from within gcc without checking for the
> > __KERNEL__ macro? I think we both know the answer.
>
> Gordon, as far as I see our linux-mod.eclass builds each kernel module
> separately and it is possible to modify it to pass CFLAGS you wish for
> kernel modules only and as such avoid using __KERNEL__ macro for this...
Peter, with much respect, this doesn't really address the question. Here is
the relevant snippet of hardened's gcc specs:
%(cc1_cpu) %{profile:-p} %{!D__KERNEL__: %{!static: %{!fno-PIC: %{!fno-pic:
%{!shared: %{!nostdlib: %{!nostartfiles: %{!fno-PIE: %{!fno-pie: %{!nopie:
%{!fPIC:
%{!fpic:-fPIE}}} } } } } } } } } %{!nostdlib: %{!fno-stack-protector:
-fstack-protector %{!D_LIBC: %{!D_LIBC_REENTRANT: %{!fno-stack-protector-all:
-fstack-protector-all} } } } } }
As you can see the __KERNEL__ macro is checked to decide which gcc specs to
apply any time hardened's gcc compiles anything. Patching linux-mod.eclass
isn't going to do anything to break our reliance on the __KERNEL__ macro.
What patching linux-mod.eclass *would* allow us to do is not patch distcc to
pass -D__KERNEL__ (which I have already done in the case of USE="hardened",
so really this is solved). The limitations of the linux-mod.eclass patching
approach is that it wouldn't work for any modules that use a standalone build
system (dumb as it that might be) instead of kbuild or any module being
compiled outside of portage (kbuild or not).
The linux-mod.eclass hacking could get pretty ugly. I haven't looked deeply
into it but KBUILD_CFLAGS is not yet defined at the time emake is called that
I can tell, so I don't think it will be as simple as adding something like
KBUILD_CFLAGS="${KBUILD_CFLAGS} -fmy -fflags -fhere". If I'm wrong please
let me know, I'd be grateful. :)
There's potentially a lot of conditionals involved as well as far as what
flags to add for a diversity of ARCHes, what the available out-of-tree
modules want for themselves, etc. Overall, linux-mod.eclass could start to
look really nasty and I think it would take quite awhile (for me alone at
least) to figure out a workable solution, if even possible. When accounting
that this would only address the problem for modules using Kbuild and built
within portage - I don't think its worth it for a partial solution.
Patching KBUILD_CFLAGS in the kernel sources themselves works, but if we don't
do that for every kernel portage we restrict users to using hardened-sources
when running a hardened toolchain w/o the hardened kernel is a perfectly
valid configuration. They wouldn't be able to use a non-gentoo provided
kernel without patching it as well. Plus, we're just *not* going to have
every kernel in the tree have a patch conditional on USE="hardened" (ick :).
Best regards,
Gordon Malm (gengor)
