wireguard-linux/arch/x86/kernel/fpu, branch jd/unified-crypt-queue

x86/pkeys: Add check for pkey "overflow"

2020-02-24T19:25:21Z

Alex Shi reported the pkey macros above arch_set_user_pkey_access() to be unused. They are unused, and even refer to a nonexistent CONFIG option. But, they might have served a good use, which was to ensure that the code does not try to set values that would not fit in the PKRU register. As it stands, a too-large 'pkey' value would be likely to silently overflow the u32 new_pkru_bits. Add a check to look for overflows. Also add a comment to remind any future developer to closely examine the types used to store pkey values if arch_max_pkey() ever changes. This boots and passes the x86 pkey selftests. Reported-by: Alex Shi Signed-off-by: Dave Hansen Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200122165346.AD4DA150@viggo.jf.intel.com

x86/fpu/xstate: Warn when checking alignment of disabled xfeatures

2020-02-12T14:43:34Z

An XSAVES component's alignment/offset is meaningful only when the feature is enabled. Return zero and WARN_ONCE on checking alignment of disabled features. Signed-off-by: Yu-cheng Yu Signed-off-by: Borislav Petkov Reviewed-by: Dave Hansen Link: https://lkml.kernel.org/r/20200109211452.27369-4-yu-cheng.yu@intel.com

x86/fpu/xstate: Fix XSAVES offsets in setup_xstate_comp()

2020-02-12T14:43:31Z

In setup_xstate_comp(), each XSAVES component offset starts from the end of its preceding component plus alignment. A disabled feature does not take space and its offset should be set to the end of its preceding one with no alignment. However, in this case, alignment is incorrectly added to the offset, which can cause the next component to have a wrong offset. This problem has not been visible because currently there is no xfeature requiring alignment. Fix it by tracking the next starting offset only from enabled xfeatures. To make it clear, also change the function name to setup_xstate_comp_offsets(). [ bp: Fix a typo in the comment above it, while at it. ] Signed-off-by: Yu-cheng Yu Signed-off-by: Borislav Petkov Reviewed-by: Dave Hansen Link: https://lkml.kernel.org/r/20200109211452.27369-3-yu-cheng.yu@intel.com

x86/fpu/xstate: Fix last_good_offset in setup_xstate_features()

2020-02-11T18:54:04Z

The function setup_xstate_features() uses CPUID to find each xfeature's standard-format offset and size. Since XSAVES always uses the compacted format, supervisor xstates are *NEVER* in the standard-format and their offsets are left as -1's. However, they are still being tracked as last_good_offset. Fix it by tracking only user xstate offsets. [ bp: Use xfeature_is_supervisor() and save an indentation level. Drop now unused xfeature_is_user(). ] Signed-off-by: Yu-cheng Yu Signed-off-by: Borislav Petkov Reviewed-by: Dave Hansen Link: https://lkml.kernel.org/r/20200109211452.27369-2-yu-cheng.yu@intel.com

x86/fpu: Deactivate FPU state after failure during state load

2020-01-07T12:44:42Z

In __fpu__restore_sig(), fpu_fpregs_owner_ctx needs to be reset if the FPU state was not fully restored. Otherwise the following may happen (on the same CPU): Task A Task B fpu_fpregs_owner_ctx *active* A.fpu __fpu__restore_sig() ctx switch load B.fpu *active* B.fpu fpregs_lock() copy_user_to_fpregs_zeroing() copy_kernel_to_xregs() *modify* copy_user_to_xregs() *fails* fpregs_unlock() ctx switch skip loading B.fpu, *active* B.fpu In the success case, fpu_fpregs_owner_ctx is set to the current task. In the failure case, the FPU state might have been modified by loading the init state. In this case, fpu_fpregs_owner_ctx needs to be reset in order to ensure that the FPU state of the following task is loaded from saved state (and not skipped because it was the previous state). Reset fpu_fpregs_owner_ctx after a failure during restore occurred, to ensure that the FPU state for the next task is always loaded. The problem was debugged-by Yu-cheng Yu . [ bp: Massage commit message. ] Fixes: 5f409e20b7945 ("x86/fpu: Defer FPU state load until return to userspace") Reported-by: Yu-cheng Yu Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Borislav Petkov Cc: Andy Lutomirski Cc: Dave Hansen Cc: Fenghua Yu Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jann Horn Cc: Peter Zijlstra Cc: "Ravi V. Shankar" Cc: Rik van Riel Cc: Thomas Gleixner Cc: Tony Luck Cc: x86-ml Link: https://lkml.kernel.org/r/20191220195906.plk6kpmsrikvbcfn@linutronix.de

x86/fpu/xstate: Make xfeature_is_supervisor()/xfeature_is_user() return bool

2020-01-06T18:08:40Z

Have both xfeature_is_supervisor()/xfeature_is_user() return bool because they are used only in boolean context. Suggested-by: Borislav Petkov Signed-off-by: Yu-cheng Yu Signed-off-by: Borislav Petkov Acked-by: Sebastian Andrzej Siewior Cc: Andy Lutomirski Cc: Dave Hansen Cc: Fenghua Yu Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Peter Zijlstra Cc: "Ravi V. Shankar" Cc: Rik van Riel Cc: Thomas Gleixner Cc: Tony Luck Cc: x86-ml Link: https://lkml.kernel.org/r/20191212210855.19260-3-yu-cheng.yu@intel.com

x86/fpu/xstate: Fix small issues

2020-01-06T16:31:11Z

In response to earlier comments, fix small issues before introducing XSAVES supervisor states: - Fix comments of xfeature_is_supervisor(). - Replace ((u64)1 << 63) with XCOMP_BV_COMPACTED_FORMAT. No functional changes. Signed-off-by: Yu-cheng Yu Signed-off-by: Borislav Petkov Reviewed-by: Dave Hansen Reviewed-by: Tony Luck Acked-by: Sebastian Andrzej Siewior Cc: Andy Lutomirski Cc: Dave Hansen Cc: Fenghua Yu Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Peter Zijlstra Cc: "Ravi V. Shankar" Cc: Rik van Riel Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20191212210855.19260-2-yu-cheng.yu@intel.com

treewide: Use sizeof_field() macro

2019-12-09T18:36:44Z

Replace all the occurrences of FIELD_SIZEOF() with sizeof_field() except at places where these are defined. Later patches will remove the unused definition of FIELD_SIZEOF(). This patch is generated using following script: EXCLUDE_FILES="include/linux/stddef.h|include/linux/kernel.h" git grep -l -e "\bFIELD_SIZEOF\b" | while read file; do if [[ "$file" =~ $EXCLUDE_FILES ]]; then continue fi sed -i -e 's/\bFIELD_SIZEOF\b/sizeof_field/g' $file; done Signed-off-by: Pankaj Bharadiya Link: https://lore.kernel.org/r/20190924105839.110713-3-pankaj.laxminarayan.bharadiya@intel.com Co-developed-by: Kees Cook Signed-off-by: Kees Cook Acked-by: David Miller # for net

x86/fpu: Use XFEATURE_FP/SSE enum values instead of hardcoded numbers

2019-11-04T21:10:07Z

When setting up sizes and offsets for legacy header entries the code uses hardcoded 0/1 instead of the corresponding enum values XFEATURE_FP and XFEATURE_SSE. Replace the hardcoded numbers which enhances readability of the code and also makes this code the first user of those enum values.. Signed-off-by: Cyrill Gorcunov Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20191101130153.GG1615@uranus.lan

x86/fpu: Shrink space allocated for xstate_comp_offsets

2019-11-04T21:04:19Z

commit 8ff925e10f2c ("x86/xsaves: Clean up code in xstate offsets computation in xsave area") introduced an allocation of 64 entries for xstate_comp_offsets while the code only handles up to XFEATURE_MAX entries. For this reason xstate_offsets and xstate_sizes are already defined with the explicit XFEATURE_MAX limit. Do the same for compressed format for consistency sake. As the changelog of that commit is not giving any information it's assumed that the main idea was to cover all possible bits in xfeatures_mask, but this doesn't explain why other variables such as the non-compacted offsets and sizes are explicitely limited to XFEATURE_MAX. For consistency it's better to use the XFEATURE_MAX limit everywhere and extend it on demand when new features get implemented at the hardware level and subsequently supported by the kernel. Signed-off-by: Cyrill Gorcunov Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20191101124228.GF1615@uranus.lan