Re: [PATCH v3 0/9] module: Introduce hash-based integrity checking

Hi James, On 2025-04-29 10:05:04-0400, James Bottomley wrote: > On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote: > > The current signature-based module integrity checking has some > > drawbacks in combination with reproducible builds: > > Either the module signing key is generated at bui

Re: [PATCH bpf-next v3 10/11] bpf: Allow nospec-protected var-offset stack access

On Thu, 1 May 2025 at 10:17, Luis Gerhorst wrote: > > Insert a nospec before the access to prevent it from ever using an index > that is subject to speculative scalar-confusion. > > The access itself can either happen directly in the BPF program (reads > only, check_stack_read_var_off()) or in a h

Re: [PATCH bpf-next v3 08/11] bpf: Fall back to nospec for Spectre v1

On Thu, 1 May 2025 at 10:00, Luis Gerhorst wrote: > > This implements the core of the series and causes the verifier to fall > back to mitigating Spectre v1 using speculation barriers. The approach > was presented at LPC'24 [1] and RAID'24 [2]. > > If we find any forbidden behavior on a speculativ

Re: [PATCH] powerpc/pseries: Include linux/types.h in papr-platform-dump.h

On 4/30/25 3:37 AM, Stephen Rothwell wrote: > Hi Haren, > > Thanks for this. I have a small nitpick below. > > On Tue, 29 Apr 2025 14:14:18 -0700 Haren Myneni wrote: >> >> Fix the following build warning: >> usr/include/asm/papr-platform-dump.h:12: found __[us]{8,16,32,64} type >> without #

Re: [PATCH] Documentation: Fix description format for powerpc RTAS ioctls

On 4/30/25 2:38 PM, Bagas Sanjaya wrote: > On Tue, Apr 29, 2025 at 07:28:47PM -0700, Haren Myneni wrote: >> Fix the description format for the following build warnings: >> >> "Documentation/userspace-api/ioctl/ioctl-number.rst:369: >> ERROR: Malformed table. Text in column margin in table line 3

Re: [PATCH bpf-next v3 07/11] bpf: Rename sanitize_stack_spill to nospec_result

On Thu, 1 May 2025 at 10:02, Luis Gerhorst wrote: > > This is made to clarify that this flag will cause a nospec to be added > after this insn and can therefore be relied upon to reduce speculative > path analysis. > > Signed-off-by: Luis Gerhorst > Cc: Henriette Herzog > Cc: Maximilian Ott > C

Re: [PATCH bpf-next v3 05/11] bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()

On Thu, 1 May 2025 at 09:51, Luis Gerhorst wrote: > > JITs can set bpf_jit_bypass_spec_v1/v4() if they want the verifier to > skip analysis/patching for the respective vulnerability. For v4, this > will reduce the number of barriers the verifier inserts. For v1, it > allows more programs to be acc

Re: [PATCH bpf-next v3 04/11] bpf: Return -EFAULT on internal errors

On Thu, 1 May 2025 at 09:48, Luis Gerhorst wrote: > > This prevents us from trying to recover from these on speculative paths > in the future. > > Signed-off-by: Luis Gerhorst > Reviewed-by: Eduard Zingerman > Acked-by: Henriette Herzog > Cc: Maximilian Ott > Cc: Milan Stephan > --- Acked-by

Re: [PATCH bpf-next v3 03/11] bpf: Return -EFAULT on misconfigurations

On Thu, 1 May 2025 at 09:48, Luis Gerhorst wrote: > > Mark these cases as non-recoverable to later prevent them from being > caught when they occur during speculative path verification. > > Eduard writes [1]: > > The only pace I'm aware of that might act upon specific error code > from verifie

Re: [PATCH bpf-next v3 02/11] bpf: Move insn if/else into do_check_insn()

On Thu, 1 May 2025 at 09:43, Luis Gerhorst wrote: > > This is required to catch the errors later and fall back to a nospec if > on a speculative path. > > Eliminate the regs variable as it is only used once and insn_idx is not > modified in-between the definition and usage. > > Still pass insn sim

Re: [PATCH bpf-next v3 01/11] selftests/bpf: Fix caps for __xlated/jited_unpriv

On Thu, 1 May 2025 at 09:39, Luis Gerhorst wrote: > > Currently, __xlated_unpriv and __jited_unpriv do not work because the > BPF syscall will overwrite info.jited_prog_len and info.xlated_prog_len > with 0 if the process is not bpf_capable(). This bug was not noticed > before, because there is no

[PATCH v4 1/3] net: ibmveth: Indented struct ibmveth_adapter correctly

Made struct ibmveth_adapter follow indentation rules Signed-off-by: Dave Marquardt Reviewed-by: Michal Swiatkowski Reviewed-by: Simon Horman --- drivers/net/ethernet/ibm/ibmveth.h | 64 +++--- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/drivers/net/e

[PATCH v4 3/3] net: ibmveth: added KUnit tests for some buffer pool functions

Added KUnit tests for ibmveth_remove_buffer_from_pool and ibmveth_rxq_get_buffer under new IBMVETH_KUNIT_TEST config option. Signed-off-by: Dave Marquardt Reviewed-by: Simon Horman --- drivers/net/ethernet/ibm/Kconfig | 13 +++ drivers/net/ethernet/ibm/ibmveth.c | 129 +++

[PATCH v4 2/3] net: ibmveth: Reset the adapter when unexpected states are detected

Reset the adapter through new function ibmveth_reset, called in WARN_ON situations. Removed conflicting and unneeded forward declaration. Signed-off-by: Dave Marquardt --- drivers/net/ethernet/ibm/ibmveth.c | 118 - drivers/net/ethernet/ibm/ibmveth.h | 1 + 2 files

[PATCH v4 0/3] net: ibmveth: Make ibmveth use new reset function and new KUnit testsg

- Fixed struct ibmveth_adapter indentation - Made ibmveth driver use WARN_ON with recovery rather than BUG_ON. Some recovery code schedules a reset through new function ibmveth_reset. Also removed a conflicting and unneeded forward declaration. - Added KUnit tests for some areas changed by the

Re: [PATCH bpf-next v3 02/11] bpf: Move insn if/else into do_check_insn()

On Thu, 2025-05-01 at 09:35 +0200, Luis Gerhorst wrote: > This is required to catch the errors later and fall back to a nospec if > on a speculative path. > > Eliminate the regs variable as it is only used once and insn_idx is not > modified in-between the definition and usage. > > Still pass ins

Re: [PATCH bpf-next v3 01/11] selftests/bpf: Fix caps for __xlated/jited_unpriv

On Thu, 2025-05-01 at 09:35 +0200, Luis Gerhorst wrote: > Currently, __xlated_unpriv and __jited_unpriv do not work because the > BPF syscall will overwrite info.jited_prog_len and info.xlated_prog_len > with 0 if the process is not bpf_capable(). This bug was not noticed > before, because there is

[PATCH bpf-next v3 07/11] bpf: Rename sanitize_stack_spill to nospec_result

This is made to clarify that this flag will cause a nospec to be added after this insn and can therefore be relied upon to reduce speculative path analysis. Signed-off-by: Luis Gerhorst Cc: Henriette Herzog Cc: Maximilian Ott Cc: Milan Stephan --- include/linux/bpf_verifier.h | 2 +- kernel/b

[PATCH bpf-next v3 10/11] bpf: Allow nospec-protected var-offset stack access

Insert a nospec before the access to prevent it from ever using an index that is subject to speculative scalar-confusion. The access itself can either happen directly in the BPF program (reads only, check_stack_read_var_off()) or in a helper (read/write, check_helper_mem_access()). This relies on

[PATCH bpf-next v3 11/11] bpf: Fall back to nospec for sanitization-failures

ALU sanitization was introduced to ensure that a subsequent ptr access can never go OOB, even under speculation. This is required because we currently allow speculative scalar confusion. Spec. scalar confusion is possible because Spectre v4 sanitization only adds a nospec after critical stores (e.g

[PATCH bpf-next v3 09/11] selftests/bpf: Add test for Spectre v1 mitigation

This is based on the gadget from the description of commit 9183671af6db ("bpf: Fix leakage under speculation on mispredicted branches"). Signed-off-by: Luis Gerhorst --- .../selftests/bpf/progs/verifier_unpriv.c | 57 +++ 1 file changed, 57 insertions(+) diff --git a/tools/t

[PATCH bpf-next v3 08/11] bpf: Fall back to nospec for Spectre v1

This implements the core of the series and causes the verifier to fall back to mitigating Spectre v1 using speculation barriers. The approach was presented at LPC'24 [1] and RAID'24 [2]. If we find any forbidden behavior on a speculative path, we insert a nospec (e.g., lfence speculation barrier o

[PATCH bpf-next v3 06/11] bpf, arm64, powerpc: Change nospec to include v1 barrier

This changes the semantics of BPF_NOSPEC (previously a v4-only barrier) to always emit a speculation barrier that works against both Spectre v1 AND v4. If mitigation is not needed on an architecture, the backend should set bpf_jit_bypass_spec_v4/v1(). As of now, this commit only has the user-visib

[PATCH bpf-next v3 05/11] bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()

JITs can set bpf_jit_bypass_spec_v1/v4() if they want the verifier to skip analysis/patching for the respective vulnerability. For v4, this will reduce the number of barriers the verifier inserts. For v1, it allows more programs to be accepted. The primary motivation for this is to not regress unp

[PATCH bpf-next v3 04/11] bpf: Return -EFAULT on internal errors

This prevents us from trying to recover from these on speculative paths in the future. Signed-off-by: Luis Gerhorst Reviewed-by: Eduard Zingerman Acked-by: Henriette Herzog Cc: Maximilian Ott Cc: Milan Stephan --- kernel/bpf/verifier.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions

[PATCH bpf-next v3 03/11] bpf: Return -EFAULT on misconfigurations

Mark these cases as non-recoverable to later prevent them from being caught when they occur during speculative path verification. Eduard writes [1]: The only pace I'm aware of that might act upon specific error code from verifier syscall is libbpf. Looking through libbpf code, it seems that

[PATCH bpf-next v3 02/11] bpf: Move insn if/else into do_check_insn()

This is required to catch the errors later and fall back to a nospec if on a speculative path. Eliminate the regs variable as it is only used once and insn_idx is not modified in-between the definition and usage. Still pass insn simply to match the other check_*() functions. As Eduard points out

[PATCH bpf-next v3 01/11] selftests/bpf: Fix caps for __xlated/jited_unpriv

Currently, __xlated_unpriv and __jited_unpriv do not work because the BPF syscall will overwrite info.jited_prog_len and info.xlated_prog_len with 0 if the process is not bpf_capable(). This bug was not noticed before, because there is no test that actually uses __xlated_unpriv/__jited_unpriv. To

[PATCH bpf-next v3 00/11] bpf: Mitigate Spectre v1 using barriers

This improves the expressiveness of unprivileged BPF by inserting speculation barriers instead of rejecting the programs. The approach was previously presented at LPC'24 [1] and RAID'24 [2]. To mitigate the Spectre v1 (PHT) vulnerability, the kernel rejects potentially-dangerous unprivileged BPF