On 4/9/2021 8:57 AM, Kirill A. Shutemov wrote:
On Thu, Apr 01, 2021 at 03:10:56PM -0700, Yu-cheng Yu wrote:
Introduce basic shadow stack enabling/disabling/allocation routines.
A task's shadow stack is allocated from memory with VM_SHADOW_STACK flag
and has a fixed size of min(RLIMIT_STACK, 4GB)
On 4/9/2021 10:14 AM, Borislav Petkov wrote:
On Fri, Apr 09, 2021 at 08:52:52AM -0700, Yu, Yu-cheng wrote:
Recall we had complicated code for the XSAVES features detection in
xstate.c. Dave Hansen proposed the solution and then the whole thing
becomes simple. Because of this flag, even when
On 4/9/2021 3:12 AM, Borislav Petkov wrote:
On Thu, Apr 01, 2021 at 03:10:38PM -0700, Yu-cheng Yu wrote:
Introduce a software-defined X86_FEATURE_CET, which indicates either Shadow
Stack or Indirect Branch Tracking (or both) is present. Also introduce
related cpu init/setup functions.
Signed-o
On 4/6/2021 3:50 PM, Andy Lutomirski wrote:
On Thu, Apr 1, 2021 at 3:11 PM Yu-cheng Yu wrote:
When shadow stack is enabled, a task's shadow stack states must be saved
along with the signal context and later restored in sigreturn. However,
currently there is no systematic facility for extendin
On 3/22/2021 3:57 AM, Kirill A. Shutemov wrote:
On Tue, Mar 16, 2021 at 08:10:44AM -0700, Yu-cheng Yu wrote:
Account shadow stack pages to stack memory.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/mm/pgtable.c | 7 +++
include/linux/pgtable.h | 11 +++
mm
On 3/23/2021 1:49 PM, Peter Zijlstra wrote:
On Fri, Mar 19, 2021 at 02:43:04PM -0700, Yu, Yu-cheng wrote:
On 3/16/2021 2:15 PM, Peter Zijlstra wrote:
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return
On 3/22/2021 3:38 AM, Kirill A. Shutemov wrote:
On Tue, Mar 16, 2021 at 08:10:40AM -0700, Yu-cheng Yu wrote:
[...]
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index a73347e2cdfc..4316732a18c6 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1100,6 +1100,17 @@ access_
On 3/22/2021 2:13 AM, Kirill A. Shutemov wrote:
On Tue, Mar 16, 2021 at 08:10:33AM -0700, Yu-cheng Yu wrote:
The x86 family of processors do not directly create read-only and Dirty
PTEs. These PTEs are created by software. One such case is that kernel
read-only pages are historically setup as
On 3/16/2021 2:15 PM, Peter Zijlstra wrote:
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Ma
On 3/17/2021 2:18 AM, Ingo Molnar wrote:
* Yu, Yu-cheng wrote:
On 3/16/2021 2:15 PM, Peter Zijlstra wrote:
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks
On 3/19/2021 2:28 AM, Borislav Petkov wrote:
On Thu, Mar 18, 2021 at 12:05:58PM -0700, Yu, Yu-cheng wrote:
Maybe I would add comments here.
Yap.
Also, looking forward in the set, I see prctl_set() and that is also
done on current so should be ok.
In any case, yes, documenting the
On 3/18/2021 5:32 AM, Borislav Petkov wrote:
Subject: Re: [PATCH v23 22/28] x86/cet/shstk: User-mode shadow stack support
^
Add
On Tue, Mar 16, 2021 at 08:10:48AM -0700, Yu-cheng Yu wrote:
Introdu
On 3/18/2021 4:42 AM, Borislav Petkov wrote:
On Tue, Mar 16, 2021 at 08:10:47AM -0700, Yu-cheng Yu wrote:
There was no more caller passing vm_flags to do_mmap(), and vm_flags was
removed from the function's input by:
commit 45e55300f114 ("mm: remove unnecessary wrapper function
do_mmap_pg
On 3/16/2021 2:15 PM, Peter Zijlstra wrote:
On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote:
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Ma
On 3/16/2021 1:26 PM, Yu, Yu-cheng wrote:
On 3/16/2021 1:15 PM, Peter Zijlstra wrote:
On Tue, Mar 16, 2021 at 01:05:30PM -0700, Yu, Yu-cheng wrote:
On 3/16/2021 12:57 PM, Peter Zijlstra wrote:
On Tue, Mar 16, 2021 at 10:12:39AM -0700, Yu, Yu-cheng wrote:
Alternatively, there is another
On 3/16/2021 1:15 PM, Peter Zijlstra wrote:
On Tue, Mar 16, 2021 at 01:05:30PM -0700, Yu, Yu-cheng wrote:
On 3/16/2021 12:57 PM, Peter Zijlstra wrote:
On Tue, Mar 16, 2021 at 10:12:39AM -0700, Yu, Yu-cheng wrote:
Alternatively, there is another compiler-defined macro _CET_ENDBR that can
be
On 3/16/2021 12:57 PM, Peter Zijlstra wrote:
On Tue, Mar 16, 2021 at 10:12:39AM -0700, Yu, Yu-cheng wrote:
Alternatively, there is another compiler-defined macro _CET_ENDBR that can
be used. We can put the following in calling.h:
#ifdef __CET__
#include
#else
#define _CET_ENDBR
#endif
and
On 3/16/2021 12:22 PM, Jarkko Sakkinen wrote:
On Tue, Mar 16, 2021 at 08:13:19AM -0700, Yu-cheng Yu wrote:
ENDBR is a special new instruction for the Indirect Branch Tracking (IBT)
component of CET. IBT prevents attacks by ensuring that (most) indirect
branches and function calls may only land
On 3/16/2021 10:28 AM, Dave Hansen wrote:
On 3/16/21 10:12 AM, Yu, Yu-cheng wrote:
On 3/16/2021 8:49 AM, Dave Hansen wrote:
...
Is "#ifdef __i386__" the right thing to use here? I guess ENDBR only
ends up getting used in the VDSO, but there's a lot of
non-userspace-exposed stu
On 3/16/2021 10:30 AM, Borislav Petkov wrote:
On Tue, Mar 16, 2021 at 10:12:39AM -0700, Yu, Yu-cheng wrote:
Alternatively, there is another compiler-defined macro _CET_ENDBR that can
be used. We can put the following in calling.h:
Not calling.h - this is apparently needed in vdso code only
On 3/16/2021 8:49 AM, Dave Hansen wrote:
On 3/16/21 8:13 AM, Yu-cheng Yu wrote:
--- a/arch/x86/entry/calling.h
+++ b/arch/x86/entry/calling.h
@@ -392,3 +392,21 @@ For 32-bit we have the following conventions - kernel is
built with
.endm
#endif /* CONFIG_SMP */
+/*
+ * ENDBR is an instru
On 3/11/2021 9:17 AM, Stefan Puiu wrote:
Hi,
My 2 cents below.
On Tue, Mar 9, 2021, 16:33 Borislav Petkov <mailto:b...@alien8.de>> wrote:
On Mon, Mar 08, 2021 at 01:46:07PM -0800, Yu, Yu-cheng wrote:
> I think the sentence above is vague, but probably for the reason
On 3/11/2021 12:42 AM, Peter Zijlstra wrote:
On Thu, Mar 11, 2021 at 05:36:06AM +0200, Jarkko Sakkinen wrote:
Does it do any harm to put it there unconditionally?
Blows up your text footprint and I$ pressure. These instructions are 4
bytes each.
Aside from that, they're a NOP, so only consume
On 3/10/2021 3:20 PM, Dave Hansen wrote:
On 3/10/21 2:55 PM, Yu, Yu-cheng wrote:
On 3/10/2021 2:39 PM, Jarkko Sakkinen wrote:
On Wed, Mar 10, 2021 at 02:05:19PM -0800, Yu-cheng Yu wrote:
When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
in the beginning of the function.
OK
On 3/10/2021 2:39 PM, Jarkko Sakkinen wrote:
On Wed, Mar 10, 2021 at 02:05:19PM -0800, Yu-cheng Yu wrote:
When CET is enabled, __vdso_sgx_enter_enclave() needs an endbr64
in the beginning of the function.
OK.
What you should do is to explain what it does and why it's needed.
The endbr mark
On 3/8/2021 1:30 PM, Borislav Petkov wrote:
On Fri, Feb 26, 2021 at 09:26:34AM -0800, Yu-cheng Yu wrote:
SIGSEGV fills si_addr only for memory access faults. Add a note to clarify.
Signed-off-by: Yu-cheng Yu
Cc: Alejandro Colomar
Cc: Michael Kerrisk
Cc: Andy Lutomirski
Cc: Borislav Petkov
On 3/5/2021 6:29 AM, Borislav Petkov wrote:
On Wed, Feb 17, 2021 at 02:27:14PM -0800, Yu-cheng Yu wrote:
@@ -787,16 +802,34 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t
newprot)
*/
val &= _PAGE_CHG_MASK;
val |= check_pgprot(newprot) & ~_PAGE_CHG_MASK;
+ v
On 3/1/2021 7:52 AM, Borislav Petkov wrote:
On Wed, Feb 17, 2021 at 02:27:12PM -0800, Yu-cheng Yu wrote:
[...]
static inline pmd_t pmd_mkdirty(pmd_t pmd)
{
- return pmd_set_flags(pmd, _PAGE_DIRTY | _PAGE_SOFT_DIRTY);
+ pmdval_t dirty = _PAGE_DIRTY;
+
+ /* Avoid creating
On 3/1/2021 7:52 AM, Borislav Petkov wrote:
On Wed, Feb 17, 2021 at 02:27:12PM -0800, Yu-cheng Yu wrote:
@@ -182,7 +206,7 @@ static inline int pud_young(pud_t pud)
static inline int pte_write(pte_t pte)
{
- return pte_flags(pte) & _PAGE_RW;
Put here a comment along the lines of:
On 2/24/2021 11:42 AM, Borislav Petkov wrote:
On Wed, Feb 24, 2021 at 11:30:34AM -0800, Andy Lutomirski wrote:
On Wed, Feb 24, 2021 at 11:20 AM Borislav Petkov wrote:
On Wed, Feb 24, 2021 at 09:56:13AM -0800, Yu, Yu-cheng wrote:
No. Maybe I am doing too much. The GP fault sets si_addr to
On 2/24/2021 8:53 AM, Borislav Petkov wrote:
On Wed, Feb 24, 2021 at 08:44:45AM -0800, Yu, Yu-cheng wrote:
+ force_sig_fault(SIGSEGV, SEGV_CPERR,
+ (void __user *)uprobe_get_trap_addr(regs));
Why is this calling an uprobes function?
I will change it to
On 2/24/2021 8:13 AM, Borislav Petkov wrote:
On Wed, Feb 17, 2021 at 02:27:10PM -0800, Yu-cheng Yu wrote:
+/*
+ * When a control protection exception occurs, send a signal to the responsible
+ * application. Currently, control protection is only enabled for user mode.
+ * This exception should
On 2/24/2021 7:34 AM, Borislav Petkov wrote:
On Wed, Feb 17, 2021 at 02:27:09PM -0800, Yu-cheng Yu wrote:
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 546d6ecf0a35..fae6b3ea1f6d 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr
On 2/10/2021 12:28 PM, Yu, Yu-cheng wrote:
On 2/10/2021 11:42 AM, Kees Cook wrote:
On Wed, Feb 10, 2021 at 09:56:46AM -0800, Yu-cheng Yu wrote:
There is essentially no room left in the x86 hardware PTEs on some OSes
(not Linux). That left the hardware architects looking for a way to
represent
On 2/10/2021 11:58 AM, Kees Cook wrote:
On Wed, Feb 10, 2021 at 09:56:59AM -0800, Yu-cheng Yu wrote:
To deliver a signal, create a shadow stack restore token and put the token
and the signal restorer address on the shadow stack. For sigreturn, verify
the token and restore from it the shadow sta
On 2/10/2021 11:42 AM, Kees Cook wrote:
On Wed, Feb 10, 2021 at 09:56:46AM -0800, Yu-cheng Yu wrote:
There is essentially no room left in the x86 hardware PTEs on some OSes
(not Linux). That left the hardware architects looking for a way to
represent a new memory type (shadow stack) within the
On 2/10/2021 11:33 AM, Kees Cook wrote:
On Wed, Feb 10, 2021 at 09:56:40AM -0800, Yu-cheng Yu wrote:
Shadow Stack provides protection against function return address
corruption. It is active when the processor supports it, the kernel has
CONFIG_X86_CET enabled, and the application is built for
On 2/5/2021 10:41 AM, Yu, Yu-cheng wrote:
On 2/4/2021 12:27 PM, Dave Hansen wrote:
On 2/4/21 12:19 PM, Kees Cook wrote:
(e) A page where the processor observed a Write=1 PTE, started a
write, set
Dirty=1, but then observed a Write=0 PTE. That's possible
today, but
will not h
On 2/8/2021 11:48 AM, Borislav Petkov wrote:
On Mon, Feb 08, 2021 at 11:23:18AM -0800, Yu, Yu-cheng wrote:
exc_general_protection() and do_trap() both call show_signal(), which
then calls printk_ratelimit().
You could've done some git archeology and could've found
abd4f7505baf (
On 2/8/2021 10:53 AM, Borislav Petkov wrote:
On Mon, Feb 08, 2021 at 10:50:07AM -0800, Yu, Yu-cheng wrote:
I have not run into the situation. Initially it was there because other
faults have it.
Which other faults?
exc_general_protection() and do_trap() both call show_signal(), which
then
On 2/8/2021 10:20 AM, Borislav Petkov wrote:
On Fri, Feb 05, 2021 at 10:00:21AM -0800, Yu, Yu-cheng wrote:
The ratelimit here is only for #CP, and its rate is not counted together
with other types of faults. If a task gets here, it will exit. The only
condition the ratelimit will trigger is
On 2/7/2021 2:35 PM, Dave Hansen wrote:
On 2/7/21 12:44 PM, Alexei Starovoitov wrote:
It probably is an item on some Intel manager's to-enable list. So far,
the CET enablement concentrates only on userspace but dhansen might know
more about future plans. CCed.
It's definitely on our radar to lo
On 2/4/2021 12:19 PM, Kees Cook wrote:
On Wed, Feb 03, 2021 at 02:55:30PM -0800, Yu-cheng Yu wrote:
There is essentially no room left in the x86 hardware PTEs on some OSes
(not Linux). That left the hardware architects looking for a way to
represent a new memory type (shadow stack) within the e
On 2/4/2021 12:27 PM, Dave Hansen wrote:
On 2/4/21 12:19 PM, Kees Cook wrote:
(e) A page where the processor observed a Write=1 PTE, started a write, set
Dirty=1, but then observed a Write=0 PTE. That's possible today, but
will not happen on processors that support shadow stack.
What
On 2/5/2021 5:59 AM, Borislav Petkov wrote:
On Wed, Feb 03, 2021 at 02:55:28PM -0800, Yu-cheng Yu wrote:
+DEFINE_IDTENTRY_ERRORCODE(exc_control_protection)
+{
+ static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
+ DEFAULT_RATELIMIT_BURST);
+
On 2/5/2021 5:43 AM, Borislav Petkov wrote:
On Wed, Feb 03, 2021 at 02:55:26PM -0800, Yu-cheng Yu wrote:
@@ -1252,6 +1260,13 @@ static void __init cpu_parse_early_param(void)
if (cmdline_find_option_bool(boot_command_line, "noxsaves"))
setup_clear_cpu_cap(X86_FEATURE_XSAV
On 2/4/2021 12:09 PM, Kees Cook wrote:
On Wed, Feb 03, 2021 at 02:55:28PM -0800, Yu-cheng Yu wrote:
[...]
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 7f5aec758f0e..f5354c35df32 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -606,6 +606,66 @@ DEF
On 2/4/2021 11:56 AM, Kees Cook wrote:
On Wed, Feb 03, 2021 at 02:55:24PM -0800, Yu-cheng Yu wrote:
Shadow Stack provides protection against function return address
corruption. It is active when the processor supports it, the kernel has
CONFIG_X86_CET enabled, and the application is built for t
On 2/4/2021 12:35 PM, Kees Cook wrote:
On Wed, Feb 03, 2021 at 02:55:46PM -0800, Yu-cheng Yu wrote:
arch_prctl(ARCH_X86_CET_STATUS, u64 *args)
Get CET feature status.
The parameter 'args' is a pointer to a user buffer. The kernel returns
the following information:
*args =
On 2/4/2021 12:46 PM, Cyrill Gorcunov wrote:
On Wed, Feb 03, 2021 at 02:55:34PM -0800, Yu-cheng Yu wrote:
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 602e3a52884d..59623dcd92bb 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -661,6 +661,9 @@ static void show_smap_vm
On 2/4/2021 11:52 AM, Kees Cook wrote:
On Wed, Feb 03, 2021 at 02:55:23PM -0800, Yu-cheng Yu wrote:
Explain no_user_shstk/no_user_ibt kernel parameters, and introduce a new
document on Control-flow Enforcement Technology (CET).
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
Thanks for
On 2/3/2021 2:11 PM, Dave Hansen wrote:
On 2/3/21 1:54 PM, Yu, Yu-cheng wrote:
On 1/29/2021 10:56 AM, Yu, Yu-cheng wrote:
On 1/29/2021 9:07 AM, Dave Hansen wrote:
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
+ if (!IS_ENABLED(CONFIG_X86_CET))
+ return -EOPNOTSUPP;
Let's ignore
On 1/29/2021 10:56 AM, Yu, Yu-cheng wrote:
On 1/29/2021 9:07 AM, Dave Hansen wrote:
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
arch_prctl(ARCH_X86_CET_STATUS, u64 *args)
Get CET feature status.
The parameter 'args' is a pointer to a user buffer. The kernel
returns
the
On 2/1/2021 3:12 PM, Dave Hansen wrote:
On 2/1/21 3:05 PM, Yu, Yu-cheng wrote:
Wait a sec... What about *THIS* series? Will *THIS* series give us
oopses when userspace blasts a new XSAVE buffer in with NT_X86_XSTATE?
Fortunately, CET states are supervisor states. NT_x86_XSTATE has only
On 2/1/2021 2:59 PM, Dave Hansen wrote:
On 2/1/21 2:43 PM, Yu, Yu-cheng wrote:
On 1/29/2021 2:53 PM, Dave Hansen wrote:
On 1/29/21 2:35 PM, Yu, Yu-cheng wrote:
Andy Cooper just mentioned on IRC about this nugget in the spec:
XRSTORS on CET state will do reserved bit and canonicality
On 2/1/2021 2:53 PM, Dave Hansen wrote:
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
To deliver a signal, create a shadow stack restore token and put a restore
token and the signal restorer address on the shadow stack. For sigreturn,
verify the token and restore the shadow stack pointer.
Introduce W
On 1/29/2021 2:53 PM, Dave Hansen wrote:
On 1/29/21 2:35 PM, Yu, Yu-cheng wrote:
Andy Cooper just mentioned on IRC about this nugget in the spec:
XRSTORS on CET state will do reserved bit and canonicality
checks on the state in similar manner as done by the WRMSR to
these state
On 1/29/2021 1:00 PM, Dave Hansen wrote:
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
@@ -135,6 +135,8 @@ enum xfeature {
#define XFEATURE_MASK_PT (1 << XFEATURE_PT_UNIMPLEMENTED_SO_FAR)
#define XFEATURE_MASK_PKRU(1 << XFEATURE_PKRU)
#define XFEATURE_MASK_PASID
On 1/29/2021 12:46 PM, Borislav Petkov wrote:
On Fri, Jan 29, 2021 at 12:33:43PM -0800, Dave Hansen wrote:
In that case is there any reason to keep the "depends on CPU_SUP_INTEL"?
Probably not. I haven't heard of the AMD implementation being somehow
different from Intel's.
Ok, I will remove
On 1/29/2021 11:42 AM, Dave Hansen wrote:
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
+ help
+ Control-flow protection is a hardware security hardening feature
+ that detects function-return address or jump target changes by
+ malicious code.
It's not really one featur
On 1/29/2021 11:15 AM, Dave Hansen wrote:
On 1/29/21 10:56 AM, Yu, Yu-cheng wrote:
On 1/29/2021 9:07 AM, Dave Hansen wrote:
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
[...]
What's the point of doing copy_status_to_user() if the processor doesn't
support CET? In other words, shouldn
On 1/29/2021 9:07 AM, Dave Hansen wrote:
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
arch_prctl(ARCH_X86_CET_STATUS, u64 *args)
Get CET feature status.
The parameter 'args' is a pointer to a user buffer. The kernel returns
the following information:
*args = shadow stack/IBT sta
On 1/26/2021 1:40 AM, Peter Zijlstra wrote:
On Tue, Jan 26, 2021 at 09:46:36AM +0100, Peter Zijlstra wrote:
On Mon, Jan 25, 2021 at 07:27:09PM +0100, Borislav Petkov wrote:
+ pte_t old_pte, new_pte;
+
+ do {
+ old_pte = READ_ONCE(*ptep);
+
On 1/26/2021 2:24 AM, Borislav Petkov wrote:
On Mon, Jan 25, 2021 at 02:18:37PM -0800, Yu, Yu-cheng wrote:
For example, when a thread reads a W=1, D=0 PTE and before changing it to
W=0,D=0, another thread could have written to the page and the PTE is W=1,
D=1 now. When try_cmpxchg() detects
On 1/25/2021 1:55 PM, Borislav Petkov wrote:
On Mon, Jan 25, 2021 at 01:27:51PM -0800, Yu, Yu-cheng wrote:
Maybe I'm missing something but those two can happen outside of the
loop, no? Or is *ptep somehow changing concurrently while the loop is
doing the CMPXCHG and you need to recreate it
On 1/25/2021 10:27 AM, Borislav Petkov wrote:
On Tue, Dec 29, 2020 at 01:30:38PM -0800, Yu-cheng Yu wrote:
[...]
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 666c25ab9564..1c84f1ba32b9 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm
On 1/21/2021 2:32 PM, David Laight wrote:
From: Randy Dunlap
Sent: 21 January 2021 22:19
On 1/21/21 2:16 PM, David Laight wrote:
From: Yu, Yu-cheng
On 1/21/2021 10:44 AM, Borislav Petkov wrote:
On Tue, Dec 29, 2020 at 01:30:35PM -0800, Yu-cheng Yu wrote:
[...]
@@ -343,6 +349,16 @@ static
On 1/21/2021 12:41 PM, Borislav Petkov wrote:
On Thu, Jan 21, 2021 at 12:16:23PM -0800, Yu, Yu-cheng wrote:
It clears _PAGE_DIRTY and sets _PAGE_COW. That is,
if (pte.pte & _PAGE_DIRTY) {
pte.pte &= ~_PAGE_DIRTY;
pte.pte |= _PAGE_COW;
}
So, shifting makes resulting c
On 1/21/2021 12:26 PM, Dave Hansen wrote:
Usually, the compiler is better at making code efficient than humans. I
find that coding it in the most human-readable way is best unless I
*know* the compiler is unable to generate god code.
"good code", even.
I really want a "god code" compiler, tho
On 1/21/2021 10:44 AM, Borislav Petkov wrote:
On Tue, Dec 29, 2020 at 01:30:35PM -0800, Yu-cheng Yu wrote:
[...]
@@ -343,6 +349,16 @@ static inline pte_t pte_mkold(pte_t pte)
static inline pte_t pte_wrprotect(pte_t pte)
{
+ /*
+* Blindly clearing _PAGE_RW might accidentall
On 1/19/2021 4:04 AM, Borislav Petkov wrote:
On Tue, Dec 29, 2020 at 01:30:33PM -0800, Yu-cheng Yu wrote:
[...]
+DEFINE_IDTENTRY_ERRORCODE(exc_control_protection)
+{
+ struct task_struct *tsk;
+
+ if (!user_mode(regs)) {
+ if (notify_die(DIE_TRAP, "control protection f
On 1/19/2021 3:06 AM, Borislav Petkov wrote:
On Tue, Dec 29, 2020 at 01:30:29PM -0800, Yu-cheng Yu wrote:
Shadow Stack provides protection against function return address
corruption. It is active when the processor supports it, the kernel has
CONFIG_X86_CET_USER enabled, and the application is
On 1/12/2021 4:38 AM, Borislav Petkov wrote:
On Mon, Jan 11, 2021 at 03:09:00PM -0800, Yu-cheng Yu wrote:
@@ -1252,6 +1260,16 @@ static void __init cpu_parse_early_param(void)
if (cmdline_find_option_bool(boot_command_line, "noxsaves"))
setup_clear_cpu_cap(X86_FEATURE_XSA
This is a minor revision of the original [PATCH v17 04/26] patch. The
purpose of the revision is to address Boris' comment earlier by doing
setup_force_cpu_cap(X86_FEATURE_CET) in bsp_init_intel().
--
Yu-cheng
On 1/11/2021 9:56 AM, Borislav Petkov wrote:
On Tue, Dec 29, 2020 at 01:30:31PM -0800, Yu-cheng Yu wrote:
@@ -895,6 +903,12 @@ static void init_speculation_control(struct cpuinfo_x86 *c)
}
}
+static void init_cet_features(struct cpuinfo_x86 *c)
+{
+ if (cpu_has(c, X86_FEATURE
On 12/29/2020 1:30 PM, Yu-cheng Yu wrote:
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This s
On 12/29/2020 10:54 AM, Borislav Petkov wrote:
On Tue, Dec 29, 2020 at 08:34:51AM -0800, Yu, Yu-cheng wrote:
Thanks! I will re-base to v5.11-rc1 and send out a new version.
You don't have to if it still applies and there are no changes pending.
There are some small conflicts, so I
On 12/29/2020 4:39 AM, Borislav Petkov wrote:
On Wed, Dec 09, 2020 at 02:22:56PM -0800, Yu-cheng Yu wrote:
Shadow Stack provides protection against function return address
corruption. It is active when the processor supports it, the kernel has
CONFIG_X86_CET_USER, and the application is built f
On 12/10/2020 9:41 AM, Borislav Petkov wrote:
On Tue, Dec 08, 2020 at 11:24:16AM -0800, Yu, Yu-cheng wrote:
Case (a) is a normal writable data page that has gone through fork(). So it
Writable >
has W=0, D=1. But here, the software chooses not to use the D bit, and
But it has W=0. So
On 12/8/2020 10:47 AM, Borislav Petkov wrote:
On Tue, Dec 08, 2020 at 10:25:15AM -0800, Yu, Yu-cheng wrote:
Both are "R/O + _PAGE_COW". Where's the difference? The dirty bit?
The PTEs are the same for both (a) and (b), but come from different routes.
Do not be afraid to go
On 12/8/2020 9:50 AM, Borislav Petkov wrote:
On Tue, Nov 10, 2020 at 08:21:53AM -0800, Yu-cheng Yu wrote:
There is essentially no room left in the x86 hardware PTEs on some OSes
(not Linux). That left the hardware architects looking for a way to
represent a new memory type (shadow stack) within
On 12/7/2020 8:36 AM, Borislav Petkov wrote:
On Tue, Nov 10, 2020 at 08:21:52AM -0800, Yu-cheng Yu wrote:
Kernel read-only PTEs are setup as _PAGE_DIRTY_HW. Since these become
shadow stack PTEs, remove the dirty bit.
This commit message is laconic to say the least. You need to start
explainin
On 12/3/2020 7:12 AM, Dave Hansen wrote:
On 12/3/20 1:19 AM, Borislav Petkov wrote:
On Tue, Nov 10, 2020 at 08:21:51AM -0800, Yu-cheng Yu wrote:
Before introducing _PAGE_COW for non-hardware memory management purposes in
the next patch, rename _PAGE_DIRTY to _PAGE_DIRTY_HW and _PAGE_BIT_DIRTY t
On 12/1/2020 2:26 PM, Dave Hansen wrote:
On 11/30/20 3:16 PM, Yu, Yu-cheng wrote:
Do we have any other spots in the kernel where we care about:
boot_cpu_has(X86_FEATURE_SHSTK) ||
boot_cpu_has(X86_FEATURE_IBT)
? If so, we could also address this by declaring a software-defined
On 11/30/2020 9:45 AM, Dave Hansen wrote:
On 11/10/20 8:21 AM, Yu-cheng Yu wrote:
Control-flow Enforcement Technology (CET) adds five MSRs. Introduce
them and their XSAVES supervisor states:
MSR_IA32_U_CET (user-mode CET settings),
MSR_IA32_PL3_SSP (user-mode Shadow Stack pointer),
On 11/30/2020 10:15 AM, Borislav Petkov wrote:
On Sat, Nov 28, 2020 at 08:23:59AM -0800, Yu, Yu-cheng wrote:
We have X86_BRANCH_TRACKING_USER too. My thought was, X86_CET means any of
kernel/user shadow stack/ibt.
It is not about what it means - it is what you're going to use/need. You
On 11/30/2020 11:56 AM, Nick Desaulniers wrote:
In response to
https://lore.kernel.org/lkml/20201110162211.9207-6-yu-cheng...@intel.com/.
Hi Yu-cheng,
This feature reminds me very much of
ARCH_SUPPORTS_SHADOW_CALL_STACK/CC_HAVE_SHADOW_CALL_STACK implemented in
https://git.kernel.org/pub/scm/lin
On 11/30/2020 11:38 AM, Fāng-ruì Sòng wrote:
On Mon, Nov 30, 2020 at 10:34 AM Yu, Yu-cheng wrote:
On 11/30/2020 10:26 AM, Nick Desaulniers wrote:
(In response to
https://lore.kernel.org/lkml/20201110162211.9207-2-yu-cheng...@intel.com/)
These need to be enabled to build a CET-enabled
On 11/30/2020 10:26 AM, Nick Desaulniers wrote:
(In response to
https://lore.kernel.org/lkml/20201110162211.9207-2-yu-cheng...@intel.com/)
These need to be enabled to build a CET-enabled kernel, and Binutils v2.31
and GCC v8.1 or later are required to build a CET kernel.
What about LLVM? Sur
On 11/30/2020 10:12 AM, Dave Hansen wrote:
On 11/30/20 10:06 AM, Yu, Yu-cheng wrote:
+ if (!boot_cpu_has(X86_FEATURE_SHSTK) &&
+ !boot_cpu_has(X86_FEATURE_IBT))
+ xfeatures_mask_all &= ~BIT_ULL(i);
+ } else {
+ if ((xsave_cp
On 11/30/2020 9:45 AM, Dave Hansen wrote:
On 11/10/20 8:21 AM, Yu-cheng Yu wrote:
Control-flow Enforcement Technology (CET) adds five MSRs. Introduce
them and their XSAVES supervisor states:
MSR_IA32_U_CET (user-mode CET settings),
MSR_IA32_PL3_SSP (user-mode Shadow Stack pointer),
On 11/27/2020 9:10 AM, Borislav Petkov wrote:
On Tue, Nov 10, 2020 at 08:21:50AM -0800, Yu-cheng Yu wrote:
+config X86_CET
+ def_bool n
+
+config ARCH_HAS_SHADOW_STACK
+ def_bool n
+
+config X86_SHADOW_STACK_USER
Is X86_SHADOW_STACK_KERNEL coming too?
Regardless, you can add it wh
On 11/27/2020 1:29 AM, Balbir Singh wrote:
On Tue, Nov 10, 2020 at 08:21:45AM -0800, Yu-cheng Yu wrote:
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Man
On 11/6/2020 12:11 PM, Borislav Petkov wrote:
On Fri, Nov 06, 2020 at 11:48:26AM -0800, Yu, Yu-cheng wrote:
I will drop it. It has been re-based many times, and probably I
accidentally introduced something else?
Yah, I think I added my tag to this version:
https://lkml.kernel.org/lkml
On 11/6/2020 10:49 AM, Borislav Petkov wrote:
On Mon, Oct 12, 2020 at 08:38:26AM -0700, Yu-cheng Yu wrote:
Add CPU feature flags for Control-flow Enforcement Technology (CET).
CPUID.(EAX=7,ECX=0):ECX[bit 7] Shadow stack
CPUID.(EAX=7,ECX=0):EDX[bit 20] Indirect Branch Tracking
Signed-off-by: Yu
On 11/6/2020 10:28 AM, Borislav Petkov wrote:
On Fri, Nov 06, 2020 at 10:16:47AM -0800, Yu, Yu-cheng wrote:
In the current shell, if GLIBC_TUNABLES variable is set as such,
applications started will have CET features disabled. I can put more
details here, or maybe a reference to the GLIBC man
On 11/6/2020 9:34 AM, Borislav Petkov wrote:
On Mon, Oct 12, 2020 at 08:38:25AM -0700, Yu-cheng Yu wrote:
+[1] Overview
+
+
+Control-flow Enforcement Technology (CET) is an Intel processor feature
+that provides protection against return/jump-oriented programming (ROP)
+attacks. It
On 10/12/2020 12:58 PM, Cyrill Gorcunov wrote:
On Mon, Oct 12, 2020 at 08:38:27AM -0700, Yu-cheng Yu wrote:
...
/*
* x86-64 Task Priority Register, CR8
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 038e19c0019e..705fd9b94e31 100644
--- a/arch/x86/kernel/fpu/
On 10/12/2020 12:15 PM, Cyrill Gorcunov wrote:
On Mon, Oct 12, 2020 at 08:45:24AM -0700, Yu-cheng Yu wrote:
...
+ the application support it. When this feature is enabled,
+ legacy non-IBT applications continue to work, but without
+ IBT protection.
+ Support for
On 10/9/2020 11:32 AM, Yu-cheng Yu wrote:
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
[...]
Hi,
The series did not get send out complet
1 - 100 of 147 matches
Mail list logo
