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 --- config/kernel/kernel.config.aarch64-ipfire | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/config/kernel/kernel.config.aarch64-ipfire b/config/kernel/kernel.config.aarch64-ipfire index 0d7c1ba8a..46bfb1bb3 100644 --- a/config/kernel/kernel.config.aarch64-ipfire +++ b/config/kernel/kernel.config.aarch64-ipfire @@ -7190,9 +7190,9 @@ CONFIG_IOMMU_IO_PGTABLE_LPAE=y # CONFIG_IOMMU_IO_PGTABLE_DART is not set # end of Generic IOMMU Pagetable Support

-# CONFIG_IOMMU_DEFAULT_DMA_STRICT is not set +CONFIG_IOMMU_DEFAULT_DMA_STRICT=y # CONFIG_IOMMU_DEFAULT_DMA_LAZY is not set -CONFIG_IOMMU_DEFAULT_PASSTHROUGH=y +# CONFIG_IOMMU_DEFAULT_PASSTHROUGH is not set CONFIG_OF_IOMMU=y CONFIG_IOMMU_DMA=y CONFIG_ROCKCHIP_IOMMU=y

Hello Peter,

On 13 Oct 2023, at 10:03, Peter Müller peter.mueller@ipfire.org wrote:

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.

Do we not? I do not see how this would affect IPFire.

See also: https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.ht...

"While io_uring brings performance benefits, and promptly reacts to security issues with comprehensive security fixes (like backporting the 5.15 version to the 5.10 stable tree), it is a fairly new part of the kernel. As such, io_uring continues to be actively developed, but it is still affected by severe vulnerabilities and also provides strong exploitation primitives. For these reasons, we currently consider it safe only for use by trusted components.”

We technically only run “trusted components”. I could not find any means how these issues can be exploited remotely. Do you have any reports/vulnerabilities that I have missed?

Signed-off-by: Peter Müller peter.mueller@ipfire.org

config/kernel/kernel.config.aarch64-ipfire | 3 +-- config/kernel/kernel.config.x86_64-ipfire | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/config/kernel/kernel.config.aarch64-ipfire b/config/kernel/kernel.config.aarch64-ipfire index 96944c3d5..0d7c1ba8a 100644 --- a/config/kernel/kernel.config.aarch64-ipfire +++ b/config/kernel/kernel.config.aarch64-ipfire @@ -229,7 +229,7 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y -CONFIG_IO_URING=y +# CONFIG_IO_URING is not set CONFIG_ADVISE_SYSCALLS=y CONFIG_MEMBARRIER=y CONFIG_KALLSYMS=y @@ -7824,7 +7824,6 @@ CONFIG_NLS_MAC_TURKISH=m CONFIG_NLS_UTF8=m # CONFIG_DLM is not set # CONFIG_UNICODE is not set -CONFIG_IO_WQ=y # end of File systems

# diff --git a/config/kernel/kernel.config.x86_64-ipfire b/config/kernel/kernel.config.x86_64-ipfire index 129e0d209..48fdbd8ff 100644 --- a/config/kernel/kernel.config.x86_64-ipfire +++ b/config/kernel/kernel.config.x86_64-ipfire @@ -249,7 +249,7 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y -CONFIG_IO_URING=y +# CONFIG_IO_URING is not set CONFIG_ADVISE_SYSCALLS=y CONFIG_MEMBARRIER=y CONFIG_KALLSYMS=y @@ -7047,7 +7047,6 @@ CONFIG_DLM=m # CONFIG_DLM_DEPRECATED_API is not set # CONFIG_DLM_DEBUG is not set # CONFIG_UNICODE is not set -CONFIG_IO_WQ=y # end of File systems

#

This patch is missing the change for the RISC-V kernel configuration.

-Michael

-- 2.35.3