This has been our default setting on x86_64 for quite some time now,
which is why this patch aligns the aarch64 kernel configuration to that
value.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This subsystem has been a frequent source of security vulnerabilities
affecting the Linux kernel; as a result, Google announced on June 14,
2023, that they would disable it in their environment as widely as
possible.
IPFire does not depend on the availability of io_uring. Therefore,
disable this subsystem as well in order to preemptively cut attack
surface.
See also: https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Compiling the kernel has automatically introduced
CONFIG_INIT_STACK_ALL_ZERO=y and removed GCC's structleak plugin (not to
be confused with its stackleak counterpart). However, according to
related documentation, this neither introduces a security nor
performance disadvantage.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
This change enables support for NXP's QorIQ/Layerscape platforms,
specifically the Traverse Technologies Ten64 (LS1088A).
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
Since last time we checked, the kernel's security features on ARM have
improved notably (see CONFIG_RANDOMIZE_BASE discussion). This patch
therefore proposes to give the seccomp filter on both 32- and 64-bit ARM
another try, since it provides significant security benefit to
applications using it.
Due to operational constraints, rootfile changes have been omitted, and
will be conducted, should this patch be approved.
Note to future self: Once this patch is approved, applications using
seccomp (OpenSSH, Tor) need to be updated/shipped on ARM.
Fixes: #12366Fixes: #12370
Cc: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
From the kernels' documentation:
> Uprobes is the user-space counterpart to kprobes: they
> enable instrumentation applications (such as 'perf probe')
> to establish unintrusive probes in user-space binaries and
> libraries, by executing handler functions when the probes
> are hit by user-space applications.
>
> ( These probes come in the form of single-byte breakpoints,
> managed by the kernel and kept transparent to the probed
> application. )
To the best of the authors' understanding, no application on IPFire
needs this functionality, and given its abuse potential, we should
probably not enable it.
As expected, strace functionality is not impaired by this.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
From the kernel documentation:
> 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. [...]
Thus, it is more sane to leave slab merging disabled. KSPP and ClipOS
recommend this as well.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremer@ipfire.org>
