KASLR is enabled by default.

Don't normalize this cmdline option.

SMEP and SMAP are enabled by default.

Explanations from the Linux kernel commit 6a6155f664e31c9be43cd:

When the kernel is compiled with Clang, -fsanitize=bounds expands to
-fsanitize=array-bounds and -fsanitize=local-bounds.

Enabling -fsanitize=local-bounds with Clang has the side-effect of
inserting traps.

That's why UBSAN_LOCAL_BOUNDS can enable the 'local-bounds' option
only when UBSAN_TRAP is enabled.

Android Open Source Project (AOSP):
https://source.android.com/docs/setup/build/building-kernels

Android Generic Kernel Image (GKI):
https://source.android.com/docs/core/architecture/kernel/gki-release-builds

Also add the GKI config `android13-5.10`.

Thanks to @h0t for the idea.

This script is still waiting for fixes from NixOS folks:
  Issue #63
  PR #64

Refers to the issue #71

Refers to the issue #71

The current result on arm64_full_hardened_5.17_clang.config (clang 12):

[+] Special report mode: show_fail
[+] Kconfig file to check: my/arm64_full_hardened_5.17_clang.config
[+] Detected architecture: ARM64
[+] Detected kernel version: 5.17
=========================================================================================================================
              option name               | type  |desired val | decision |      reason      | check result
=========================================================================================================================
CONFIG_GCC_PLUGINS                      |kconfig|     y      |defconfig | self_protection  | FAIL: CONFIG_CC_IS_GCC not "y"
CONFIG_STACKPROTECTOR_PER_TASK          |kconfig|     y      |defconfig | self_protection  | FAIL: not found
CONFIG_FORTIFY_SOURCE                   |kconfig|     y      |   kspp   | self_protection  | FAIL: not found
CONFIG_GCC_PLUGIN_LATENT_ENTROPY        |kconfig|     y      |   kspp   | self_protection  | FAIL: CONFIG_CC_IS_GCC not "y"
CONFIG_ZERO_CALL_USED_REGS              |kconfig|     y      |   kspp   | self_protection  | FAIL: not found
CONFIG_GCC_PLUGIN_RANDSTRUCT            |kconfig|     y      |   kspp   | self_protection  | FAIL: CONFIG_CC_IS_GCC not "y"
CONFIG_GCC_PLUGIN_STACKLEAK             |kconfig|     y      |   kspp   | self_protection  | FAIL: CONFIG_CC_IS_GCC not "y"
CONFIG_GCC_PLUGIN_RANDSTRUCT_PERFORMANCE|kconfig| is not set |  clipos  | self_protection  | FAIL: CONFIG_CC_IS_GCC not "y"
CONFIG_STACKLEAK_METRICS                |kconfig| is not set |  clipos  | self_protection  | FAIL: CONFIG_CC_IS_GCC not "y"
CONFIG_STACKLEAK_RUNTIME_DISABLE        |kconfig| is not set |  clipos  | self_protection  | FAIL: CONFIG_CC_IS_GCC not "y"

CONFIG_STACKPROTECTOR_PER_TASK, CONFIG_FORTIFY_SOURCE and CONFIG_ZERO_CALL_USED_REGS
will be supported for clang in future (WIP).

Use empty decision and reason for such kind of checks

These are very slow debugging features

Don't normalize this option value since the Linux kernel
doesn't use kstrtobool() for it.

Don't add CmdlineChecks in add_kconfig_checks() to avoid wrong results
when the tool doesn't check the cmdline.

A common pattern for checking the 'param_x' cmdline parameter
that __overrides__ the 'PARAM_X_DEFAULT' kconfig option:
  l += [OR(CmdlineCheck(reason, decision, 'param_x', '1'),
           AND(KconfigCheck(reason, decision, 'PARAM_X_DEFAULT_ON', 'y'),
               CmdlineCheck(reason, decision, 'param_x, 'is not set')))]

Here we don't check the kconfig options or minimal kernel version
required for the cmdline parameters. That would make the checks
very complex and not give a 100% guarantee anyway.

Having HARDENED_USERCOPY_FALLBACK disabled is not enough.

The Linux kernel 4.16-4.17 has a weird STACKPROTECTOR configuration:
CC_STACKPROTECTOR_NONE -- stackprotector is disabled;
CC_STACKPROTECTOR_REGULAR -- similar to current STACKPROTECTOR;
CC_STACKPROTECTOR_STRONG -- similar to current STACKPROTECTOR_STRONG;
CC_STACKPROTECTOR_AUTO -- the best stack-protector that compiler provides.
These options are mutually exclusive.

Let's improve the STACKPROTECTOR check:
- Add CC_STACKPROTECTOR_REGULAR as a valid alternative name of this option;
- Add CC_STACKPROTECTOR_STRONG to avoid false negative result;
- Add CC_STACKPROTECTOR_AUTO hoping that it enables at least STACKPROTECTOR.

The STACKPROTECTOR_STRONG check still requires explicit configuration, not
CC_STACKPROTECTOR_AUTO.

Thanks to @izh1979 for the idea