kernel/config: enable security features #639
Conversation
|
/test |
CONFIG_RANDOMIZE_BASE Randomize the physical address at which the kernel image is decompressed and the virtual address where the kernel image is mapped, as a security feature that deters exploit attempts relying on knowledge of the location of kernel code internals CONFIG_RANDOMIZE_MEMORY Randomizes the base virtual address of kernel memory sections. This security feature makes exploits relying on predictable memory locations less reliable CONFIG_STACKPROTECTOR This feature puts, at the beginning of functions, a canary value on the stack just before the return address, and validates the value just before actually returning. Stack based buffer overflows now also overwrite the canary, which gets detected and the attack is then neutralized via a kernel panic. CONFIG_REFCOUNT_FULL Enabling this switches the ref counting infrastructure from a fast unchecked atomic_t implementation to a fully state checked implementation, which can be (slightly) slower but provides protections against various use-after-free conditions that can be used insecurity flaw exploits. CONFIG_HARDENED_USERCOPY This option checks for obviously wrong memory regions when copying memory to/from the kernel (via copy_to_user() and copy_from_user() functions) by rejecting memory ranges that are larger than the specified heap object, span multiple separately allocated pages, are not on the process stack,or are part of the kernel text. This kills entire classes of heap overflow exploits and similar kernel memory exposures. CONFIG_FORTIFY_SOURCE Detect overflows of buffers in common string and memory functionswhere the compiler can determine and validate the buffer sizes. fixes kata-containers#638 Signed-off-by: Julio Montes <julio.montes@intel.com>
devimc
force-pushed
the
topic/kernel/addSecurityConfigs
branch
from
38c218b to
435e20c
Compare
|
/test |
There was a problem hiding this comment.
Thanks @devimc!
lgtm
OOI, I wonder if there is any appreciable performance impact of using these options. We need the options but it would be useful to know what it is costing though.
|
@jodh-intel yes I agree, I going to raise a pr in runtime to test this change |
test kernel security features depends-on: github.com/kata-containers/packaging#639 fixes #1234567 Signed-off-by: Julio Montes <julio.montes@intel.com>
|
Metrics looked good. I think we would require a focused test / micro bench to see the impact of these. LGTM. |
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
test kernel security features Depends-on: github.com/kata-containers/packaging#639 fixes #1234567 Signed-off-by: Julio Montes <julio.montes@intel.com>
|
@egernst @jodh-intel @grahamwhaley this change will impact in the memory consumption (see kata-containers/runtime#1881) no-KSM: from139080.9 to 141586.42 in the case of KSM, I think it's expected because of the kernel memory randomization What do you think? should we merge it? |
|
@devimc - I think it should be the default. But users who really care about memory density may wish to create their own kernel without certain options (assuming they understand the implications of doing so). For that latter scenario, I still wonder whether we want to create the
It seems a little odd having the agent log this, but atleast we'd be able to log it somewhere. The alternative is that we store the config alongside each binary kernel image on the host - that way the throttler itself could check. |
|
Off the top of my head, I would have thought randomisation would not affect KSM, as KSM works on page contents, not their addresses (PA or VA) - but - the last page of http://www.syssec-project.eu/m/page-media/28/eurosec12-suzaki-slides.pdf says it has an effect, yes. I think it might be due to the way randomisation initialises the pages (possibly on free) - I didn't read the whole deck ;-0 |
|
I worry that open these security options will harm the performance of the guest kernel. And guest kernel already inside the VM that to handle the most of security issues, does KATA really need to open these options by default? |
|
@teawater - that's a valid concern. The default Kata stance should be to maximise security where reasonable to do so. The key word here being "reasonable"; there is precedent for not enabling a security feature by default due to the significant performance impact of doing so: We could allow the specification of some sort of "security preference" annotation to the runtime. Values could range from "none" (for maximum performance but potentially lowering security) to "omg-crazy-insane-security" (which could potentially impact performance negatively). The runtime could then potentially choose an appropriate kernel [1] that would satisfy that security preference. If no such kernel exists, the runtime would error and the workload would not be run. Iff we could somehow defer the decision to the agent (implying modules [2] probably), the agent could again arrange a suitable environment to run the workload in or again error and the workload would not be run (possibly related: #222). This could all get very complex very fast so I suggest you add this topic to the Architecture Committee agenda for discussion. [1] - This could be achieved partly by creating a [2] - Enabling guest kernel modules whilst bringing flexibility, could potentially impact performance and potentially impact security. |
|
@devimc - did you do a local metrics report generator run? Got any data you can post here? thx. |
|
@grahamwhaley nop, I didn't run any metrics, I got these numbers from the pnp-ci kata-containers/runtime#1881 |
|
I’m not sure how much we care about KSM, but rather the standard configuration. Curious for input from @gnawux @sameo @bergwolf @WeiZhang555 |
|
@Ace-Tang please take a look, do you have enabled KSM in your environment? |
|
@devimc - can you update as this branch is now conflicted? |
|
closing pr since with these change kernel will consume more memory |
CONFIG_RANDOMIZE_BASE
Randomize the physical address at which the kernel image is decompressed and
the virtual address where the kernel image is mapped, as a security feature
that deters exploit attempts relying on knowledge of the location of kernel
code internals
CONFIG_RANDOMIZE_MEMORY
Randomizes the base virtual address of kernel memory sections. This security
feature makes exploits relying on predictable memory locations less reliable
CONFIG_STACKPROTECTOR
This feature puts, at the beginning of functions, a canary value on the stack
just before the return address, and validates the value just before actually
returning. Stack based buffer overflows now also overwrite the canary, which
gets detected and the attack is then neutralized via a kernel panic.
CONFIG_REFCOUNT_FULL
Enabling this switches the ref counting infrastructure from a fast unchecked
atomic_t implementation to a fully state checked implementation, which can be
(slightly) slower but provides protections against various use-after-free
conditions that can be used insecurity flaw exploits.
CONFIG_HARDENED_USERCOPY
This option checks for obviously wrong memory regions when copying memory
to/from the kernel (via copy_to_user() and copy_from_user() functions) by
rejecting memory ranges that are larger than the specified heap object, span
multiple separately allocated pages, are not on the process stack,or are part
of the kernel text. This kills entire classes of heap overflow exploits and
similar kernel memory exposures.
CONFIG_FORTIFY_SOURCE
Detect overflows of buffers in common string and memory functionswhere the
compiler can determine and validate the buffer sizes.
fixes #638
Signed-off-by: Julio Montes julio.montes@intel.com