Re: [gentoo-dev] [PMS] Add RESTRICT="distcc" capability

[Gordon Malm <gengor@gentoo.org>]

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)