# 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 next.git/log/net/ipv4/fib_trie.c'>
path: root/net/ipv4/fib_trie.c
diff options
context:
space:
mode:
authorMarc Zyngier <marc.zyngier@arm.com>2017-01-17 16:00:48 +0000
committerThomas Gleixner <tglx@linutronix.de>2017-01-30 15:18:56 +0100
commit08d85f3ea99f1eeafc4e8507936190e86a16ee8c (patch)
tree410bb1acd0cd7dcfaad37ae7b63ff243b7fa4bee /net/ipv4/fib_trie.c
parent566cf877a1fcb6d6dc0126b076aad062054c2637 (diff)
irqdomain: Avoid activating interrupts more than once
Since commit f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early"), we can end-up activating a PCI/MSI twice (once at allocation time, and once at startup time). This is normally of no consequences, except that there is some HW out there that may misbehave if activate is used more than once (the GICv3 ITS, for example, uses the activate callback to issue the MAPVI command, and the architecture spec says that "If there is an existing mapping for the EventID-DeviceID combination, behavior is UNPREDICTABLE"). While this could be worked around in each individual driver, it may make more sense to tackle the issue at the core level. In order to avoid getting in that situation, let's have a per-interrupt flag to remember if we have already activated that interrupt or not. Fixes: f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early") Reported-and-tested-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1484668848-24361-1-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'net/ipv4/fib_trie.c')