On Fri, 20 May 2022 13:26:14 +0100
Simon Farnsworth via devel <devel@lists.fedoraproject.org> wrote:
> On Thursday, 19 May 2022 04:15:16 BST Hellosway Here via devel wrote:
> > Add `slab_nomerge init_on_alloc=1 init_on_free=1
> > page_alloc.shuffle=1 pti=on randomize_kstack_offset=on
> > vsyscall=none ` as default kernel command line arguments. This can
> > help prevent local exploits by making it harder to exploit the
> > kernel. I do not think there will be any breakage, I have been
> > using these for a long time. The performance impact is minimal, a
> > few of these can improve performance.
>
> A question, then: if these options are helpful to performance and/or
> security, why are they not yet the kernel's defaults?
>
> If there are tradeoffs that mean that these aren't suitable for
> general use, then Fedora needs to know what those tradeoffs are
> before it can make the decision, while if they're a simple net
> improvement, then upstream kernel developers should be happy to
> switch the defaults over without requiring a kernel argument.
>
> > This can help increase the security of Fedora, while also not
> > causing any other problems. Many users do not know what kernel
> > command line arguments are, so doing this will help them with the
> > security of their system. This does not address every problem, or
> > even most of them, but every little bit matters.
>
> If that's the case, why doesn't the upstream kernel switch them over?
> Is there an ABI break caused by some of these? A major performance
> regression on some workloads (if so, which workloads and does Fedora
> care)? Known bugs that upstream hasn't tracked down yet?
As an anecdotal point of reference, I compile a local custom kernel, and
have had kernel hardening set as defaults from their implementation. I
have not noticed any issues. With the 5.18 series, however, there was
a security measure that I didn't think I needed, so I didn't implement
it.
Initialize kernel stack variables at function entry (zero-init everything
(strongest and safest)) ---> │ │
│ │ [*] Poison
kernel stack before returning from syscalls
│ │
│ │ [ ]
Report stack depth analysis instrumentation
│ │
│ │ (100)
Minimum stack frame size of functions tracked by STACKLEAK
│ │
│ │ [ ] Show
STACKLEAK metrics in the /proc file system
│ │
│ │ [*]
Allow runtime disabling of kernel stack erasing
│ │
│ │ [*] Enable
heap memory zeroing on allocation by default
│ │
│ │ [*] Enable
heap memory zeroing on free by default
│ │
│ │ [*] Enable
register zeroing on function exit
I don't bother with the STACKLEAK metrics or stack depth analysis. I
also have the random implementations mentioned above turned on via
configuration options, and so compiled into the kernel as defaults.
These are all small hits to performance, and as someone in the US
Congress once said, 'a billion here and a billion there, and pretty soon
you're talking real money'.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
