Add an add_x86_only_kconfig_checks and an add_arm_only_kconfig_checks function

[jvoisin]

Splitting the checks by arch family makes the code a tad more readable and self-contains, and makes it easier to inspect what checks are architecture-specific, instead of having the read the whole file.

[jvoisin]

Is this something you're interested in @a13xp0p0v? Otherwise, I won't spend time resolving conflicts :)

[a13xp0p0v]

Hello @jvoisin,

This branch breaks the current order of the checks.

Let me describe the rationale, maybe we will create a better solution.

First, all checks in config_checklist are ordered by type:

1. kconfig checks
2. cmdline checks
3. sysctl checks

In each type, the checks are ordered by reason:

1. self_protection
2. security_policy
3. cut_attack_surface
4. harden_userspace

In each reason, the checks are ordered by decision starting from the most credible:

1. defconfig
2. kspp
3. grsec
4. maintainer
5. clipos
6. lockdown
7. a13xp0p0v

This ordering of the checks in kernel_hardening_checker/checks.py makes maintaining them much easier.

We also discussed this with @asarubbo in #113.

Does it sound reasonable?
Do you see how to improve the sorting of the checks?

[jvoisin]

I think it depends what we want to optimize for, code-wise: do we think it's easier to group checks by reason, or by architecture. I think the latter is more desirable, grouping by reason also makes sense.

What would be nice would be to actually group the checks, either in add_arm_only_kconfig_checks/add_x86_only_kconfig_checks/…, or in add_defconfig_kconfig_checks/add_kssp_kconfig_checks/… to make the grouping explicit and reduce the length of add_kconfig_checks. Happy to send a pull-request if you agree :)

[a13xp0p0v]

Thanks @jvoisin!

Explicit grouping by type + reason is a good idea.

We will return to this work when I update the checks according to the recent KSPP changes (b227085, thanks to Kees for the collaboration).

[a13xp0p0v]

By the way, I guess this refactoring will allow to do easy alphabetical sorting inside each group.

[jvoisin]

By the way, I guess this refactoring will allow to do easy alphabetical sorting inside each group.

That's the plan :>

[a13xp0p0v]

It's a big and important refactoring.
Let's return to this work after releasing a fresh version of kernel-hardening-checker.