* Re: [PATCH v11 12/18] x86/fsgsbase/64: move save_fsgs to header file
@ 2020-05-10 8:14 kbuild test robot
0 siblings, 0 replies; 4+ messages in thread
From: kbuild test robot @ 2020-05-10 8:14 UTC (permalink / raw)
To: kbuild
[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]
CC: kbuild-all(a)lists.01.org
In-Reply-To: <20200509173655.13977-13-sashal@kernel.org>
References: <20200509173655.13977-13-sashal@kernel.org>
TO: Sasha Levin <alexander.levin@microsoft.com>
TO: linux-kernel(a)vger.kernel.org
TO: tglx(a)linutronix.de
TO: bp(a)alien8.de
TO: luto(a)kernel.org
CC: hpa(a)zytor.com
CC: dave.hansen(a)intel.com
CC: tony.luck(a)intel.com
CC: ak(a)linux.intel.com
CC: ravi.v.shankar(a)intel.com
CC: chang.seok.bae(a)intel.com
CC: Sasha Levin <alexander.levin@microsoft.com>
Hi Sasha,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tip/x86/asm]
[also build test WARNING on tip/auto-latest linus/master tip/x86/core v5.7-rc4 next-20200508]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Sasha-Levin/Enable-FSGSBASE-instructions/20200510-032805
base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 2ce0d7f9766f0e49bb54f149c77bae89464932fb
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-191-gc51a0382-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
:::::: branch date: 13 hours ago
:::::: commit date: 13 hours ago
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> arch/x86/kernel/process.h:42:9: sparse: sparse: empty enum definition
arch/x86/kernel/process.h:42:9: sparse: sparse: Expected } at end of struct-union-enum-specifier
arch/x86/kernel/process.h:42:9: sparse: sparse: got 9
# https://github.com/0day-ci/linux/commit/9e719afbb12b0236d01454efaac424c14f46bf69
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 9e719afbb12b0236d01454efaac424c14f46bf69
vim +42 arch/x86/kernel/process.h
9e719afbb12b02 Sasha Levin 2020-05-09 40
9e719afbb12b02 Sasha Levin 2020-05-09 41 enum which_selector {
9e719afbb12b02 Sasha Levin 2020-05-09 @42 FS,
9e719afbb12b02 Sasha Levin 2020-05-09 43 GS
9e719afbb12b02 Sasha Levin 2020-05-09 44 };
9e719afbb12b02 Sasha Levin 2020-05-09 45
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply [flat|nested] 4+ messages in thread* [PATCH v11 00/18] Enable FSGSBASE instructions
@ 2020-05-09 17:36 Sasha Levin
2020-05-09 17:36 ` [PATCH v11 12/18] x86/fsgsbase/64: move save_fsgs to header file Sasha Levin
0 siblings, 1 reply; 4+ messages in thread
From: Sasha Levin @ 2020-05-09 17:36 UTC (permalink / raw)
To: linux-kernel, tglx, bp, luto
Cc: hpa, dave.hansen, tony.luck, ak, ravi.v.shankar, chang.seok.bae,
Sasha Levin
Benefits:
Currently a user process that wishes to read or write the FS/GS base must
make a system call. But recent X86 processors have added new instructions
for use in 64-bit mode that allow direct access to the FS and GS segment
base addresses. The operating system controls whether applications can
use these instructions with a %cr4 control bit.
In addition to benefits to applications, performance improvements to the
OS context switch code are possible by making use of these instructions. A
third party reported out promising performance numbers out of their
initial benchmarking of the previous version of this patch series [9].
Enablement check:
The kernel provides information about the enabled state of FSGSBASE to
applications using the ELF_AUX vector. If the HWCAP2_FSGSBASE bit is set in
the AUX vector, the kernel has FSGSBASE instructions enabled and
applications can use them.
Kernel changes:
Major changes made in the kernel are in context switch, paranoid path, and
ptrace. In a context switch, a task's FS/GS base will be secured regardless
of its selector. In the paranoid path, GS base is unconditionally
overwritten to the kernel GS base on entry and the original GS base is
restored on exit. Ptrace includes divergence of FS/GS index and base
values.
Security:
For mitigating the Spectre v1 SWAPGS issue, LFENCE instructions were added
on most kernel entries. Those patches are dependent on previous behaviors
that users couldn't load a kernel address into the GS base. These patches
change that assumption since the user can load any address into GS base.
The changes to the kernel entry path in this patch series take account of
the SWAPGS issue.
Changes from v10:
- Rewrite the commit message for patch #1.
- Document communication/acks from userspace projects that are
potentially affected by this.
Andi Kleen (2):
x86/fsgsbase/64: Add intrinsics for FSGSBASE instructions
x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2
Andy Lutomirski (4):
x86/cpu: Add 'unsafe_fsgsbase' to enable CR4.FSGSBASE
x86/entry/64: Clean up paranoid exit
x86/fsgsbase/64: Use FSGSBASE in switch_to() if available
x86/fsgsbase/64: Enable FSGSBASE on 64bit by default and add a chicken
bit
Chang S. Bae (9):
x86/ptrace: Prevent ptrace from clearing the FS/GS selector
selftests/x86/fsgsbase: Test GS selector on ptracer-induced GS base
write
x86/entry/64: Switch CR3 before SWAPGS in paranoid entry
x86/entry/64: Introduce the FIND_PERCPU_BASE macro
x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit
x86/entry/64: Document GSBASE handling in the paranoid path
x86/fsgsbase/64: Enable FSGSBASE instructions in helper functions
x86/fsgsbase/64: Use FSGSBASE instructions on thread copy and ptrace
selftests/x86/fsgsbase: Test ptracer-induced GS base write with
FSGSBASE
Sasha Levin (1):
x86/fsgsbase/64: move save_fsgs to header file
Thomas Gleixner (1):
Documentation/x86/64: Add documentation for GS/FS addressing mode
Tony Luck (1):
x86/speculation/swapgs: Check FSGSBASE in enabling SWAPGS mitigation
.../admin-guide/kernel-parameters.txt | 2 +
Documentation/x86/entry_64.rst | 9 +
Documentation/x86/x86_64/fsgs.rst | 199 ++++++++++++++++++
Documentation/x86/x86_64/index.rst | 1 +
arch/x86/entry/calling.h | 40 ++++
arch/x86/entry/entry_64.S | 131 +++++++++---
arch/x86/include/asm/fsgsbase.h | 45 +++-
arch/x86/include/asm/inst.h | 15 ++
arch/x86/include/uapi/asm/hwcap2.h | 3 +
arch/x86/kernel/cpu/bugs.c | 6 +-
arch/x86/kernel/cpu/common.c | 22 ++
arch/x86/kernel/process.c | 10 +-
arch/x86/kernel/process.h | 68 ++++++
arch/x86/kernel/process_64.c | 142 +++++++------
arch/x86/kernel/ptrace.c | 17 +-
tools/testing/selftests/x86/fsgsbase.c | 24 ++-
16 files changed, 605 insertions(+), 129 deletions(-)
create mode 100644 Documentation/x86/x86_64/fsgs.rst
--
2.20.1
^ permalink raw reply [flat|nested] 4+ messages in thread* [PATCH v11 12/18] x86/fsgsbase/64: move save_fsgs to header file 2020-05-09 17:36 [PATCH v11 00/18] Enable FSGSBASE instructions Sasha Levin @ 2020-05-09 17:36 ` Sasha Levin 2020-05-09 23:39 ` kbuild test robot 0 siblings, 1 reply; 4+ messages in thread From: Sasha Levin @ 2020-05-09 17:36 UTC (permalink / raw) To: linux-kernel, tglx, bp, luto Cc: hpa, dave.hansen, tony.luck, ak, ravi.v.shankar, chang.seok.bae, Sasha Levin Given copy_thread_tls() is now shared between 32 and 64 bit and we need to use save_fsgs() there, move it to a header file. Signed-off-by: Sasha Levin <sashal@kernel.org> --- arch/x86/kernel/process.h | 68 ++++++++++++++++++++++++++++++++++++ arch/x86/kernel/process_64.c | 68 ------------------------------------ 2 files changed, 68 insertions(+), 68 deletions(-) diff --git a/arch/x86/kernel/process.h b/arch/x86/kernel/process.h index 1d0797b2338a2..e21b6669a3851 100644 --- a/arch/x86/kernel/process.h +++ b/arch/x86/kernel/process.h @@ -37,3 +37,71 @@ static inline void switch_to_extra(struct task_struct *prev, prev_tif & _TIF_WORK_CTXSW_PREV)) __switch_to_xtra(prev, next); } + +enum which_selector { + FS, + GS +}; + +/* + * Saves the FS or GS base for an outgoing thread if FSGSBASE extensions are + * not available. The goal is to be reasonably fast on non-FSGSBASE systems. + * It's forcibly inlined because it'll generate better code and this function + * is hot. + */ +static __always_inline void save_base_legacy(struct task_struct *prev_p, + unsigned short selector, + enum which_selector which) +{ + if (likely(selector == 0)) { + /* + * On Intel (without X86_BUG_NULL_SEG), the segment base could + * be the pre-existing saved base or it could be zero. On AMD + * (with X86_BUG_NULL_SEG), the segment base could be almost + * anything. + * + * This branch is very hot (it's hit twice on almost every + * context switch between 64-bit programs), and avoiding + * the RDMSR helps a lot, so we just assume that whatever + * value is already saved is correct. This matches historical + * Linux behavior, so it won't break existing applications. + * + * To avoid leaking state, on non-X86_BUG_NULL_SEG CPUs, if we + * report that the base is zero, it needs to actually be zero: + * see the corresponding logic in load_seg_legacy. + */ + } else { + /* + * If the selector is 1, 2, or 3, then the base is zero on + * !X86_BUG_NULL_SEG CPUs and could be anything on + * X86_BUG_NULL_SEG CPUs. In the latter case, Linux + * has never attempted to preserve the base across context + * switches. + * + * If selector > 3, then it refers to a real segment, and + * saving the base isn't necessary. + */ + if (which == FS) + prev_p->thread.fsbase = 0; + else + prev_p->thread.gsbase = 0; + } +} + +static __always_inline void save_fsgs(struct task_struct *task) +{ + savesegment(fs, task->thread.fsindex); + savesegment(gs, task->thread.gsindex); + if (static_cpu_has(X86_FEATURE_FSGSBASE)) { + /* + * If FSGSBASE is enabled, we can't make any useful guesses + * about the base, and user code expects us to save the current + * value. Fortunately, reading the base directly is efficient. + */ + task->thread.fsbase = rdfsbase(); + task->thread.gsbase = x86_gsbase_read_cpu_inactive(); + } else { + save_base_legacy(task, task->thread.fsindex, FS); + save_base_legacy(task, task->thread.gsindex, GS); + } +} diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index e066750be89a0..4be88124d81ea 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -145,74 +145,6 @@ void release_thread(struct task_struct *dead_task) WARN_ON(dead_task->mm); } -enum which_selector { - FS, - GS -}; - -/* - * Saves the FS or GS base for an outgoing thread if FSGSBASE extensions are - * not available. The goal is to be reasonably fast on non-FSGSBASE systems. - * It's forcibly inlined because it'll generate better code and this function - * is hot. - */ -static __always_inline void save_base_legacy(struct task_struct *prev_p, - unsigned short selector, - enum which_selector which) -{ - if (likely(selector == 0)) { - /* - * On Intel (without X86_BUG_NULL_SEG), the segment base could - * be the pre-existing saved base or it could be zero. On AMD - * (with X86_BUG_NULL_SEG), the segment base could be almost - * anything. - * - * This branch is very hot (it's hit twice on almost every - * context switch between 64-bit programs), and avoiding - * the RDMSR helps a lot, so we just assume that whatever - * value is already saved is correct. This matches historical - * Linux behavior, so it won't break existing applications. - * - * To avoid leaking state, on non-X86_BUG_NULL_SEG CPUs, if we - * report that the base is zero, it needs to actually be zero: - * see the corresponding logic in load_seg_legacy. - */ - } else { - /* - * If the selector is 1, 2, or 3, then the base is zero on - * !X86_BUG_NULL_SEG CPUs and could be anything on - * X86_BUG_NULL_SEG CPUs. In the latter case, Linux - * has never attempted to preserve the base across context - * switches. - * - * If selector > 3, then it refers to a real segment, and - * saving the base isn't necessary. - */ - if (which == FS) - prev_p->thread.fsbase = 0; - else - prev_p->thread.gsbase = 0; - } -} - -static __always_inline void save_fsgs(struct task_struct *task) -{ - savesegment(fs, task->thread.fsindex); - savesegment(gs, task->thread.gsindex); - if (static_cpu_has(X86_FEATURE_FSGSBASE)) { - /* - * If FSGSBASE is enabled, we can't make any useful guesses - * about the base, and user code expects us to save the current - * value. Fortunately, reading the base directly is efficient. - */ - task->thread.fsbase = rdfsbase(); - task->thread.gsbase = x86_gsbase_read_cpu_inactive(); - } else { - save_base_legacy(task, task->thread.fsindex, FS); - save_base_legacy(task, task->thread.gsindex, GS); - } -} - #if IS_ENABLED(CONFIG_KVM) /* * While a process is running,current->thread.fsbase and current->thread.gsbase -- 2.20.1 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v11 12/18] x86/fsgsbase/64: move save_fsgs to header file 2020-05-09 17:36 ` [PATCH v11 12/18] x86/fsgsbase/64: move save_fsgs to header file Sasha Levin @ 2020-05-09 23:39 ` kbuild test robot 0 siblings, 0 replies; 4+ messages in thread From: kbuild test robot @ 2020-05-09 23:39 UTC (permalink / raw) To: Sasha Levin, linux-kernel, tglx, bp, luto Cc: kbuild-all, hpa, dave.hansen, tony.luck, ak, ravi.v.shankar, chang.seok.bae, Sasha Levin [-- Attachment #1: Type: text/plain, Size: 8076 bytes --] Hi Sasha, I love your patch! Yet something to improve: [auto build test ERROR on tip/x86/asm] [also build test ERROR on tip/auto-latest linus/master tip/x86/core v5.7-rc4 next-20200508] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Sasha-Levin/Enable-FSGSBASE-instructions/20200510-032805 base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 2ce0d7f9766f0e49bb54f149c77bae89464932fb config: i386-allyesconfig (attached as .config) compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot <lkp@intel.com> All error/warnings (new ones prefixed by >>): In file included from arch/x86/include/uapi/asm/ptrace.h:6:0, from arch/x86/include/asm/ptrace.h:7, from arch/x86/include/asm/math_emu.h:5, from arch/x86/include/asm/processor.h:13, from arch/x86/include/asm/cpufeature.h:5, from arch/x86/include/asm/thread_info.h:53, from include/linux/thread_info.h:38, from arch/x86/include/asm/preempt.h:7, from include/linux/preempt.h:78, from include/linux/spinlock.h:51, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/mm.h:10, from arch/x86/kernel/process.c:6: >> arch/x86/include/uapi/asm/ptrace-abi.h:16:12: error: expected identifier before numeric constant #define FS 9 ^ >> arch/x86/kernel/process.h:42:2: note: in expansion of macro 'FS' FS, ^~ In file included from arch/x86/kernel/process.c:46:0: arch/x86/kernel/process.h: In function 'save_base_legacy': >> arch/x86/kernel/process.h:85:18: error: 'struct thread_struct' has no member named 'fsbase' prev_p->thread.fsbase = 0; ^ >> arch/x86/kernel/process.h:87:18: error: 'struct thread_struct' has no member named 'gsbase' prev_p->thread.gsbase = 0; ^ In file included from arch/x86/include/asm/ptrace.h:5:0, from arch/x86/include/asm/math_emu.h:5, from arch/x86/include/asm/processor.h:13, from arch/x86/include/asm/cpufeature.h:5, from arch/x86/include/asm/thread_info.h:53, from include/linux/thread_info.h:38, from arch/x86/include/asm/preempt.h:7, from include/linux/preempt.h:78, from include/linux/spinlock.h:51, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/mm.h:10, from arch/x86/kernel/process.c:6: arch/x86/kernel/process.h: In function 'save_fsgs': >> arch/x86/kernel/process.h:93:30: error: 'struct thread_struct' has no member named 'fsindex' savesegment(fs, task->thread.fsindex); ^ arch/x86/include/asm/segment.h:368:32: note: in definition of macro 'savesegment' asm("mov %%" #seg ",%0":"=r" (value) : : "memory") ^~~~~ >> arch/x86/kernel/process.h:94:30: error: 'struct thread_struct' has no member named 'gsindex' savesegment(gs, task->thread.gsindex); ^ arch/x86/include/asm/segment.h:368:32: note: in definition of macro 'savesegment' asm("mov %%" #seg ",%0":"=r" (value) : : "memory") ^~~~~ In file included from arch/x86/kernel/process.c:46:0: arch/x86/kernel/process.h:101:15: error: 'struct thread_struct' has no member named 'fsbase' task->thread.fsbase = rdfsbase(); ^ >> arch/x86/kernel/process.h:101:25: error: implicit declaration of function 'rdfsbase'; did you mean 'rb_erase'? [-Werror=implicit-function-declaration] task->thread.fsbase = rdfsbase(); ^~~~~~~~ rb_erase arch/x86/kernel/process.h:102:15: error: 'struct thread_struct' has no member named 'gsbase' task->thread.gsbase = x86_gsbase_read_cpu_inactive(); ^ >> arch/x86/kernel/process.h:102:25: error: implicit declaration of function 'x86_gsbase_read_cpu_inactive' [-Werror=implicit-function-declaration] task->thread.gsbase = x86_gsbase_read_cpu_inactive(); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/x86/kernel/process.h:104:38: error: 'struct thread_struct' has no member named 'fsindex' save_base_legacy(task, task->thread.fsindex, FS); ^ arch/x86/kernel/process.h:105:38: error: 'struct thread_struct' has no member named 'gsindex' save_base_legacy(task, task->thread.gsindex, GS); ^ cc1: some warnings being treated as errors vim +85 arch/x86/kernel/process.h 40 41 enum which_selector { > 42 FS, 43 GS 44 }; 45 46 /* 47 * Saves the FS or GS base for an outgoing thread if FSGSBASE extensions are 48 * not available. The goal is to be reasonably fast on non-FSGSBASE systems. 49 * It's forcibly inlined because it'll generate better code and this function 50 * is hot. 51 */ 52 static __always_inline void save_base_legacy(struct task_struct *prev_p, 53 unsigned short selector, 54 enum which_selector which) 55 { 56 if (likely(selector == 0)) { 57 /* 58 * On Intel (without X86_BUG_NULL_SEG), the segment base could 59 * be the pre-existing saved base or it could be zero. On AMD 60 * (with X86_BUG_NULL_SEG), the segment base could be almost 61 * anything. 62 * 63 * This branch is very hot (it's hit twice on almost every 64 * context switch between 64-bit programs), and avoiding 65 * the RDMSR helps a lot, so we just assume that whatever 66 * value is already saved is correct. This matches historical 67 * Linux behavior, so it won't break existing applications. 68 * 69 * To avoid leaking state, on non-X86_BUG_NULL_SEG CPUs, if we 70 * report that the base is zero, it needs to actually be zero: 71 * see the corresponding logic in load_seg_legacy. 72 */ 73 } else { 74 /* 75 * If the selector is 1, 2, or 3, then the base is zero on 76 * !X86_BUG_NULL_SEG CPUs and could be anything on 77 * X86_BUG_NULL_SEG CPUs. In the latter case, Linux 78 * has never attempted to preserve the base across context 79 * switches. 80 * 81 * If selector > 3, then it refers to a real segment, and 82 * saving the base isn't necessary. 83 */ 84 if (which == FS) > 85 prev_p->thread.fsbase = 0; 86 else > 87 prev_p->thread.gsbase = 0; 88 } 89 } 90 91 static __always_inline void save_fsgs(struct task_struct *task) 92 { > 93 savesegment(fs, task->thread.fsindex); > 94 savesegment(gs, task->thread.gsindex); 95 if (static_cpu_has(X86_FEATURE_FSGSBASE)) { 96 /* 97 * If FSGSBASE is enabled, we can't make any useful guesses 98 * about the base, and user code expects us to save the current 99 * value. Fortunately, reading the base directly is efficient. 100 */ > 101 task->thread.fsbase = rdfsbase(); > 102 task->thread.gsbase = x86_gsbase_read_cpu_inactive(); --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 72326 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v11 12/18] x86/fsgsbase/64: move save_fsgs to header file @ 2020-05-09 23:39 ` kbuild test robot 0 siblings, 0 replies; 4+ messages in thread From: kbuild test robot @ 2020-05-09 23:39 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 8246 bytes --] Hi Sasha, I love your patch! Yet something to improve: [auto build test ERROR on tip/x86/asm] [also build test ERROR on tip/auto-latest linus/master tip/x86/core v5.7-rc4 next-20200508] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Sasha-Levin/Enable-FSGSBASE-instructions/20200510-032805 base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 2ce0d7f9766f0e49bb54f149c77bae89464932fb config: i386-allyesconfig (attached as .config) compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot <lkp@intel.com> All error/warnings (new ones prefixed by >>): In file included from arch/x86/include/uapi/asm/ptrace.h:6:0, from arch/x86/include/asm/ptrace.h:7, from arch/x86/include/asm/math_emu.h:5, from arch/x86/include/asm/processor.h:13, from arch/x86/include/asm/cpufeature.h:5, from arch/x86/include/asm/thread_info.h:53, from include/linux/thread_info.h:38, from arch/x86/include/asm/preempt.h:7, from include/linux/preempt.h:78, from include/linux/spinlock.h:51, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/mm.h:10, from arch/x86/kernel/process.c:6: >> arch/x86/include/uapi/asm/ptrace-abi.h:16:12: error: expected identifier before numeric constant #define FS 9 ^ >> arch/x86/kernel/process.h:42:2: note: in expansion of macro 'FS' FS, ^~ In file included from arch/x86/kernel/process.c:46:0: arch/x86/kernel/process.h: In function 'save_base_legacy': >> arch/x86/kernel/process.h:85:18: error: 'struct thread_struct' has no member named 'fsbase' prev_p->thread.fsbase = 0; ^ >> arch/x86/kernel/process.h:87:18: error: 'struct thread_struct' has no member named 'gsbase' prev_p->thread.gsbase = 0; ^ In file included from arch/x86/include/asm/ptrace.h:5:0, from arch/x86/include/asm/math_emu.h:5, from arch/x86/include/asm/processor.h:13, from arch/x86/include/asm/cpufeature.h:5, from arch/x86/include/asm/thread_info.h:53, from include/linux/thread_info.h:38, from arch/x86/include/asm/preempt.h:7, from include/linux/preempt.h:78, from include/linux/spinlock.h:51, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/mm.h:10, from arch/x86/kernel/process.c:6: arch/x86/kernel/process.h: In function 'save_fsgs': >> arch/x86/kernel/process.h:93:30: error: 'struct thread_struct' has no member named 'fsindex' savesegment(fs, task->thread.fsindex); ^ arch/x86/include/asm/segment.h:368:32: note: in definition of macro 'savesegment' asm("mov %%" #seg ",%0":"=r" (value) : : "memory") ^~~~~ >> arch/x86/kernel/process.h:94:30: error: 'struct thread_struct' has no member named 'gsindex' savesegment(gs, task->thread.gsindex); ^ arch/x86/include/asm/segment.h:368:32: note: in definition of macro 'savesegment' asm("mov %%" #seg ",%0":"=r" (value) : : "memory") ^~~~~ In file included from arch/x86/kernel/process.c:46:0: arch/x86/kernel/process.h:101:15: error: 'struct thread_struct' has no member named 'fsbase' task->thread.fsbase = rdfsbase(); ^ >> arch/x86/kernel/process.h:101:25: error: implicit declaration of function 'rdfsbase'; did you mean 'rb_erase'? [-Werror=implicit-function-declaration] task->thread.fsbase = rdfsbase(); ^~~~~~~~ rb_erase arch/x86/kernel/process.h:102:15: error: 'struct thread_struct' has no member named 'gsbase' task->thread.gsbase = x86_gsbase_read_cpu_inactive(); ^ >> arch/x86/kernel/process.h:102:25: error: implicit declaration of function 'x86_gsbase_read_cpu_inactive' [-Werror=implicit-function-declaration] task->thread.gsbase = x86_gsbase_read_cpu_inactive(); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/x86/kernel/process.h:104:38: error: 'struct thread_struct' has no member named 'fsindex' save_base_legacy(task, task->thread.fsindex, FS); ^ arch/x86/kernel/process.h:105:38: error: 'struct thread_struct' has no member named 'gsindex' save_base_legacy(task, task->thread.gsindex, GS); ^ cc1: some warnings being treated as errors vim +85 arch/x86/kernel/process.h 40 41 enum which_selector { > 42 FS, 43 GS 44 }; 45 46 /* 47 * Saves the FS or GS base for an outgoing thread if FSGSBASE extensions are 48 * not available. The goal is to be reasonably fast on non-FSGSBASE systems. 49 * It's forcibly inlined because it'll generate better code and this function 50 * is hot. 51 */ 52 static __always_inline void save_base_legacy(struct task_struct *prev_p, 53 unsigned short selector, 54 enum which_selector which) 55 { 56 if (likely(selector == 0)) { 57 /* 58 * On Intel (without X86_BUG_NULL_SEG), the segment base could 59 * be the pre-existing saved base or it could be zero. On AMD 60 * (with X86_BUG_NULL_SEG), the segment base could be almost 61 * anything. 62 * 63 * This branch is very hot (it's hit twice on almost every 64 * context switch between 64-bit programs), and avoiding 65 * the RDMSR helps a lot, so we just assume that whatever 66 * value is already saved is correct. This matches historical 67 * Linux behavior, so it won't break existing applications. 68 * 69 * To avoid leaking state, on non-X86_BUG_NULL_SEG CPUs, if we 70 * report that the base is zero, it needs to actually be zero: 71 * see the corresponding logic in load_seg_legacy. 72 */ 73 } else { 74 /* 75 * If the selector is 1, 2, or 3, then the base is zero on 76 * !X86_BUG_NULL_SEG CPUs and could be anything on 77 * X86_BUG_NULL_SEG CPUs. In the latter case, Linux 78 * has never attempted to preserve the base across context 79 * switches. 80 * 81 * If selector > 3, then it refers to a real segment, and 82 * saving the base isn't necessary. 83 */ 84 if (which == FS) > 85 prev_p->thread.fsbase = 0; 86 else > 87 prev_p->thread.gsbase = 0; 88 } 89 } 90 91 static __always_inline void save_fsgs(struct task_struct *task) 92 { > 93 savesegment(fs, task->thread.fsindex); > 94 savesegment(gs, task->thread.gsindex); 95 if (static_cpu_has(X86_FEATURE_FSGSBASE)) { 96 /* 97 * If FSGSBASE is enabled, we can't make any useful guesses 98 * about the base, and user code expects us to save the current 99 * value. Fortunately, reading the base directly is efficient. 100 */ > 101 task->thread.fsbase = rdfsbase(); > 102 task->thread.gsbase = x86_gsbase_read_cpu_inactive(); --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 72326 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-05-10 8:14 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-10 8:14 [PATCH v11 12/18] x86/fsgsbase/64: move save_fsgs to header file kbuild test robot -- strict thread matches above, loose matches on Subject: below -- 2020-05-09 17:36 [PATCH v11 00/18] Enable FSGSBASE instructions Sasha Levin 2020-05-09 17:36 ` [PATCH v11 12/18] x86/fsgsbase/64: move save_fsgs to header file Sasha Levin 2020-05-09 23:39 ` kbuild test robot 2020-05-09 23:39 ` kbuild test robot
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.