# config INTEGRITY bool "Integrity subsystem" depends on SECURITY default y help This option enables the integrity subsystem, which is comprised of a number of different components including the Integrity Measurement Architecture (IMA), Extended Verification Module (EVM), IMA-appraisal extension, digital signature verification extension and audit measurement log support. Each of these components can be enabled/disabled separately. Refer to the individual components for additional details. if INTEGRITY config INTEGRITY_SIGNATURE bool "Digital signature verification using multiple keyrings" depends on KEYS default n select SIGNATURE help This option enables digital signature verification support using multiple keyrings. It defines separate keyrings for each of the different use cases - evm, ima, and modules. Different keyrings improves search performance, but also allow to "lock" certain keyring to prevent adding new keys. This is useful for evm and module keyrings, when keys are usually only added from initramfs. config INTEGRITY_ASYMMETRIC_KEYS bool "Enable asymmetric keys support" depends on INTEGRITY_SIGNATURE default n select ASYMMETRIC_KEY_TYPE select ASYMMETRIC_PUBLIC_KEY_SUBTYPE select CRYPTO_RSA select X509_CERTIFICATE_PARSER help This option enables digital signature verification using asymmetric keys. config INTEGRITY_TRUSTED_KEYRING bool "Require all keys on the integrity keyrings be signed" depends on SYSTEM_TRUSTED_KEYRING depends on INTEGRITY_ASYMMETRIC_KEYS default y help This option requires that all keys added to the .ima and .evm keyrings be signed by a key on the system trusted keyring. config INTEGRITY_AUDIT bool "Enables integrity auditing support " depends on AUDIT default y help In addition to enabling integrity auditing support, this option adds a kernel parameter 'integrity_audit', which controls the level of integrity auditing messages. 0 - basic integrity auditing messages (default) 1 - additional integrity auditing messages Additional informational integrity auditing messages would be enabled by specifying 'integrity_audit=1' on the kernel command line. source security/integrity/ima/Kconfig source security/integrity/evm/Kconfig endif # if INTEGRITY rep'>log msg
path: root/net/llc/llc_c_ac.c
diff options
context:
space:
mode:
authorBorislav Petkov <bp@suse.de>2017-01-20 21:29:40 +0100
committerThomas Gleixner <tglx@linutronix.de>2017-01-23 09:39:55 +0100
commitc26665ab5c49ad3e142e0f054ca3204f259ba09c (patch)
tree3bab11918e18e9d25ef7544dba05cdf39d1abec5 /net/llc/llc_c_ac.c
parent7a308bb3016f57e5be11a677d15b821536419d36 (diff)
x86/microcode/intel: Drop stashed AP patch pointer optimization
This was meant to save us the scanning of the microcode containter in the initrd since the first AP had already done that but it can also hurt us: Imagine a single hyperthreaded CPU (Intel(R) Atom(TM) CPU N270, for example) which updates the microcode on the BSP but since the microcode engine is shared between the two threads, the update on CPU1 doesn't happen because it has already happened on CPU0 and we don't find a newer microcode revision on CPU1. Which doesn't set the intel_ucode_patch pointer and at initrd jettisoning time we don't save the microcode patch for later application. Now, when we suspend to RAM, the loaded microcode gets cleared so we need to reload but there's no patch saved in the cache. Removing the optimization fixes this issue and all is fine and dandy. Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading") Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170120202955.4091-2-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'net/llc/llc_c_ac.c')