can't add version check for constraints in a logical product about kernel-hardening-checker

[a13xp0p0v]

Hello @tych0!
I'm glad that you had a look at this project!
How are you doing? :)

Yes, currently the combination of ComplexOptCheck objects is not supported (there have been no cases that needed it).

The original logic behind X86_UMIP check:

• if X86_UMIP or X86_INTEL_UMIP is set to y, then OK;
• otherwise FAIL.

What is the purpose of combining UMIP check with version check?

I designed VerCheck for cases like that:

• if REFCOUNT_FULL is set to y, then OK;
• if kernel version >= 5.5, then OK (since REFCOUNT_FULL is enabled by default and dropped since v5.5);
• otherwise FAIL.

N.B. There is an implicit drawback with checking kernel versions.
Some kernel features are backported to previous stable kernels.
That's why checking the version can give false positive or false negative result.
Detailed example: #32

Thanks!

[tych0]

On Sat, Mar 28, 2020 at 01:55:08PM -0700, Alexander Popov wrote: Hello @tych0! I'm glad that you had a look at this project! How are you doing? :)

Good, just hacking away :)

Yes, currently the combination of `ComplexOptCheck` objects is not supported (there have been no cases that needed it). The original logic behind `X86_UMIP` check: - if `X86_UMIP` or `X86_INTEL_UMIP` is set to `y`, then `OK`; - otherwise `FAIL`. What is the purpose of combining `UMIP` check with version check?

It's only present in 4.15 or greater; I'm running a 4.14 kernel and kconfig-hardened-check is complaining at me :)

I designed `VerCheck` for cases like that: - if `REFCOUNT_FULL` is set to `y`, then `OK`; - if kernel version >= `5.5`, then `OK` (since `REFCOUNT_FULL` is enabled by default and dropped since v5.5); - otherwise `FAIL`. N.B. There is an implicit drawback with checking kernel versions. Some kernel features are backported to previous stable kernels. That's why checking the version can give false positive or false negative result. Detailed example: #32

"Not present" is also risky though, if people don't have some of the dependencies of a feature enabled. A version whitelist seems the best.

[a13xp0p0v]

What is the purpose of combining UMIP check with version check?

It's only present in 4.15 or greater; I'm running a 4.14 kernel and kconfig-hardened-check is complaining at me :)

Yes, that's good. The tool inspires you to switch onto a newer kernel :)

"Not present" is also risky though, if people don't have some of the
dependencies of a feature enabled.

You know, I haven't seen any example of such unmet dependencies. I suppose that kernel feature dependencies are resolved by Kconfig.

A version whitelist seems the best.

I would like to avoid version checking as much as possible.
Relying on kernel version brings so many troubles!
For example:

• sometimes new features are backported to previous stable kernels,
• sometimes Linux distributions cherry-pick features into their kernels,
• some Linux distributions have custom kernel versioning scheme -- look at Ubuntu or Red Hat.

Finally, the most important aspect.
I like that kernels of different versions are checked against the same list of recommendations.
Hence they can be compared using OK/FAIL numbers that are printed by the tool in the end:

[+] config check is finished: 'OK' - 55 / 'FAIL' - 77

[a13xp0p0v]

@tych0 your issue reminded me the idea to create some formatted annotations, that can be used for muting checks for a particular kernel. That was discussed in #9.
Thank you.

[tych0]

Sorry, I read this and forgot to respond :)

Yes, that's good. The tool inspires you to switch onto a newer kernel :)

Yes, but switching is not so easy sometimes, because of institutional challenges. If we want to add this to our CI to check our kernel configs or something, it would be nice to exclude stuff that doesn't exist in our kernel. I can do this manually, but it would be nicer to have this knowledge baked into the script.

You know, I haven't seen any example of such unmet dependencies. I suppose that kernel feature dependencies are resolved by Kconfig.

Consider GCC_PLUGIN_STACKLEAK; we'll report "Not present" if the user hasn't set CONFIG_GCC_PLUGINS=n, but it really should be an error.

[tych0]

Anwyay, I'll check out the updates, thanks :)