From: Borislav Petkov <bp@alien8.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org>
Subject: [GIT PULL] x86/urgent for v6.5-rc7
Date: Sat, 19 Aug 2023 10:27:09 +0200 [thread overview]
Message-ID: <20230819082709.GAZOB83cQ687HkbMgt@fat_crate.local> (raw)
Hi Linus,
extraordinary embargoed times call for extraordinary measures. That's
why this week's x86/urgent branch is larger than usual, containing all
the known fallout fixes after the SRSO mitigation got merged.
I know, it is a bit late in the game but everyone who has reported a bug
stemming from the SRSO pile, has tested that branch and has confirmed
that it fixes their bug.
Also, I've run it on every possible hardware I have and it is looking
good. It is running on this very machine while I'm typing, for 2 days
now without an issue. Famous last words...
So please pull,
thx!
---
The following changes since commit 2ccdd1b13c591d306f0401d98dedc4bdcd02b421:
Linux 6.5-rc6 (2023-08-13 11:29:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_urgent_for_v6.5_rc7
for you to fetch changes up to 6405b72e8d17bd1875a56ae52d23ec3cd51b9d66:
x86/srso: Correct the mitigation status when SMT is disabled (2023-08-18 12:43:10 +0200)
----------------------------------------------------------------
- Use LEA ...%rsp instead of ADD %rsp in the Zen1/2 SRSO return sequence
as latter clobbers flags which interferes with fastop emulation in
KVM, leading to guests freezing during boot
- A fix for the DIV(0) quotient data leak on Zen1 to clear the divider
buffers at the right time
- Disable the SRSO mitigation on unaffected configurations as it got
enabled there unnecessarily
- Change .text section name to fix CONFIG_LTO_CLANG builds
- Improve the optprobe indirect jmp check so that certain configurations
can still be able to use optprobes at all
- A serious and good scrubbing of the untraining routines by PeterZ:
- Add proper speculation stopping traps so that objtool is happy
- Adjust objtool to handle the new thunks
- Make the thunk pointer assignable to the different untraining
sequences at runtime, thus avoiding the alternative at the return
thunk. It simplifies the code a bit too.
- Add a entry_untrain_ret() main entry point which selects the
respective untraining sequence
- Rename things so that they're more clear
- Fix stack validation with FRAME_POINTER=y builds
- Fix static call patching to handle when a JMP to the return thunk is
the last insn on the very last module memory page
- Add more documentation about what each untraining routine does and
why
----------------------------------------------------------------
Borislav Petkov (AMD) (4):
x86/CPU/AMD: Fix the DIV(0) initial fix attempt
x86/srso: Disable the mitigation on unaffected configurations
x86/srso: Explain the untraining sequences a bit more
x86/srso: Correct the mitigation status when SMT is disabled
Peter Zijlstra (11):
x86/cpu: Fix __x86_return_thunk symbol type
x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk()
objtool/x86: Fix SRSO mess
x86/alternative: Make custom return thunk unconditional
x86/cpu: Clean up SRSO return thunk mess
x86/cpu: Rename original retbleed methods
x86/cpu: Rename srso_(.*)_alias to srso_alias_\1
x86/cpu: Cleanup the untrain mess
x86/cpu/kvm: Provide UNTRAIN_RET_VM
objtool/x86: Fixup frame-pointer vs rethunk
x86/static_call: Fix __static_call_fixup()
Petr Pavlu (2):
x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG
x86/retpoline,kprobes: Skip optprobe check for indirect jumps with retpolines and IBT
Sean Christopherson (1):
x86/retpoline: Don't clobber RFLAGS during srso_safe_ret()
Documentation/admin-guide/hw-vuln/srso.rst | 4 +-
arch/x86/include/asm/entry-common.h | 1 +
arch/x86/include/asm/nospec-branch.h | 49 ++++++-----
arch/x86/kernel/alternative.c | 4 -
arch/x86/kernel/cpu/amd.c | 1 +
arch/x86/kernel/cpu/bugs.c | 27 +++++-
arch/x86/kernel/kprobes/opt.c | 40 ++++-----
arch/x86/kernel/static_call.c | 13 +++
arch/x86/kernel/traps.c | 2 -
arch/x86/kernel/vmlinux.lds.S | 20 ++---
arch/x86/kvm/svm/svm.c | 2 +
arch/x86/kvm/svm/vmenter.S | 7 +-
arch/x86/lib/retpoline.S | 137 ++++++++++++++++++++---------
tools/objtool/arch/x86/decode.c | 11 ++-
tools/objtool/check.c | 45 +++++++---
tools/objtool/include/objtool/arch.h | 1 +
tools/objtool/include/objtool/elf.h | 1 +
tools/perf/util/thread-stack.c | 4 +-
18 files changed, 236 insertions(+), 133 deletions(-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next reply other threads:[~2023-08-19 8:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-19 8:27 Borislav Petkov [this message]
2023-08-19 11:05 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230819082709.GAZOB83cQ687HkbMgt@fat_crate.local \
--to=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®