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>
i had disabled CONFIG_GCC_PLUGIN_LATENT_ENTROPY because this
fails to compile on riscv64.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
From the kernel documentation:
> Driver for the internal USB role switch for switching the USB data
> lines between the xHCI host controller and the dwc3 gadget controller
> found on various Intel SoCs. [...]
This may unblock USB-LAN-adaptor usage on certain boards, as reported
once in #12750. Overall affected devices seem to be scanty;
nevertheless, enabling this as a module only is highly unlikely to cause
any harm, so let's give it a try.
Signed-off-by: Peter Müller <peter.mueller@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 removes support for building IPFire for 32 bit ARM architectures.
This has been decided in August 2022 with six months notice as there are
not very many users and hardware is generally not available any more.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
It does not generate cryptographically secure entropy.
Backported from IPFire 3.x as 6aea180b26906f001611dcc0c54f494818069d8c.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremer@ipfire.org>
This patch also compiles all sorts of device mapper stuff as modules.
Backported from IPFire 3.x as 6fe31a44d07d8705ca7713c449ccbb3dbb9684a0.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremer@ipfire.org>
This is disabled in IPFire 3.x, and projects such as grsecurity
recommend doing so for security reasons as well. Also, skimming through
our source code, there is no point where this ACPI configfs would have
been explicitly mounted, which leads to the assumption that we never
used it anyway.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremer@ipfire.org>
From the kernel's documentation:
> Landlock is a sandboxing mechanism that enables processes to restrict
> themselves (and their future children) by gradually enforcing
> tailored access control policies. A Landlock security policy is a
> set of access rights (e.g. open a file in read-only, make a
> directory, etc.) tied to a file hierarchy. Such policy can be
> configured and enforced by any processes for themselves using the
> dedicated system calls: landlock_create_ruleset(),
> landlock_add_rule(), and landlock_restrict_self().
There is no harm in enabling this security feature, so applications
supporting Landlock can benefit from it.
Rolled forward from https://patchwork.ipfire.org/project/ipfire/patch/d7ac0caf-5a7c-bcca-6293-16c773523942@ipfire.org/
to submit all kernel-related changes as a single patchset.
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-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>
