Re: Include PaX / GRSecurity

Re: Include PaX / GRSecurity

[Stath, Paul]

Jens Lecius <incnews@jenslucius.de> write:

> I am trying to include the GRSecurity & PaX patches for the kernel in a Yocto build.
>
> The patch is applied to the kernel correctly, but when the build begins
> I get the following error:

> | Makefile:686: *** Your gcc installation does not support plugins. If
> the necessary headers for plugin support are missing, they should be
> installed.  On Debian, apt-get install gcc-<ver>-plugin-dev.  If you
> choose to ignore this error and lessen the improvements provided by this
> patch, re-run make with the DISABLE_PAX_PLUGINS=y argument..  Stop.

> Any ideas how to solve this? (Compile is on an Intel machine crosscompile for ARM)

> Thanks,
> Jens

By default, the gcc compiler built by Yocto is not configured with plug-in support.

To resolve this, I added a bbappend file for the gcc-cross recipe in my custom layer, which simply contained:

EXTRA_OECONF += "--enable-plugin"

This added the "--enable-plugin" flag to the do_configure task when configuring/building the gcc-cross compiler.

Note:  Where you add the "--enable-plugin" configure option will depend on which compiler needs plugin support.

Kernel features

[Ilya Dmitrichenko]

Today I have spent quite a while trying to figure how KERNEL_FEATURES
works and why some of the things I pass in my configuration fragment
are not getting enabled.

It turned out that some of the options no longer existed and some had
been renamed.

The question is really why would this not get detected by
kernel_configcheck or any other step?

I'm guessing this might be the case of how kconfig works, perhaps...
So I wonder whether anyone have looked into how we could actually get
the feature dependency graph from kconfig to bitbake or at least some
sort of helper tool? Perhaps parsing kconfig manifests in Python would
be a starting point...

Cheers,
-- 
Ilya

Re: Kernel features

[Bruce Ashfield]

On 2014-09-07, 4:51 AM, Ilya Dmitrichenko wrote:
> Today I have spent quite a while trying to figure how KERNEL_FEATURES
> works and why some of the things I pass in my configuration fragment
> are not getting enabled.
>
> It turned out that some of the options no longer existed and some had
> been renamed.

Do you have an example ? We try and not rename or remove public facing
configuration fragments, and hide the changing CONFIG_* values behind
the fragment names.

>
> The question is really why would this not get detected by
> kernel_configcheck or any other step?
>
> I'm guessing this might be the case of how kconfig works, perhaps...
> So I wonder whether anyone have looked into how we could actually get
> the feature dependency graph from kconfig to bitbake or at least some
> sort of helper tool? Perhaps parsing kconfig manifests in Python would
> be a starting point...

There have been many efforts are changing, writing and processing
Kconfig constructs in other languages .. they all end up being
pretty much a re-implementation of Kconfig, and hence a big effort
that needs to be continuously maintained over time .. also a big
effort.

But maybe I'm not quite understanding your question, if you can
send along an example, that might help.

Cheers,

Bruce

>
> Cheers,
>

Re: Kernel features

[Ilya Dmitrichenko]

Hi Bruce,

On 7 September 2014 15:17, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
> On 2014-09-07, 4:51 AM, Ilya Dmitrichenko wrote:
>>
>> Today I have spent quite a while trying to figure how KERNEL_FEATURES
>> works and why some of the things I pass in my configuration fragment
>> are not getting enabled.
>>
>> It turned out that some of the options no longer existed and some had
>> been renamed.
>
>
> Do you have an example ? We try and not rename or remove public facing
> configuration fragments, and hide the changing CONFIG_* values behind
> the fragment names.

Here is what I was doing first:

CONFIG_SND_OMAP_SOC=n
CONFIG_SND_OMAP_SOC_MCBSP=n
CONFIG_SND_OMAP_SOC_OMAP_TWL4030=n
CONFIG_SND_SOC_TWL4030=n
CONFIG_SND_AM335X_SOC_EVM=m
CONFIG_SND_AM33XX_SOC=m
CONFIG_SND_DAVINCI_SOC_MCASP=m
CONFIG_SND_HRTIMER=m

This is resulted in disabled options propagating as expected and
CONFIG_SND_HRTIMER worked as well.

The rest, however didn't.

It turned out that basically CONFIG_SND_AM335X_SOC_EVM is misspelled
and should be called CONFIG_SND_AM33XX_SOC_EVM. I think there must be
a way to verify whether this existed or not.

It then also turned out that CONFIG_SND_AM335X_SOC_EVM depends on
CONFIG_SND_DAVINCI_SOC, and I had to enable that one and ensure it
comes first.

This is a working set:

CONFIG_SND_OMAP_SOC=m
CONFIG_SND_OMAP_SOC_MCBSP=m
CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
CONFIG_SND_SOC_TWL4030=m
CONFIG_SND_DAVINCI_SOC=m
CONFIG_SND_AM33XX_SOC_EVM=m
CONFIG_SND_DAVINCI_SOC_MCASP=m
CONFIG_SND_HRTIMER=m


>> The question is really why would this not get detected by
>> kernel_configcheck or any other step?
>>
>> I'm guessing this might be the case of how kconfig works, perhaps...
>> So I wonder whether anyone have looked into how we could actually get
>> the feature dependency graph from kconfig to bitbake or at least some
>> sort of helper tool? Perhaps parsing kconfig manifests in Python would
>> be a starting point...
>
>
> There have been many efforts are changing, writing and processing
> Kconfig constructs in other languages .. they all end up being
> pretty much a re-implementation of Kconfig, and hence a big effort
> that needs to be continuously maintained over time .. also a big
> effort.

I basically think that we could do something better then blindly
throwing a set of options without verifying it.

The reason I mentioned Python was that I though of sharing Kconfig's
dependency graph with bitbake and thereby detecting errors like the
above.

As a user, this is what I'd love to see:

Error: The Kconfig option CONFIG_SND_AM335X_SOC_EVM that you have
specified doesn't exist. (Did you mean CONFIG_SND_AM33XX_SOC_EVM?)

Error: The Kconfig option CONFIG_SND_AM33XX_SOC that you have
specified doesn't exist. (Nothing similar exists)

Warning: The Kconfig option CONFIG_SND_DAVINCI_SOC_MCASP that you have
specified depends on CONFIG_SND_DAVINCI_SOC. I will enable
CONFIG_SND_DAVINCI_SOC as a module for you.

Hope this makes more sense.

Cheers,
-- 
Ilya

Re: Kernel features

[Bruce Ashfield]

On 2014-09-08, 1:50 AM, Ilya Dmitrichenko wrote:
> Hi Bruce,
>
> On 7 September 2014 15:17, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
>> On 2014-09-07, 4:51 AM, Ilya Dmitrichenko wrote:
>>>
>>> Today I have spent quite a while trying to figure how KERNEL_FEATURES
>>> works and why some of the things I pass in my configuration fragment
>>> are not getting enabled.
>>>
>>> It turned out that some of the options no longer existed and some had
>>> been renamed.
>>
>>
>> Do you have an example ? We try and not rename or remove public facing
>> configuration fragments, and hide the changing CONFIG_* values behind
>> the fragment names.
>
> Here is what I was doing first:
>
> CONFIG_SND_OMAP_SOC=n
> CONFIG_SND_OMAP_SOC_MCBSP=n
> CONFIG_SND_OMAP_SOC_OMAP_TWL4030=n
> CONFIG_SND_SOC_TWL4030=n
> CONFIG_SND_AM335X_SOC_EVM=m
> CONFIG_SND_AM33XX_SOC=m
> CONFIG_SND_DAVINCI_SOC_MCASP=m
> CONFIG_SND_HRTIMER=m
>
> This is resulted in disabled options propagating as expected and
> CONFIG_SND_HRTIMER worked as well.
>
> The rest, however didn't.

Aha. The kernel configuration audit would have told you that some
options were set, and didn't make it into the final .config

>
> It turned out that basically CONFIG_SND_AM335X_SOC_EVM is misspelled
> and should be called CONFIG_SND_AM33XX_SOC_EVM. I think there must be
> a way to verify whether this existed or not.
>
> It then also turned out that CONFIG_SND_AM335X_SOC_EVM depends on
> CONFIG_SND_DAVINCI_SOC, and I had to enable that one and ensure it
> comes first.

And the audit would have told you that you had an invalid option
(i.e. the misspelled one didn't appear in any Kconfig in the kernel).

>
> This is a working set:
>
> CONFIG_SND_OMAP_SOC=m
> CONFIG_SND_OMAP_SOC_MCBSP=m
> CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
> CONFIG_SND_SOC_TWL4030=m
> CONFIG_SND_DAVINCI_SOC=m
> CONFIG_SND_AM33XX_SOC_EVM=m
> CONFIG_SND_DAVINCI_SOC_MCASP=m
> CONFIG_SND_HRTIMER=m
>
>
>>> The question is really why would this not get detected by
>>> kernel_configcheck or any other step?
>>>
>>> I'm guessing this might be the case of how kconfig works, perhaps...
>>> So I wonder whether anyone have looked into how we could actually get
>>> the feature dependency graph from kconfig to bitbake or at least some
>>> sort of helper tool? Perhaps parsing kconfig manifests in Python would
>>> be a starting point...
>>
>>
>> There have been many efforts are changing, writing and processing
>> Kconfig constructs in other languages .. they all end up being
>> pretty much a re-implementation of Kconfig, and hence a big effort
>> that needs to be continuously maintained over time .. also a big
>> effort.
>
> I basically think that we could do something better then blindly
> throwing a set of options without verifying it.

Ah, but we do verify it. There's a check config task, that used to
be more visible, I got complaints and we hid it. I have a 1.7 task
to make it more visible again :)

>
> The reason I mentioned Python was that I though of sharing Kconfig's
> dependency graph with bitbake and thereby detecting errors like the
> above.
>
> As a user, this is what I'd love to see:
>
> Error: The Kconfig option CONFIG_SND_AM335X_SOC_EVM that you have
> specified doesn't exist. (Did you mean CONFIG_SND_AM33XX_SOC_EVM?)
>
> Error: The Kconfig option CONFIG_SND_AM33XX_SOC that you have
> specified doesn't exist. (Nothing similar exists)

Pretty much already done.

>
> Warning: The Kconfig option CONFIG_SND_DAVINCI_SOC_MCASP that you have
> specified depends on CONFIG_SND_DAVINCI_SOC. I will enable
> CONFIG_SND_DAVINCI_SOC as a module for you.

This one you can't do without parsing and evaluating all the Kconfigs,
which is expensive, and hard to do. We can do something basic by looking
at only the direct options within a particular Kconfig, since they are
immediately available.

But we do detect a whole set of other errors already, and for the most
part, they lead pretty quickly to the issue.

Bruce

>
> Hope this makes more sense.
>
> Cheers,
>

Include PaX / GRSecurity

[Jens Lucius]

I am trying to include the GRSecurity & PaX patches for the kernel in a 
Yocto build.

The patch is applied to the kernel correctly, but when the build begins 
I get the following error:

| Makefile:686: *** Your gcc installation does not support plugins. If 
the necessary headers for plugin support are missing, they should be 
installed.  On Debian, apt-get install gcc-<ver>-plugin-dev.  If you 
choose to ignore this error and lessen the improvements provided by this 
patch, re-run make with the DISABLE_PAX_PLUGINS=y argument..  Stop.

Any ideas how to solve this? (Compile is on an Intel machine 
crosscompile for ARM)

Thanks,

Jens