# 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 elect name='qt'>
path: root/net/wireless/wext-compat.c
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2017-01-31 09:37:34 +0100
committerThomas Gleixner <tglx@linutronix.de>2017-01-31 21:47:58 +0100
commit0becc0ae5b42828785b589f686725ff5bc3b9b25 (patch)
treebe6d0e1f37c38ed0a7dd5da2d4b1e93f0fb43101 /net/wireless/wext-compat.c
parent24c2503255d35c269b67162c397a1a1c1e02f6ce (diff)
x86/mce: Make timer handling more robust
Erik reported that on a preproduction hardware a CMCI storm triggers the BUG_ON in add_timer_on(). The reason is that the per CPU MCE timer is started by the CMCI logic before the MCE CPU hotplug callback starts the timer with add_timer_on(). So the timer is already queued which triggers the BUG. Using add_timer_on() is pretty pointless in this code because the timer is strictlty per CPU, initialized as pinned and all operations which arm the timer happen on the CPU to which the timer belongs. Simplify the whole machinery by using mod_timer() instead of add_timer_on() which avoids the problem because mod_timer() can handle already queued timers. Use __start_timer() everywhere so the earliest armed expiry time is preserved. Reported-by: Erik Veijola <erik.veijola@intel.com> Tested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov <bp@alien8.de> Cc: Tony Luck <tony.luck@intel.com> Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701310936080.3457@nanos Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'net/wireless/wext-compat.c')