mm: Allow slab_nomerge to be set at build time
Subsystems (3)
PATCH v2 1/1 mm: Allow slab_nomerge to be set at build time
Some hardened environments want to build kernels with slab_nomerge already set (so that they do not depend on remembering to set the kernel command line option). This is desired to reduce the risk of kernel heap overflows being able to overwrite objects from merged caches and changes the requirements for cache layout control, increasing the difficulty of these attacks. By keeping caches unmerged, these kinds of exploits can usually only damage objects in the same cache (though the risk to metadata exploitation is unchanged).
---
v2: split out of slab whitelisting series
--- Documentation/admin-guide/kernel-parameters.txt | 10 ++++++++-- init/Kconfig | 14 ++++++++++++++ mm/slab_common.c | 5 ++--- 3 files changed, 24 insertions(+), 5 deletions(-)
Documentation/admin-guide/kernel-parameters.txt +8 -2
@@ -3715,8 +3715,14 @@ slab_nomerge [MM] Disable merging of slabs with similar size. May be necessary if there is some reason to distinguish - allocs to different slabs. Debug options disable - merging on their own. + allocs to different slabs, especially in hardened + environments where the risk of heap overflows and + layout control by attackers can usually be + frustrated by disabling merging. This will reduce + most of the exposure of a heap attack to a single + cache (risks via metadata attacks are mostly + unchanged). Debug options disable merging on their + own. For more information see Documentation/vm/slub.txt. slab_max_order= [MM, SLAB]
init/Kconfig +14 -0
@@ -1891,6 +1891,20 @@ config SLOB endchoice +config SLAB_MERGE_DEFAULT + bool "Allow slab caches to be merged" + default y + help + For reduced kernel memory fragmentation, slab caches can be + merged when they share the same size and other characteristics. + This carries a risk of kernel heap overflows being able to + overwrite objects from merged caches (and more easily control + cache layout), which makes such heap attacks easier to exploit + by attackers. By keeping caches unmerged, these kinds of exploits + can usually only damage objects in the same cache. To disable + merging at runtime, "slab_nomerge" can be passed on the kernel + command line. + config SLAB_FREELIST_RANDOM default n depends on SLAB || SLUB
mm/slab_common.c +2 -3
@@ -47,13 +47,12 @@ static DECLARE_WORK(slab_caches_to_rcu_destroy_work,/* * Merge control. If this is set then no merging of slab caches will occur. -* (Could be removed. This was introduced to pacify the merge skeptics.) */ -static int slab_nomerge; +static bool slab_nomerge = !IS_ENABLED (CONFIG_SLAB_MERGE_DEFAULT );static int __init setup_slab_nomerge (char *str) { - slab_nomerge =1 ; + slab_nomerge = true;return 1 ; }
Signature · 12 lines
2.7.4 -- Kees Cook Pixel Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Randy Dunlap
reviewerQuoted 32 lines · Kees Cook
Some hardened environments want to build kernels with
slab_nomergealready set (so that they do not depend on remembering to set the kernel command line option). This is desired to reduce the risk of kernel heap overflows being able to overwrite objects from merged caches and changes the requirements for cache layout control, increasing the difficulty of these attacks. By keeping caches unmerged, these kinds of exploits can usually only damage objects in the same cache (though the risk to metadata exploitation is unchanged).Cc Daniel Micay <[email protected]>Cc David Windsor <[email protected]>Cc Eric Biggers <[email protected]>Signed-off-by Kees Cook <[email protected]>---
v2: split out of slab whitelisting series--- Documentation/admin-guide/kernel-parameters.txt | 10 ++++++++-- init/Kconfig | 14 ++++++++++++++ mm/slab_common.c | 5 ++--- 3 files changed, 24 insertions(+), 5 deletions(-)init/Kconfig +3
-0@@ -1891,6 +1891,20 @@ config SLOB endchoice +config SLAB_MERGE_DEFAULT + bool "Allow slab caches to be merged" + default y
init/Kconfig config SLOB · line 1906
Quoted 10 lines
init/Kconfig +10
-0+ help + For reduced kernel memory fragmentation, slab caches can be + merged when they share the same size and other characteristics. + This carries a risk of kernel heap overflows being able to + overwrite objects from merged caches (and more easily control + cache layout), which makes such heap attacks easier to exploit + by attackers. By keeping caches unmerged, these kinds of exploits + can usually only damage objects in the same cache. To disable + merging at runtime, "slab_nomerge" can be passed on the kernel + command line.
command line or this option can be disabled in the kernel config.
Quoted 4 lines
init/Kconfig +1
-0+ config SLAB_FREELIST_RANDOM default n depends on SLAB || SLUB
Signature · 1 line
~Randy
Quoted 30 lines · Randy Dunlap
Quoted 29 lines · Kees Cook
Some hardened environments want to build kernels with
slab_nomergealready set (so that they do not depend on remembering to set the kernel command line option). This is desired to reduce the risk of kernel heap overflows being able to overwrite objects from merged caches and changes the requirements for cache layout control, increasing the difficulty of these attacks. By keeping caches unmerged, these kinds of exploits can usually only damage objects in the same cache (though the risk to metadata exploitation is unchanged).Cc Daniel Micay <[email protected]>Cc David Windsor <[email protected]>Cc Eric Biggers <[email protected]>Signed-off-by Kees Cook <[email protected]>---
v2: split out of slab whitelisting series--- Documentation/admin-guide/kernel-parameters.txt | 10 ++++++++-- init/Kconfig | 14 ++++++++++++++ mm/slab_common.c | 5 ++--- 3 files changed, 24 insertions(+), 5 deletions(-)init/Kconfig +0
-0@@ -1891,6 +1891,20 @@ config SLOB endchoice
Quoted 15 lines
init/Kconfig config SLOB · line 1906
Quoted 13 lines
init/Kconfig +13
-0+config SLAB_MERGE_DEFAULT + bool "Allow slab caches to be merged" + default y + help + For reduced kernel memory fragmentation, slab caches can be + merged when they share the same size and other characteristics. + This carries a risk of kernel heap overflows being able to + overwrite objects from merged caches (and more easily control + cache layout), which makes such heap attacks easier to exploit + by attackers. By keeping caches unmerged, these kinds of exploits + can usually only damage objects in the same cache. To disable + merging at runtime, "slab_nomerge" can be passed on the kernel + command line.command line or this option can be disabled in the kernel config.
Isn't that implicit in that it is Kconfig help text? Happy to add it, but seems redundant to me.
-Kees
Quoted 8 lines
init/Kconfig config SLOB · line 1910
Quoted 5 lines
init/Kconfig +1
-0+ config SLAB_FREELIST_RANDOM default n depends on SLAB || SLUB--
~Randy
Signature · 8 lines
Kees Cook Pixel Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Randy Dunlap
reviewerQuoted 47 lines · Kees Cook
Quoted 30 lines · Randy Dunlap
Quoted 29 lines · Kees Cook
Some hardened environments want to build kernels with
slab_nomergealready set (so that they do not depend on remembering to set the kernel command line option). This is desired to reduce the risk of kernel heap overflows being able to overwrite objects from merged caches and changes the requirements for cache layout control, increasing the difficulty of these attacks. By keeping caches unmerged, these kinds of exploits can usually only damage objects in the same cache (though the risk to metadata exploitation is unchanged).Cc Daniel Micay <[email protected]>Cc David Windsor <[email protected]>Cc Eric Biggers <[email protected]>Signed-off-by Kees Cook <[email protected]>---
v2: split out of slab whitelisting series--- Documentation/admin-guide/kernel-parameters.txt | 10 ++++++++-- init/Kconfig | 14 ++++++++++++++ mm/slab_common.c | 5 ++--- 3 files changed, 24 insertions(+), 5 deletions(-)init/Kconfig +0
-0@@ -1891,6 +1891,20 @@ config SLOB endchoiceQuoted 15 lines
init/Kconfig config SLOB · line 1906
Quoted 13 lines
init/Kconfig +13
-0+config SLAB_MERGE_DEFAULT + bool "Allow slab caches to be merged" + default y + help + For reduced kernel memory fragmentation, slab caches can be + merged when they share the same size and other characteristics. + This carries a risk of kernel heap overflows being able to + overwrite objects from merged caches (and more easily control + cache layout), which makes such heap attacks easier to exploit + by attackers. By keeping caches unmerged, these kinds of exploits + can usually only damage objects in the same cache. To disable + merging at runtime, "slab_nomerge" can be passed on the kernel + command line.command line or this option can be disabled in the kernel config.
Quoted 3 lines
Isn't that implicit in that it is
Kconfighelp text? Happy to add it, but seems redundant to me.
Just trying for completeness instead of being implicit.
Quoted 12 lines
Quoted 9 lines
init/Kconfig config SLOB · line 1910
Quoted 6 lines
init/Kconfig +1
-0+ config SLAB_FREELIST_RANDOM default n depends on SLAB || SLUB--
~Randy
Signature · 1 line
~Randy
Quoted 8 lines · Kees Cook
Some hardened environments want to build kernels with
slab_nomergealready set (so that they do not depend on remembering to set the kernel command line option). This is desired to reduce the risk of kernel heap overflows being able to overwrite objects from merged caches and changes the requirements for cache layout control, increasing the difficulty of these attacks. By keeping caches unmerged, these kinds of exploits can usually only damage objects in the same cache (though the risk to metadata exploitation is unchanged).
Do we really want to have a dedicated config for each hardening specific kernel command line? I believe we have quite a lot of config options already. Can we rather have a CONFIG_HARDENED_CMD_OPIONS and cover all those defauls there instead?
Quoted 91 lines
Cc Daniel Micay <[email protected]>Cc David Windsor <[email protected]>Cc Eric Biggers <[email protected]>Signed-off-by Kees Cook <[email protected]>---
v2: split out of slab whitelisting series--- Documentation/admin-guide/kernel-parameters.txt | 10 ++++++++-- init/Kconfig | 14 ++++++++++++++ mm/slab_common.c | 5 ++--- 3 files changed, 24 insertions(+), 5 deletions(-)Documentation/admin-guide/kernel-parameters.txt +8
-2@@ -3715,8 +3715,14 @@ slab_nomerge [MM] Disable merging of slabs with similar size. May be necessary if there is some reason to distinguish - allocs to different slabs. Debug options disable - merging on their own. + allocs to different slabs, especially in hardened + environments where the risk of heap overflows and + layout control by attackers can usually be + frustrated by disabling merging. This will reduce + most of the exposure of a heap attack to a single + cache (risks via metadata attacks are mostly + unchanged). Debug options disable merging on their + own. For more information see Documentation/vm/slub.txt. slab_max_order= [MM, SLAB]init/Kconfig +14
-0@@ -1891,6 +1891,20 @@ config SLOB endchoice +config SLAB_MERGE_DEFAULT + bool "Allow slab caches to be merged" + default y + help + For reduced kernel memory fragmentation, slab caches can be + merged when they share the same size and other characteristics. + This carries a risk of kernel heap overflows being able to + overwrite objects from merged caches (and more easily control + cache layout), which makes such heap attacks easier to exploit + by attackers. By keeping caches unmerged, these kinds of exploits + can usually only damage objects in the same cache. To disable + merging at runtime, "slab_nomerge" can be passed on the kernel + command line. + config SLAB_FREELIST_RANDOM default n depends on SLAB || SLUBmm/slab_common.c +2
-3@@ -47,13 +47,12 @@ static DECLARE_WORK(slab_caches_to_rcu_destroy_work,/* * Merge control. If this is set then no merging of slab caches will occur. -* (Could be removed. This was introduced to pacify the merge skeptics.) */ -static int slab_nomerge; +static bool slab_nomerge = !IS_ENABLED (CONFIG_SLAB_MERGE_DEFAULT );static int __init setup_slab_nomerge (char *str) { - slab_nomerge =1 ; + slab_nomerge = true;return 1 ; }Signature · 12 lines
2.7.4 -- Kees Cook Pixel Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Signature · 8 lines
Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 10 lines · Michal Hocko
Quoted 8 lines · Kees Cook
Some hardened environments want to build kernels with
slab_nomergealready set (so that they do not depend on remembering to set the kernel command line option). This is desired to reduce the risk of kernel heap overflows being able to overwrite objects from merged caches and changes the requirements for cache layout control, increasing the difficulty of these attacks. By keeping caches unmerged, these kinds of exploits can usually only damage objects in the same cache (though the risk to metadata exploitation is unchanged).
Quoted 4 lines
Do we really want to have a dedicated config for each hardening specific kernel command line? I believe we have quite a lot of config options already. Can we rather have a
CONFIG_HARDENED_CMD_OPIONSand cover all those defauls there instead?
There's not been a lot of success with grouped Kconfigs in the past (e.g. CONFIG_EXPERIMENTAL), but one thing that has been suggested is a defconfig-like make target that would collect all the things together. I haven't had time for that, but that would let us group the various configs.
Additionally, using something like CONFIG_CMDLINE seems a little clunky to me.
-Kees
Signature · 8 lines
Kees Cook Pixel Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 11 lines · Kees Cook
Quoted 10 lines · Michal Hocko
Quoted 8 lines · Kees Cook
Some hardened environments want to build kernels with
slab_nomergealready set (so that they do not depend on remembering to set the kernel command line option). This is desired to reduce the risk of kernel heap overflows being able to overwrite objects from merged caches and changes the requirements for cache layout control, increasing the difficulty of these attacks. By keeping caches unmerged, these kinds of exploits can usually only damage objects in the same cache (though the risk to metadata exploitation is unchanged).
Quoted 8 lines
Quoted 4 lines
Do we really want to have a dedicated config for each hardening specific kernel command line? I believe we have quite a lot of config options already. Can we rather have a
CONFIG_HARDENED_CMD_OPIONSand cover all those defauls there instead?There's not been a lot of success with grouped Kconfigs in the past (e.g.
CONFIG_EXPERIMENTAL), but one thing that has been suggested is a defconfig-like make target that would collect all the things together.
Which wouldn't reduce the number of config options, would it? I don't know but is there any usecase when somebody wants to have hardened kernel and still want to have different defaults than you are suggesting?
Signature · 8 lines
Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>