Additional VMD bridge IDs needed for new Alder Lake platforms, but
actually there is no a complete list for them. Here we match bridge
devices if they're directly attached to a VMD controller instead.
Signed-off-by: You-Sheng Yang <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
Update configs after applying AMX patchset. Enforce
STRICT_SIGALTSTACK_SIZE as off, because:
CONFIG_STRICT_SIGALTSTACK_SIZE is intend for enforcing strict checking
of the sigaltstack size against the *real size of the FPU frame*,
enabling it is risky since it may lead to the broken of legacy
applications which already allocate a too small sigaltstack but can
still work because they never get a signal delivered. (lin-x-wang)
Fixes: cf1383fe60 ("x86/signal: Implement sigaltstack size validation")
Signed-off-by: Dimitri John Ledkov <email address hidden>
Signed-off-by: Andrea Righi <email address hidden>
nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION
It appears that there are some buffer overflows in EVT_TRANSACTION.
This happens because the length parameters that are passed to memcpy
come directly from skb->data and are not guarded in any way.
Signed-off-by: Jordy Zomer <email address hidden>
Reviewed-by: Krzysztof Kozlowski <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 4fbcc1a4cb20fe26ad0225679c536c80f1648221)
CVE-2022-26490
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Bartlomiej Zolnierkiewicz <email address hidden>
Signed-off-by: Andrea Righi <email address hidden>
83f5b84...
by
Peter Zijlstra <email address hidden>
Current BPF codegen doesn't respect X86_FEATURE_RETPOLINE* flags and
unconditionally emits a thunk call, this is sub-optimal and doesn't
match the regular, compiler generated, code.
Update the i386 JIT to emit code equal to what the compiler emits for
the regular kernel text (IOW. a plain THUNK call).
Update the x86_64 JIT to emit code similar to the result of compiler
and kernel rewrites as according to X86_FEATURE_RETPOLINE* flags.
Inlining RETPOLINE_AMD (lfence; jmp *%reg) and !RETPOLINE (jmp *%reg),
while doing a THUNK call for RETPOLINE.
This removes the hard-coded retpoline thunks and shrinks the generated
code. Leaving a single retpoline thunk definition in the kernel.
Signed-off-by: Peter Zijlstra (Intel) <email address hidden>
Reviewed-by: Borislav Petkov <email address hidden>
Acked-by: Alexei Starovoitov <email address hidden>
Acked-by: Josh Poimboeuf <email address hidden>
Tested-by: Alexei Starovoitov <email address hidden>
Link: https://<email address hidden>
(backported from commit 87c87ecd00c54ecd677798cb49ef27329e0fab41)
[cascardo: RETPOLINE_AMD was renamed to RETPOLINE_LFENCE]
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Andrea Righi <email address hidden>
470167a...
by
Peter Zijlstra <email address hidden>
Take an idea from the 32bit JIT, which uses the multi-pass nature of
the JIT to compute the instruction offsets on a prior pass in order to
compute the relative jump offsets on a later pass.
Application to the x86_64 JIT is slightly more involved because the
offsets depend on program variables (such as callee_regs_used and
stack_depth) and hence the computed offsets need to be kept in the
context of the JIT.
This removes, IMO quite fragile, code that hard-codes the offsets and
tries to compute the length of variable parts of it.
Convert both emit_bpf_tail_call_*() functions which have an out: label
at the end. Additionally emit_bpt_tail_call_direct() also has a poke
table entry, for which it computes the offset from the end (and thus
already relies on the previous pass to have computed addrs[i]), also
convert this to be a forward based offset.
Specifically, the sequence above is 5 bytes for the low 8 registers,
but 6 bytes for the high 8 registers. This means that unless the
compilers prefix stuff the call with higher registers this replacement
will fail.
Luckily GCC strongly favours RAX for the indirect calls and most (95%+
for defconfig-x86_64) will be converted. OTOH clang strongly favours
R11 and almost nothing gets converted.
Note: it will also generate a correct replacement for the Jcc.d32
case, except unless the compilers start to prefix stuff that, it'll
never fit. Specifically:
Jncc.d8 1f
LFENCE
JMP *%\reg
1:
is 7-8 bytes long, where the original instruction in unpadded form is
only 6 bytes.
Signed-off-by: Peter Zijlstra (Intel) <email address hidden>
Reviewed-by: Borislav Petkov <email address hidden>
Acked-by: Josh Poimboeuf <email address hidden>
Tested-by: Alexei Starovoitov <email address hidden>
Link: https://<email address hidden>
(backported from commit bbe2df3f6b6da7848398d55b1311d58a16ec21e4)
[cascardo: RETPOLINE_AMD was renamed to RETPOLINE_LFENCE]
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Andrea Righi <email address hidden>
4d11116...
by
Peter Zijlstra <email address hidden>
