Thomas Gleixner [Thu, 21 Oct 2021 22:55:05 +0000 (15:55 -0700)]
signal: Add an optional check for altstack size
BugLink: https://bugs.launchpad.net/bugs/1967750
New x86 FPU features will be very large, requiring ~10k of stack in
signal handlers. These new features require a new approach called
"dynamic features".
The kernel currently tries to ensure that altstacks are reasonably
sized. Right now, on x86, sys_sigaltstack() requires a size of >=2k.
However, that 2k is a constant. Simply raising that 2k requirement
to >10k for the new features would break existing apps which have a
compiled-in size of 2k.
Instead of universally enforcing a larger stack, prohibit a process from
using dynamic features without properly-sized altstacks. This must be
enforced in two places:
* A dynamic feature can not be enabled without an large-enough altstack
for each process thread.
* Once a dynamic feature is enabled, any request to install a too-small
altstack will be rejected
The dynamic feature enabling code must examine each thread in a
process to ensure that the altstacks are large enough. Add a new lock
(sigaltstack_lock()) to ensure that threads can not race and change
their altstack after being examined.
Add the infrastructure in form of a config option and provide empty
stubs for architectures which do not need dynamic altstack size checks.
This implementation will be fleshed out for x86 in a future patch called
x86/arch_prctl: Add controls for dynamic XSTATE components
Thomas Gleixner [Fri, 22 Oct 2021 18:55:53 +0000 (20:55 +0200)]
x86/kvm: Convert FPU handling to a single swap buffer
BugLink: https://bugs.launchpad.net/bugs/1967750
For the upcoming AMX support it's necessary to do a proper integration with
KVM. Currently KVM allocates two FPU structs which are used for saving the user
state of the vCPU thread and restoring the guest state when entering
vcpu_run() and doing the reverse operation before leaving vcpu_run().
With the new fpstate mechanism this can be reduced to one extra buffer by
swapping the fpstate pointer in current::thread::fpu. This makes the
upcoming support for AMX and XFD simpler because then fpstate information
(features, sizes, xfd) are always consistent and it does not require any
nasty workarounds.
Thomas Gleixner [Fri, 22 Oct 2021 18:55:51 +0000 (20:55 +0200)]
x86/fpu: Provide infrastructure for KVM FPU cleanup
BugLink: https://bugs.launchpad.net/bugs/1967750
For the upcoming AMX support it's necessary to do a proper integration with
KVM. Currently KVM allocates two FPU structs which are used for saving the user
state of the vCPU thread and restoring the guest state when entering
vcpu_run() and doing the reverse operation before leaving vcpu_run().
With the new fpstate mechanism this can be reduced to one extra buffer by
swapping the fpstate pointer in current::thread::fpu. This makes the
upcoming support for AMX and XFD simpler because then fpstate information
(features, sizes, xfd) are always consistent and it does not require any
nasty workarounds.
Provide:
- An allocator which initializes the state properly
- A replacement for the existing FPU swap mechanim
Aside of the reduced memory footprint, this also makes state switching
more efficient when TIF_FPU_NEED_LOAD is set. It does not require a
memcpy as the state is already correct in the to be swapped out fpstate.
The existing interfaces will be removed once KVM is converted over.
Thomas Gleixner [Fri, 22 Oct 2021 18:55:49 +0000 (20:55 +0200)]
x86/fpu: Prepare for sanitizing KVM FPU code
BugLink: https://bugs.launchpad.net/bugs/1967750
For the upcoming AMX support it's necessary to do a proper integration with
KVM. To avoid more nasty hackery in KVM which violate encapsulation extend
struct fpu and fpstate so the fpstate switching can be consolidated and
simplified.
Currently KVM allocates two FPU structs which are used for saving the user
state of the vCPU thread and restoring the guest state when entering
vcpu_run() and doing the reverse operation before leaving vcpu_run().
With the new fpstate mechanism this can be reduced to one extra buffer by
swapping the fpstate pointer in current::thread::fpu. This makes the
upcoming support for AMX and XFD simpler because then fpstate information
(features, sizes, xfd) are always consistent and it does not require any
nasty workarounds.
Add fpu::__task_fpstate to save the regular fpstate pointer while the task
is inside vcpu_run(). Add some state fields to fpstate to indicate the
nature of the state.
Thomas Gleixner [Thu, 14 Oct 2021 23:09:40 +0000 (01:09 +0200)]
x86/fpu/xstate: Move remaining xfeature helpers to core
BugLink: https://bugs.launchpad.net/bugs/1967750
Now that everything is mopped up, move all the helpers and prototypes into
the core header. They are not required by the outside.
Rework restore_regs_from_fpstate() so it takes a constant mask which will
then be applied against the maximum feature set so that the restore
operation brings all features which are not in the xsave buffer xfeature
bitmap into init state.
This ensures that if the previous task used a dynamically enabled feature
that the task which restores has all unused components properly initialized.
Cleanup the last user of xfeatures_mask_fpstate() as well and remove it.
Thomas Gleixner [Thu, 14 Oct 2021 23:09:37 +0000 (01:09 +0200)]
x86/fpu: Mop up xfeatures_mask_uabi()
BugLink: https://bugs.launchpad.net/bugs/1967750
Use the new fpu_user_cfg to retrieve the information instead of
xfeatures_mask_uabi() which will be no longer correct when dynamically
enabled features become available.
Using fpu_user_cfg is appropriate when setting XCOMP_BV in the
init_fpstate since it has space allocated for "max_features". But,
normal fpstates might only have space for default xfeatures. Since
XRSTOR* derives the format of the XSAVE buffer from XCOMP_BV, this can
lead to XRSTOR reading out of bounds.
So when copying actively used fpstate, simply read the XCOMP_BV features
bits directly out of the fpstate instead.
This correction courtesy of Dave Hansen <dave.hansen@linux.intel.com>
Thomas Gleixner [Thu, 14 Oct 2021 23:09:35 +0000 (01:09 +0200)]
x86/fpu: Move xstate feature masks to fpu_*_cfg
BugLink: https://bugs.launchpad.net/bugs/1967750
Move the feature mask storage to the kernel and user config
structs. Default and maximum feature set are the same for now.
Thomas Gleixner [Thu, 14 Oct 2021 23:09:34 +0000 (01:09 +0200)]
x86/fpu: Move xstate size to fpu_*_cfg
BugLink: https://bugs.launchpad.net/bugs/1967750
Use the new kernel and user space config storage to store and retrieve the
XSTATE buffer sizes. The default and the maximum size are the same for now,
but will change when support for dynamically enabled features is added.
Thomas Gleixner [Thu, 14 Oct 2021 23:09:29 +0000 (01:09 +0200)]
x86/fpu: Provide struct fpu_config
BugLink: https://bugs.launchpad.net/bugs/1967750
Provide a struct to store information about the maximum supported and the
default feature set and buffer sizes for both user and kernel space.
This allows quick retrieval of this information for the upcoming support
for dynamically enabled features.
[ bp: Add vertical spacing between the struct members. ]
Thomas Gleixner [Thu, 14 Oct 2021 22:51:51 +0000 (00:51 +0200)]
x86/fpu/signal: Use fpstate for size and features
BugLink: https://bugs.launchpad.net/bugs/1967750
For dynamically enabled features it's required to get the features which
are enabled for that context when restoring from sigframe.
The same applies for all signal frame size calculations.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:55 +0000 (16:55 +0200)]
x86/fpu/xstate: Use fpstate for copy_uabi_to_xstate()
BugLink: https://bugs.launchpad.net/bugs/1967750
Prepare for dynamically enabled states per task. The function needs to
retrieve the features and sizes which are valid in a fpstate
context. Retrieve them from fpstate.
Move the function declarations to the core header as they are not
required anywhere else.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:54 +0000 (16:55 +0200)]
x86/fpu: Use fpstate in __copy_xstate_to_uabi_buf()
BugLink: https://bugs.launchpad.net/bugs/1967750
With dynamically enabled features the copy function must know the features
and the size which is valid for the task. Retrieve them from fpstate.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:51 +0000 (16:55 +0200)]
x86/fpu/xstate: Use fpstate for xsave_to_user_sigframe()
BugLink: https://bugs.launchpad.net/bugs/1967750
With dynamically enabled features the sigframe code must know the features
which are enabled for the task. Get them from fpstate.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:49 +0000 (16:55 +0200)]
x86/fpu/xstate: Use fpstate for os_xsave()
BugLink: https://bugs.launchpad.net/bugs/1967750
With variable feature sets XSAVE[S] requires to know the feature set for
which the buffer is valid. Retrieve it from fpstate.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:48 +0000 (16:55 +0200)]
x86/fpu: Use fpstate::size
BugLink: https://bugs.launchpad.net/bugs/1967750
Make use of fpstate::size in various places which require the buffer size
information for sanity checks or memcpy() sizing.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:46 +0000 (16:55 +0200)]
x86/fpu: Add size and mask information to fpstate
BugLink: https://bugs.launchpad.net/bugs/1967750
Add state size and feature mask information to the fpstate container. This
will be used for runtime checks with the upcoming support for dynamically
enabled features and dynamically sized buffers. That avoids conditionals
all over the place as the required information is accessible for both
default and extended buffers.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:45 +0000 (16:55 +0200)]
x86/process: Move arch_thread_struct_whitelist() out of line
BugLink: https://bugs.launchpad.net/bugs/1967750
In preparation for dynamically enabled FPU features move the function
out of line as the goal is to expose less and not more information.
Not a problem right now, but later when dynamically allocated buffers
are available, keeping the pointer might result in freeing the
parent's buffer. Set it to NULL which prevents that. If fork reaches
clone_thread(), the pointer will be correctly set to the new task
context.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:40 +0000 (16:55 +0200)]
x86/math-emu: Convert to fpstate
BugLink: https://bugs.launchpad.net/bugs/1967750
Convert math emulation code to the new register storage
mechanism in preparation for dynamically sized buffers.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:39 +0000 (16:55 +0200)]
x86/fpu/core: Convert to fpstate
BugLink: https://bugs.launchpad.net/bugs/1967750
Convert the rest of the core code to the new register storage mechanism in
preparation for dynamically sized buffers.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:37 +0000 (16:55 +0200)]
x86/fpu/signal: Convert to fpstate
BugLink: https://bugs.launchpad.net/bugs/1967750
Convert signal related code to the new register storage mechanism in
preparation for dynamically sized buffers.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:36 +0000 (16:55 +0200)]
x86/fpu/regset: Convert to fpstate
BugLink: https://bugs.launchpad.net/bugs/1967750
Convert regset related code to the new register storage mechanism in
preparation for dynamically sized buffers.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:34 +0000 (16:55 +0200)]
x86/fpu: Convert tracing to fpstate
BugLink: https://bugs.launchpad.net/bugs/1967750
Convert FPU tracing code to the new register storage mechanism in
preparation for dynamically sized buffers.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:31 +0000 (16:55 +0200)]
x86/fpu: Replace KVMs xstate component clearing
BugLink: https://bugs.launchpad.net/bugs/1967750
In order to prepare for the support of dynamically enabled FPU features,
move the clearing of xstate components to the FPU core code.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:30 +0000 (16:55 +0200)]
x86/fpu: Convert restore_fpregs_from_fpstate() to struct fpstate
BugLink: https://bugs.launchpad.net/bugs/1967750
Convert restore_fpregs_from_fpstate() and related code to the new
register storage mechanism in preparation for dynamically sized buffers.
Thomas Gleixner [Wed, 13 Oct 2021 14:55:28 +0000 (16:55 +0200)]
x86/fpu: Convert fpstate_init() to struct fpstate
BugLink: https://bugs.launchpad.net/bugs/1967750
Convert fpstate_init() and related code to the new register storage
mechanism in preparation for dynamically sized buffers.
The kernel will provide the default sized buffer for storing the regular
features up to AVX512 in thread_struct::fpu and if a task requests to use
one of the new features then the register storage has to be extended.
The state will be accessed via a pointer in thread_struct::fpu which
defaults to the builtin storage and can be switched when extended storage
is required.
To avoid conditionals all over the code, create a new container for the
register storage which will gain other information, e.g. size, feature
masks etc., later. For now it just contains the register storage, which
gives it exactly the same layout as the exiting fpu::state.
Stick fpu::state and the new fpu::__fpstate into an anonymous union and
initialize the pointer. Add build time checks to validate that both are
at the same place and have the same size.
Thomas Gleixner [Fri, 15 Oct 2021 01:16:17 +0000 (03:16 +0200)]
x86/fpu: Replace KVMs home brewed FPU copy to user
BugLink: https://bugs.launchpad.net/bugs/1967750
Similar to the copy from user function the FPU core has this already
implemented with all bells and whistles.
Get rid of the duplicated code and use the core functionality.
Thomas Gleixner [Fri, 15 Oct 2021 01:16:41 +0000 (03:16 +0200)]
x86/fpu: Provide a proper function for ex_handler_fprestore()
BugLink: https://bugs.launchpad.net/bugs/1967750
To make upcoming changes for support of dynamically enabled features
simpler, provide a proper function for the exception handler which removes
exposure of FPU internals.
Thomas Gleixner [Fri, 15 Oct 2021 01:16:39 +0000 (03:16 +0200)]
x86/fpu: Replace the includes of fpu/internal.h
BugLink: https://bugs.launchpad.net/bugs/1967750
Now that the file is empty, fixup all references with the proper includes
and delete the former kitchen sink.
Include asm/fpu/xstate.h to fix a missing update_regset_xstate_info()
prototype, which is Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20211015011539.844565975@linutronix.de
(cherry picked from commit 0ae67cc34f765078a63137120e4567ad2f050b75) Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Thomas Gleixner [Fri, 15 Oct 2021 01:16:15 +0000 (03:16 +0200)]
x86/fpu: Rework copy_xstate_to_uabi_buf()
BugLink: https://bugs.launchpad.net/bugs/1967750
Prepare for replacing the KVM copy xstate to user function by extending
copy_xstate_to_uabi_buf() with a pkru argument which allows the caller to
hand in the pkru value, which is required for KVM because the guest PKRU is
not accessible via current. Fixup all callsites accordingly.
Thomas Gleixner [Fri, 15 Oct 2021 01:16:13 +0000 (03:16 +0200)]
x86/fpu: Replace KVMs home brewed FPU copy from user
BugLink: https://bugs.launchpad.net/bugs/1967750
Copying a user space buffer to the memory buffer is already available in
the FPU core. The copy mechanism in KVM lacks sanity checks and needs to
use cpuid() to lookup the offset of each component, while the FPU core has
this information cached.
Make the FPU core variant accessible for KVM and replace the home brewed
mechanism.
Thomas Gleixner [Fri, 15 Oct 2021 01:16:12 +0000 (03:16 +0200)]
x86/fpu: Move KVMs FPU swapping to FPU core
BugLink: https://bugs.launchpad.net/bugs/1967750
Swapping the host/guest FPU is directly fiddling with FPU internals which
requires 5 exports. The upcoming support of dynamically enabled states
would even need more.
Implement a swap function in the FPU core code and export that instead.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org Link: https://lkml.kernel.org/r/20211015011539.076072399@linutronix.de
(cherry picked from commit a0ff0611c2fbde94f6c9db8351939b08f2cb6797) Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Thomas Gleixner [Fri, 15 Oct 2021 01:16:09 +0000 (03:16 +0200)]
x86/fpu/xstate: Provide and use for_each_xfeature()
BugLink: https://bugs.launchpad.net/bugs/1967750
These loops evaluating xfeature bits are really hard to read. Create an
iterator and use for_each_set_bit_from() inside which already does the right
thing.
Thomas Gleixner [Fri, 15 Oct 2021 01:16:06 +0000 (03:16 +0200)]
x86/fpu: Do not inherit FPU context for kernel and IO worker threads
BugLink: https://bugs.launchpad.net/bugs/1967750
There is no reason why kernel and IO worker threads need a full clone of
the parent's FPU state. Both are kernel threads which are not supposed to
use FPU. So copying a large state or doing XSAVE() is pointless. Just clean
out the minimally required state for those tasks.
Thomas Gleixner [Fri, 15 Oct 2021 01:16:04 +0000 (03:16 +0200)]
x86/process: Clone FPU in copy_thread()
BugLink: https://bugs.launchpad.net/bugs/1967750
There is no reason to clone FPU in arch_dup_task_struct(). Quite the
contrary - it prevents optimizations. Move it to copy_thread().
Thomas Gleixner [Fri, 15 Oct 2021 01:16:02 +0000 (03:16 +0200)]
x86/fpu: Remove pointless memset in fpu_clone()
BugLink: https://bugs.launchpad.net/bugs/1967750
Zeroing the forked task's FPU registers buffer to avoid leaking init
optimized stale data into the clone is a pointless exercise for the case
where the current task has TIF_NEED_FPU_LOAD set. In that case, the FPU
registers state is copied from current's FPU register buffer which can
contain stale init optimized data as well.
The alledged information leak is non-existant because this stale init
optimized data is used nowhere and cannot leak anywhere.
Thomas Gleixner [Fri, 15 Oct 2021 01:15:59 +0000 (03:15 +0200)]
x86/fpu: Restrict xsaves()/xrstors() to independent states
BugLink: https://bugs.launchpad.net/bugs/1967750
These interfaces are really only valid for features which are independently
managed and not part of the task context state for various reasons.
Tighten the checks and adjust the misleading comments.
Thomas Gleixner [Fri, 15 Oct 2021 01:15:57 +0000 (03:15 +0200)]
x86/pkru: Remove useless include
BugLink: https://bugs.launchpad.net/bugs/1967750
PKRU code does not need anything from FPU headers. Include cpufeature.h
instead and fixup the resulting fallout in perf.
This is a preparation for FPU changes in order to prevent recursive include
hell.
Thomas Gleixner [Fri, 15 Oct 2021 01:15:56 +0000 (03:15 +0200)]
x86/fpu: Update stale comments
BugLink: https://bugs.launchpad.net/bugs/1967750
copy_fpstate_to_sigframe() does not have a slow path anymore. Neither does
the !ia32 restore in __fpu_restore_sig().
Thomas Gleixner [Wed, 8 Sep 2021 13:29:38 +0000 (15:29 +0200)]
x86/fpu/signal: Change return type of __fpu_restore_sig() to boolean
BugLink: https://bugs.launchpad.net/bugs/1967750
Now that fpu__restore_sig() returns a boolean get rid of the individual
error codes in __fpu_restore_sig() as well.
Thomas Gleixner [Wed, 8 Sep 2021 13:29:37 +0000 (15:29 +0200)]
x86/fpu/signal: Change return type of fpu__restore_sig() to boolean
BugLink: https://bugs.launchpad.net/bugs/1967750
None of the call sites cares about the error code. All they need to know is
whether the function succeeded or not.
Thomas Gleixner [Wed, 8 Sep 2021 13:29:34 +0000 (15:29 +0200)]
x86/fpu/signal: Change return type of copy_fpregs_to_sigframe() helpers to boolean
BugLink: https://bugs.launchpad.net/bugs/1967750
Now that copy_fpregs_to_sigframe() returns boolean the individual return
codes in the related helper functions do not make sense anymore. Change
them to return boolean success/fail.
Thomas Gleixner [Wed, 8 Sep 2021 13:29:32 +0000 (15:29 +0200)]
x86/fpu/signal: Change return type of copy_fpstate_to_sigframe() to boolean
BugLink: https://bugs.launchpad.net/bugs/1967750
None of the call sites cares about the actual return code. Change the
return type to boolean and return 'true' on success.
Thomas Gleixner [Wed, 8 Sep 2021 13:29:30 +0000 (15:29 +0200)]
x86/fpu/signal: Move xstate clearing out of copy_fpregs_to_sigframe()
BugLink: https://bugs.launchpad.net/bugs/1967750
When the direct saving of the FPU registers to the user space sigframe
fails, copy_fpregs_to_sigframe() attempts to clear the user buffer.
The most likely reason for such a fail is a page fault. As
copy_fpregs_to_sigframe() is invoked with pagefaults disabled the chance
that __clear_user() succeeds is minuscule.
Move the clearing out into the caller which replaces the
fault_in_pages_writeable() in that error handling path.
The return value confusion will be cleaned up separately.
Thomas Gleixner [Wed, 8 Sep 2021 13:29:26 +0000 (15:29 +0200)]
x86/fpu/signal: Clarify exception handling in restore_fpregs_from_user()
BugLink: https://bugs.launchpad.net/bugs/1967750
FPU restore from a signal frame can trigger various exceptions. The
exceptions are caught with an exception table entry. The handler of this
entry stores the trap number in EAX. The FPU specific fixup negates that
trap number to convert it into an negative error code.
Any other exception than #PF is fatal and recovery is not possible. This
relies on the fact that the #PF exception number is the same as EFAULT, but
that's not really obvious.
Remove the negation from the exception fixup as it really has no value and
check for X86_TRAP_PF at the call site.
There is still confusion due to the return code conversion for the error
case which will be cleaned up separately.
Thomas Gleixner [Wed, 8 Sep 2021 13:29:24 +0000 (15:29 +0200)]
x86/extable: Remove EX_TYPE_FAULT from MCE safe fixups
BugLink: https://bugs.launchpad.net/bugs/1967750
Now that the MC safe copy and FPU have been converted to use the MCE safe
fixup types remove EX_TYPE_FAULT from the list of types which MCE considers
to be safe to be recovered in kernel.
This removes the SGX exception handling of ENCLS from the #MC safe
handling, but according to the SGX wizards the current SGX implementations
cannot survive #MC on ENCLS:
The code relies on the trap number being stored if ENCLS raised an
exception. That's still working, but it does no longer trick the MCE code
into assuming that #MC is handled correctly for ENCLS.
Thomas Gleixner [Wed, 8 Sep 2021 13:29:23 +0000 (15:29 +0200)]
x86/fpu: Use EX_TYPE_FAULT_MCE_SAFE for exception fixups
BugLink: https://bugs.launchpad.net/bugs/1967750
The macros used for restoring FPU state from a user space buffer can handle
all exceptions including #MC. They need to return the trap number in the
error case as the code which invokes them needs to distinguish the cause of
the failure. It aborts the operation for anything except #PF.
Use the new EX_TYPE_FAULT_MCE_SAFE exception table fixup type to document
the nature of the fixup.
Thomas Gleixner [Wed, 8 Sep 2021 13:29:21 +0000 (15:29 +0200)]
x86/copy_mc: Use EX_TYPE_DEFAULT_MCE_SAFE for exception fixups
BugLink: https://bugs.launchpad.net/bugs/1967750
Nothing in that code uses the trap number which was stored by the exception
fixup which is instantiated via _ASM_EXTABLE_FAULT().
Use _ASM_EXTABLE(... EX_TYPE_DEFAULT_MCE_SAFE) instead which just handles
the IP fixup and the type indicates to the #MC handler that the call site
can handle the abort caused by #MC correctly.
Thomas Gleixner [Wed, 8 Sep 2021 13:29:19 +0000 (15:29 +0200)]
x86/extable: Provide EX_TYPE_DEFAULT_MCE_SAFE and EX_TYPE_FAULT_MCE_SAFE
BugLink: https://bugs.launchpad.net/bugs/1967750
Provide exception fixup types which can be used to identify fixups which
allow in kernel #MC recovery and make them invoke the existing handlers.
These will be used at places where #MC recovery is handled correctly by the
caller.
Thomas Gleixner [Wed, 8 Sep 2021 13:29:18 +0000 (15:29 +0200)]
x86/extable: Rework the exception table mechanics
BugLink: https://bugs.launchpad.net/bugs/1967750
The exception table entries contain the instruction address, the fixup
address and the handler address. All addresses are relative. Storing the
handler address has a few downsides:
1) Most handlers need to be exported
2) Handlers can be defined everywhere and there is no overview about the
handler types
3) MCE needs to check the handler type to decide whether an in kernel #MC
can be recovered. The functionality of the handler itself is not in any
way special, but for these checks there need to be separate functions
which in the worst case have to be exported.
Some of these 'recoverable' exception fixups are pretty obscure and
just reuse some other handler to spare code. That obfuscates e.g. the
#MC safe copy functions. Cleaning that up would require more handlers
and exports
Rework the exception fixup mechanics by storing a fixup type number instead
of the handler address and invoke the proper handler for each fixup
type. Also teach the extable sort to leave the type field alone.
This makes most handlers static except for special cases like the MCE
MSR fixup and the BPF fixup. This allows to add more types for cleaning up
the obscure places without adding more handler code and exports.
There is a marginal code size reduction for a production config and it
removes _eight_ exported symbols.
netfilter: nf_tables: initialize registers in nft_do_chain()
Initialize registers to avoid stack leak into userspace.
Fixes: 96518518cc41 ("netfilter: add nftables") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit 4c905f6740a365464e91467aa50916555b28213d)
CVE-2022-1016 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
netfilter: nf_tables: validate registers coming from userspace.
Bail out in case userspace uses unsupported registers.
Fixes: 49499c3e6e18 ("netfilter: nf_tables: switch registers to 32 bit addressing") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit 6e1acfa387b9ff82cfc7db8cc3b6959221a95851)
CVE-2022-1015 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
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 <jordy@pwning.systems> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 4fbcc1a4cb20fe26ad0225679c536c80f1648221)
CVE-2022-26490 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Bartlomiej Zolnierkiewicz <bartlomiej.zolnierkiewicz@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Peter Zijlstra [Tue, 26 Oct 2021 12:01:48 +0000 (14:01 +0200)]
bpf,x86: Respect X86_FEATURE_RETPOLINE*
BugLink: https://bugs.launchpad.net/bugs/1967579
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) <peterz@infradead.org> Reviewed-by: Borislav Petkov <bp@suse.de> Acked-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Tested-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/r/20211026120310.614772675@infradead.org
(backported from commit 87c87ecd00c54ecd677798cb49ef27329e0fab41)
[cascardo: RETPOLINE_AMD was renamed to RETPOLINE_LFENCE] Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Peter Zijlstra [Tue, 26 Oct 2021 12:01:47 +0000 (14:01 +0200)]
bpf,x86: Simplify computing label offsets
BugLink: https://bugs.launchpad.net/bugs/1967579
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.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Borislav Petkov <bp@suse.de> Acked-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Tested-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/r/20211026120310.552304864@infradead.org
(cherry picked from commit dceba0817ca329868a15e2e1dd46eb6340b69206) Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
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) <peterz@infradead.org> Reviewed-by: Borislav Petkov <bp@suse.de> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Tested-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/r/20211026120310.359986601@infradead.org
(backported from commit bbe2df3f6b6da7848398d55b1311d58a16ec21e4)
[cascardo: RETPOLINE_AMD was renamed to RETPOLINE_LFENCE] Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
projects / mirror_ubuntu-jammy-kernel.git / log