Including Kernel Hardening Flags in linux-qcom-next

[abhilash-manna]

Working on enabling several kernel hardening flags in our custom Yocto-based kernel recipe.

After consulting with upstream maintainers, we were advised to use:

KERNEL_FEATURES:append = " features/security/security.scc" which pulls scc files form yocto-kernel-cache.

However, we want to ensure our approach aligns with Yocto mainline practices, where yocto-kernel-cache holds feature-based configuration files.
These are typically enabled using the "KERNEL_FEATURES:append" variable, which pulls in .scc files that reference relevant config fragments.

e.g. of security flags that we are looking @

• CONFIG_SLAB_FREELIST_RANDOM=y
• CONFIG_SLAB_FREELIST_HARDENED=y
• CONFIG_HARDENED_USERCOPY=y
• CONFIG_FORTIFY_SOURCE=y

....

I don't see .scc file being used in linux-qcom-next — or am I missing something?
What would be the recommended approach to enable these configs: should we go with security.cfg under configs/, or is there a better way suggested?

[shashim-quic]

We have other option to use kernel community hosted kernel/configs/hardening.config.

Would that be a better choice ?

[rsiddoji]

@shashim-quic , thanks we are going to re-use haredening.config and now tracked with PR #1214

[ricardosalveti]

@shashim-quic , thanks we are going to re-use haredening.config and now tracked with PR #1214

It is bound to a distro feature, shouldn't we just include it by default? I don't see why create a different distro feature and yet another image permutation for things that shouldn't really break the system.

[abhilash-manna]

@shashim-quic , thanks we are going to re-use haredening.config and now tracked with PR #1214

It is bound to a distro feature, shouldn't we just include it by default? I don't see why create a different distro feature and yet another image permutation for things that shouldn't really break the system.

I agree with your point.
Since it is already tied to a distro feature and does not introduce any risk or system instability,
including it by default is the practical approach.
Let me raise a new change to make this the default behavior.

[abhilash-manna]

Enabled hardened feature default to build and now tracked with PR #1223

[github-actions]

This issue has been marked as stale due to 30 days of inactivity. To prevent automatic closure in 5 days, remove the stale label or add a comment. You can reopen a closed issue at any time.