From: Dave Hansen <dave.hansen@linux.intel.com>
To: Yu-cheng Yu <yu-cheng.yu@intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Andy Lutomirski <luto@amacapital.net>,
Balbir Singh <bsingharora@gmail.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
"H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Kees Cook <keescook@chromiun.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Nadav Amit <nadav.amit@gmail.com>,
Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>,
Peter Zijlstra <peterz@infradead.org>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>
Subject: Re: [RFC PATCH v2 22/27] x86/cet/ibt: User-mode indirect branch tracking support
Date: Wed, 11 Jul 2018 16:16:44 -0700 [thread overview]
Message-ID: <25675609-9ea7-55fb-6e73-b4a4c49b6c35@linux.intel.com> (raw)
In-Reply-To: <1531350028.15351.102.camel@intel.com>
On 07/11/2018 04:00 PM, Yu-cheng Yu wrote:
> On Wed, 2018-07-11 at 15:40 -0700, Dave Hansen wrote:
>> On 07/11/2018 03:10 PM, Yu-cheng Yu wrote:
>>>
>>> On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:
>>>>
>>>> Is this feature *integral* to shadow stacks? Or, should it just
>>>> be
>>>> in a
>>>> different series?
>>> The whole CET series is mostly about SHSTK and only a minority for
>>> IBT.
>>> IBT changes cannot be applied by itself without first applying
>>> SHSTK
>>> changes. Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk,
>>> etc.?
>> That doesn't really answer what I asked, though.
>>
>> Do shadow stacks *require* IBT? Or, should we concentrate on merging
>> shadow stacks themselves first and then do IBT at a later time, in a
>> different patch series?
>>
>> But, yes, better patch titles would help, although I'm not sure
>> that's
>> quite the format that Ingo and Thomas prefer.
>
> Shadow stack does not require IBT, but they complement each other. If
> we can resolve the legacy bitmap, both features can be merged at the
> same time.
As large as this patch set is, I'd really prefer to see you get shadow
stacks merged and then move on to IBT. I say separate them.
> GLIBC does the bitmap setup. It sets bits in there.
> I thought you wanted a smaller bitmap? One way is forcing legacy libs
> to low address, or not having the bitmap at all, i.e. turn IBT off.
I'm concerned with two things:
1. the virtual address space consumption, especially the *default* case
which will be apps using 4-level address space amounts, but having
5-level-sized tables.
2. the driving a truck-sized hole in the address space limits
You can force legacy libs to low addresses, but you can't stop anyone
from putting code into a high address *later*, at least with the code we
have today.
>>>>> + rdmsrl(MSR_IA32_U_CET, r);
>>>>> + r &= ~(MSR_IA32_CET_ENDBR_EN | MSR_IA32_CET_LEG_IW_EN
>>>>> |
>>>>> + MSR_IA32_CET_NO_TRACK_EN);
>>>>> + wrmsrl(MSR_IA32_U_CET, r);
>>>>> + current->thread.cet.ibt_enabled = 0;
>>>>> +}
>>>> What's the locking for current->thread.cet?
>>> Now CET is not locked until the application calls ARCH_CET_LOCK.
>> No, I mean what is the in-kernel locking for the current->thread.cet
>> data structure? Is there none because it's only every modified via
>> current->thread and it's entirely thread-local?
>
> Yes, that is the case.
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@linux.intel.com>
To: Yu-cheng Yu <yu-cheng.yu@intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Andy Lutomirski <luto@amacapital.net>,
Balbir Singh <bsingharora@gmail.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
"H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Kees Cook <keescook@chromiun.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Nadav Amit <nadav.amit@gmail.com>,
Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>,
Peter Zijlstra <peterz@infradead.org>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>
Subject: Re: [RFC PATCH v2 22/27] x86/cet/ibt: User-mode indirect branch tracking support
Date: Wed, 11 Jul 2018 16:16:44 -0700 [thread overview]
Message-ID: <25675609-9ea7-55fb-6e73-b4a4c49b6c35@linux.intel.com> (raw)
In-Reply-To: <1531350028.15351.102.camel@intel.com>
On 07/11/2018 04:00 PM, Yu-cheng Yu wrote:
> On Wed, 2018-07-11 at 15:40 -0700, Dave Hansen wrote:
>> On 07/11/2018 03:10 PM, Yu-cheng Yu wrote:
>>>
>>> On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:
>>>>
>>>> Is this feature *integral* to shadow stacks? Or, should it just
>>>> be
>>>> in a
>>>> different series?
>>> The whole CET series is mostly about SHSTK and only a minority for
>>> IBT.
>>> IBT changes cannot be applied by itself without first applying
>>> SHSTK
>>> changes. Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk,
>>> etc.?
>> That doesn't really answer what I asked, though.
>>
>> Do shadow stacks *require* IBT? Or, should we concentrate on merging
>> shadow stacks themselves first and then do IBT at a later time, in a
>> different patch series?
>>
>> But, yes, better patch titles would help, although I'm not sure
>> that's
>> quite the format that Ingo and Thomas prefer.
>
> Shadow stack does not require IBT, but they complement each other. If
> we can resolve the legacy bitmap, both features can be merged at the
> same time.
As large as this patch set is, I'd really prefer to see you get shadow
stacks merged and then move on to IBT. I say separate them.
> GLIBC does the bitmap setup. It sets bits in there.
> I thought you wanted a smaller bitmap? One way is forcing legacy libs
> to low address, or not having the bitmap at all, i.e. turn IBT off.
I'm concerned with two things:
1. the virtual address space consumption, especially the *default* case
which will be apps using 4-level address space amounts, but having
5-level-sized tables.
2. the driving a truck-sized hole in the address space limits
You can force legacy libs to low addresses, but you can't stop anyone
from putting code into a high address *later*, at least with the code we
have today.
>>>>> + rdmsrl(MSR_IA32_U_CET, r);
>>>>> + r &= ~(MSR_IA32_CET_ENDBR_EN | MSR_IA32_CET_LEG_IW_EN
>>>>> |
>>>>> + MSR_IA32_CET_NO_TRACK_EN);
>>>>> + wrmsrl(MSR_IA32_U_CET, r);
>>>>> + current->thread.cet.ibt_enabled = 0;
>>>>> +}
>>>> What's the locking for current->thread.cet?
>>> Now CET is not locked until the application calls ARCH_CET_LOCK.
>> No, I mean what is the in-kernel locking for the current->thread.cet
>> data structure? Is there none because it's only every modified via
>> current->thread and it's entirely thread-local?
>
> Yes, that is the case.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@linux.intel.com>
To: Yu-cheng Yu <yu-cheng.yu@intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Andy Lutomirski <luto@amacapital.net>,
Balbir Singh <bsingharora@gmail.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
"H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Kees Cook <keescook@chromiun.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Nadav Amit <nadav.amit@gmail.com>,
Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>,
Peter Zijlstra <pet>
Subject: Re: [RFC PATCH v2 22/27] x86/cet/ibt: User-mode indirect branch tracking support
Date: Wed, 11 Jul 2018 16:16:44 -0700 [thread overview]
Message-ID: <25675609-9ea7-55fb-6e73-b4a4c49b6c35@linux.intel.com> (raw)
In-Reply-To: <1531350028.15351.102.camel@intel.com>
On 07/11/2018 04:00 PM, Yu-cheng Yu wrote:
> On Wed, 2018-07-11 at 15:40 -0700, Dave Hansen wrote:
>> On 07/11/2018 03:10 PM, Yu-cheng Yu wrote:
>>>
>>> On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:
>>>>
>>>> Is this feature *integral* to shadow stacks? Or, should it just
>>>> be
>>>> in a
>>>> different series?
>>> The whole CET series is mostly about SHSTK and only a minority for
>>> IBT.
>>> IBT changes cannot be applied by itself without first applying
>>> SHSTK
>>> changes. Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk,
>>> etc.?
>> That doesn't really answer what I asked, though.
>>
>> Do shadow stacks *require* IBT? Or, should we concentrate on merging
>> shadow stacks themselves first and then do IBT at a later time, in a
>> different patch series?
>>
>> But, yes, better patch titles would help, although I'm not sure
>> that's
>> quite the format that Ingo and Thomas prefer.
>
> Shadow stack does not require IBT, but they complement each other. If
> we can resolve the legacy bitmap, both features can be merged at the
> same time.
As large as this patch set is, I'd really prefer to see you get shadow
stacks merged and then move on to IBT. I say separate them.
> GLIBC does the bitmap setup. It sets bits in there.
> I thought you wanted a smaller bitmap? One way is forcing legacy libs
> to low address, or not having the bitmap at all, i.e. turn IBT off.
I'm concerned with two things:
1. the virtual address space consumption, especially the *default* case
which will be apps using 4-level address space amounts, but having
5-level-sized tables.
2. the driving a truck-sized hole in the address space limits
You can force legacy libs to low addresses, but you can't stop anyone
from putting code into a high address *later*, at least with the code we
have today.
>>>>> + rdmsrl(MSR_IA32_U_CET, r);
>>>>> + r &= ~(MSR_IA32_CET_ENDBR_EN | MSR_IA32_CET_LEG_IW_EN
>>>>> |
>>>>> + MSR_IA32_CET_NO_TRACK_EN);
>>>>> + wrmsrl(MSR_IA32_U_CET, r);
>>>>> + current->thread.cet.ibt_enabled = 0;
>>>>> +}
>>>> What's the locking for current->thread.cet?
>>> Now CET is not locked until the application calls ARCH_CET_LOCK.
>> No, I mean what is the in-kernel locking for the current->thread.cet
>> data structure? Is there none because it's only every modified via
>> current->thread and it's entirely thread-local?
>
> Yes, that is the case.
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@linux.intel.com>
To: Yu-cheng Yu <yu-cheng.yu@intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Andy Lutomirski <luto@amacapital.net>,
Balbir Singh <bsingharora@gmail.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
"H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Kees Cook <keescook@chromiun.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Nadav Amit <nadav.amit@gmail.com>,
Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>,
Peter Zijlstra <peterz@infradead.org>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>
Subject: Re: [RFC PATCH v2 22/27] x86/cet/ibt: User-mode indirect branch tracking support
Date: Wed, 11 Jul 2018 16:16:44 -0700 [thread overview]
Message-ID: <25675609-9ea7-55fb-6e73-b4a4c49b6c35@linux.intel.com> (raw)
In-Reply-To: <1531350028.15351.102.camel@intel.com>
On 07/11/2018 04:00 PM, Yu-cheng Yu wrote:
> On Wed, 2018-07-11 at 15:40 -0700, Dave Hansen wrote:
>> On 07/11/2018 03:10 PM, Yu-cheng Yu wrote:
>>>
>>> On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:
>>>>
>>>> Is this feature *integral* to shadow stacks?A A Or, should it just
>>>> be
>>>> in a
>>>> different series?
>>> The whole CET series is mostly about SHSTK and only a minority for
>>> IBT.
>>> IBT changes cannot be applied by itself without first applying
>>> SHSTK
>>> changes. A Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk,
>>> etc.?
>> That doesn't really answer what I asked, though.
>>
>> Do shadow stacks *require* IBT?A A Or, should we concentrate on merging
>> shadow stacks themselves first and then do IBT at a later time, in a
>> different patch series?
>>
>> But, yes, better patch titles would help, although I'm not sure
>> that's
>> quite the format that Ingo and Thomas prefer.
>
> Shadow stack does not require IBT, but they complement each other. A If
> we can resolve the legacy bitmap, both features can be merged at the
> same time.
As large as this patch set is, I'd really prefer to see you get shadow
stacks merged and then move on to IBT. I say separate them.
> GLIBC does the bitmap setup. A It sets bits in there.
> I thought you wanted a smaller bitmap? A One way is forcing legacy libs
> to low address, or not having the bitmap at all, i.e. turn IBT off.
I'm concerned with two things:
1. the virtual address space consumption, especially the *default* case
which will be apps using 4-level address space amounts, but having
5-level-sized tables.
2. the driving a truck-sized hole in the address space limits
You can force legacy libs to low addresses, but you can't stop anyone
from putting code into a high address *later*, at least with the code we
have today.
>>>>> + rdmsrl(MSR_IA32_U_CET, r);
>>>>> + r &= ~(MSR_IA32_CET_ENDBR_EN | MSR_IA32_CET_LEG_IW_EN
>>>>> |
>>>>> + A A A A A A A MSR_IA32_CET_NO_TRACK_EN);
>>>>> + wrmsrl(MSR_IA32_U_CET, r);
>>>>> + current->thread.cet.ibt_enabled = 0;
>>>>> +}
>>>> What's the locking for current->thread.cet?
>>> Now CET is not locked until the application callsA ARCH_CET_LOCK.
>> No, I mean what is the in-kernel locking for the current->thread.cet
>> data structure?A A Is there none because it's only every modified via
>> current->thread and it's entirely thread-local?
>
> Yes, that is the case.
next prev parent reply other threads:[~2018-07-11 23:16 UTC|newest]
Thread overview: 413+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-10 22:26 [RFC PATCH v2 00/27] Control Flow Enforcement (CET) Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 01/27] x86/cpufeatures: Add CPUIDs for Control-flow Enforcement Technology (CET) Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 02/27] x86/fpu/xstate: Change some names to separate XSAVES system and user states Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 03/27] x86/fpu/xstate: Enable XSAVES system states Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 04/27] x86/fpu/xstate: Add XSAVES system states for shadow stack Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 05/27] Documentation/x86: Add CET description Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 8:27 ` Pavel Machek
2018-07-11 8:27 ` Pavel Machek
2018-07-11 15:25 ` Yu-cheng Yu
2018-07-11 15:25 ` Yu-cheng Yu
2018-07-11 15:25 ` Yu-cheng Yu
2018-07-11 15:25 ` Yu-cheng Yu
2018-07-11 9:57 ` Florian Weimer
2018-07-11 9:57 ` Florian Weimer
2018-07-11 9:57 ` Florian Weimer
2018-07-11 13:47 ` H.J. Lu
2018-07-11 13:47 ` H.J. Lu
2018-07-11 13:47 ` H.J. Lu
2018-07-11 14:53 ` Yu-cheng Yu
2018-07-11 14:53 ` Yu-cheng Yu
2018-07-11 14:53 ` Yu-cheng Yu
2018-07-11 14:53 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 06/27] x86/cet: Control protection exception handler Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 07/27] x86/cet/shstk: Add Kconfig option for user-mode shadow stack Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 08/27] mm: Introduce VM_SHSTK for shadow stack memory Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 8:34 ` Peter Zijlstra
2018-07-11 8:34 ` Peter Zijlstra
2018-07-11 8:34 ` Peter Zijlstra
2018-07-11 16:15 ` Yu-cheng Yu
2018-07-11 16:15 ` Yu-cheng Yu
2018-07-11 16:15 ` Yu-cheng Yu
2018-07-11 16:15 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 09/27] x86/mm: Change _PAGE_DIRTY to _PAGE_DIRTY_HW Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 10/27] x86/mm: Introduce _PAGE_DIRTY_SW Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 8:45 ` Peter Zijlstra
2018-07-11 8:45 ` Peter Zijlstra
2018-07-11 8:45 ` Peter Zijlstra
2018-07-11 9:21 ` Peter Zijlstra
2018-07-11 9:21 ` Peter Zijlstra
2018-07-11 9:21 ` Peter Zijlstra
2018-07-10 22:26 ` [RFC PATCH v2 11/27] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:44 ` Dave Hansen
2018-07-10 22:44 ` Dave Hansen
2018-07-10 22:44 ` Dave Hansen
2018-07-10 23:23 ` Nadav Amit
2018-07-10 23:23 ` Nadav Amit
2018-07-10 23:23 ` Nadav Amit
2018-07-10 23:23 ` Nadav Amit
2018-07-10 23:52 ` Dave Hansen
2018-07-10 23:52 ` Dave Hansen
2018-07-10 23:52 ` Dave Hansen
2018-07-11 8:48 ` Peter Zijlstra
2018-07-11 8:48 ` Peter Zijlstra
2018-07-11 8:48 ` Peter Zijlstra
2018-07-10 22:26 ` [RFC PATCH v2 12/27] x86/mm: Shadow stack page fault error checking Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:52 ` Dave Hansen
2018-07-10 22:52 ` Dave Hansen
2018-07-10 22:52 ` Dave Hansen
2018-07-11 17:28 ` Yu-cheng Yu
2018-07-11 17:28 ` Yu-cheng Yu
2018-07-11 17:28 ` Yu-cheng Yu
2018-07-11 17:28 ` Yu-cheng Yu
2018-07-10 23:24 ` Dave Hansen
2018-07-10 23:24 ` Dave Hansen
2018-07-10 23:24 ` Dave Hansen
2018-07-10 22:26 ` [RFC PATCH v2 13/27] mm: Handle shadow stack page fault Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:06 ` Dave Hansen
2018-07-10 23:06 ` Dave Hansen
2018-07-10 23:06 ` Dave Hansen
2018-07-11 9:06 ` Peter Zijlstra
2018-07-11 9:06 ` Peter Zijlstra
2018-07-11 9:06 ` Peter Zijlstra
2018-08-14 21:28 ` Yu-cheng Yu
2018-08-14 21:28 ` Yu-cheng Yu
2018-08-14 21:28 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 14/27] mm: Handle THP/HugeTLB " Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:08 ` Dave Hansen
2018-07-10 23:08 ` Dave Hansen
2018-07-10 23:08 ` Dave Hansen
2018-07-11 9:10 ` Peter Zijlstra
2018-07-11 9:10 ` Peter Zijlstra
2018-07-11 9:10 ` Peter Zijlstra
2018-07-11 16:11 ` Yu-cheng Yu
2018-07-11 16:11 ` Yu-cheng Yu
2018-07-11 16:11 ` Yu-cheng Yu
2018-07-11 16:11 ` Yu-cheng Yu
2018-07-20 14:20 ` Dave Hansen
2018-07-20 14:20 ` Dave Hansen
2018-07-20 14:20 ` Dave Hansen
2018-07-20 14:58 ` Yu-cheng Yu
2018-07-20 14:58 ` Yu-cheng Yu
2018-07-20 14:58 ` Yu-cheng Yu
2018-07-20 14:58 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 15/27] mm/mprotect: Prevent mprotect from changing shadow stack Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:10 ` Dave Hansen
2018-07-10 23:10 ` Dave Hansen
2018-07-10 23:10 ` Dave Hansen
2018-07-11 9:12 ` Peter Zijlstra
2018-07-11 9:12 ` Peter Zijlstra
2018-07-11 9:12 ` Peter Zijlstra
2018-07-11 16:07 ` Yu-cheng Yu
2018-07-11 16:07 ` Yu-cheng Yu
2018-07-11 16:07 ` Yu-cheng Yu
2018-07-11 16:07 ` Yu-cheng Yu
2018-07-11 16:22 ` Dave Hansen
2018-07-11 16:22 ` Dave Hansen
2018-07-11 16:22 ` Dave Hansen
2018-07-11 16:22 ` Dave Hansen
2018-07-10 22:26 ` [RFC PATCH v2 16/27] mm: Modify can_follow_write_pte/pmd for " Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:37 ` Dave Hansen
2018-07-10 23:37 ` Dave Hansen
2018-07-10 23:37 ` Dave Hansen
2018-07-11 17:05 ` Yu-cheng Yu
2018-07-11 17:05 ` Yu-cheng Yu
2018-07-11 17:05 ` Yu-cheng Yu
2018-07-11 17:05 ` Yu-cheng Yu
2018-07-13 18:26 ` Dave Hansen
2018-07-13 18:26 ` Dave Hansen
2018-07-13 18:26 ` Dave Hansen
2018-07-13 18:26 ` Dave Hansen
2018-07-17 23:03 ` Yu-cheng Yu
2018-07-17 23:03 ` Yu-cheng Yu
2018-07-17 23:03 ` Yu-cheng Yu
2018-07-17 23:03 ` Yu-cheng Yu
2018-07-17 23:11 ` Dave Hansen
2018-07-17 23:11 ` Dave Hansen
2018-07-17 23:11 ` Dave Hansen
2018-07-17 23:11 ` Dave Hansen
2018-07-17 23:15 ` Dave Hansen
2018-07-17 23:15 ` Dave Hansen
2018-07-17 23:15 ` Dave Hansen
2018-07-18 20:14 ` Yu-cheng Yu
2018-07-18 20:14 ` Yu-cheng Yu
2018-07-18 20:14 ` Yu-cheng Yu
2018-07-18 20:14 ` Yu-cheng Yu
2018-07-18 21:45 ` Dave Hansen
2018-07-18 21:45 ` Dave Hansen
2018-07-18 21:45 ` Dave Hansen
2018-07-18 21:45 ` Dave Hansen
2018-07-18 23:10 ` Yu-cheng Yu
2018-07-18 23:10 ` Yu-cheng Yu
2018-07-18 23:10 ` Yu-cheng Yu
2018-07-18 23:10 ` Yu-cheng Yu
2018-07-19 0:06 ` Dave Hansen
2018-07-19 0:06 ` Dave Hansen
2018-07-19 0:06 ` Dave Hansen
2018-07-19 0:06 ` Dave Hansen
2018-07-19 17:06 ` Yu-cheng Yu
2018-07-19 17:06 ` Yu-cheng Yu
2018-07-19 17:06 ` Yu-cheng Yu
2018-07-19 17:06 ` Yu-cheng Yu
2018-07-19 19:31 ` Dave Hansen
2018-07-19 19:31 ` Dave Hansen
2018-07-19 19:31 ` Dave Hansen
2018-07-11 9:29 ` Peter Zijlstra
2018-07-11 9:29 ` Peter Zijlstra
2018-07-11 9:29 ` Peter Zijlstra
2018-07-17 23:00 ` Yu-cheng Yu
2018-07-17 23:00 ` Yu-cheng Yu
2018-07-17 23:00 ` Yu-cheng Yu
2018-07-17 23:00 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 17/27] x86/cet/shstk: User-mode shadow stack support Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:40 ` Dave Hansen
2018-07-10 23:40 ` Dave Hansen
2018-07-10 23:40 ` Dave Hansen
2018-07-11 9:34 ` Peter Zijlstra
2018-07-11 9:34 ` Peter Zijlstra
2018-07-11 9:34 ` Peter Zijlstra
2018-07-11 15:45 ` Yu-cheng Yu
2018-07-11 15:45 ` Yu-cheng Yu
2018-07-11 15:45 ` Yu-cheng Yu
2018-07-11 9:36 ` Peter Zijlstra
2018-07-11 9:36 ` Peter Zijlstra
2018-07-11 9:36 ` Peter Zijlstra
2018-07-11 21:10 ` Jann Horn
2018-07-11 21:10 ` Jann Horn
2018-07-11 21:10 ` Jann Horn
2018-07-11 21:34 ` Andy Lutomirski
2018-07-11 21:34 ` Andy Lutomirski
2018-07-11 21:34 ` Andy Lutomirski
2018-07-11 21:51 ` Jann Horn
2018-07-11 21:51 ` Jann Horn
2018-07-11 21:51 ` Jann Horn
2018-07-11 22:21 ` Andy Lutomirski
2018-07-11 22:21 ` Andy Lutomirski
2018-07-11 22:21 ` Andy Lutomirski
2018-07-13 18:03 ` Yu-cheng Yu
2018-07-13 18:03 ` Yu-cheng Yu
2018-07-13 18:03 ` Yu-cheng Yu
2018-07-13 18:03 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 18/27] x86/cet/shstk: Introduce WRUSS instruction Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:48 ` Dave Hansen
2018-07-10 23:48 ` Dave Hansen
2018-07-10 23:48 ` Dave Hansen
2018-07-12 22:59 ` Yu-cheng Yu
2018-07-12 22:59 ` Yu-cheng Yu
2018-07-12 22:59 ` Yu-cheng Yu
2018-07-12 22:59 ` Yu-cheng Yu
2018-07-12 23:49 ` Dave Hansen
2018-07-12 23:49 ` Dave Hansen
2018-07-12 23:49 ` Dave Hansen
2018-07-12 23:49 ` Dave Hansen
2018-07-13 1:50 ` Dave Hansen
2018-07-13 1:50 ` Dave Hansen
2018-07-13 1:50 ` Dave Hansen
2018-07-13 1:50 ` Dave Hansen
2018-07-13 2:21 ` Andy Lutomirski
2018-07-13 2:21 ` Andy Lutomirski
2018-07-13 2:21 ` Andy Lutomirski
2018-07-13 4:16 ` Dave Hansen
2018-07-13 4:16 ` Dave Hansen
2018-07-13 4:16 ` Dave Hansen
2018-07-13 4:16 ` Dave Hansen
2018-07-13 4:18 ` Dave Hansen
2018-07-13 4:18 ` Dave Hansen
2018-07-13 4:18 ` Dave Hansen
2018-07-13 4:18 ` Dave Hansen
2018-07-13 17:39 ` Yu-cheng Yu
2018-07-13 17:39 ` Yu-cheng Yu
2018-07-13 17:39 ` Yu-cheng Yu
2018-07-13 17:39 ` Yu-cheng Yu
2018-07-13 5:55 ` Andy Lutomirski
2018-07-13 5:55 ` Andy Lutomirski
2018-07-13 5:55 ` Andy Lutomirski
2018-07-11 9:44 ` Peter Zijlstra
2018-07-11 9:44 ` Peter Zijlstra
2018-07-11 9:44 ` Peter Zijlstra
2018-07-11 15:06 ` Yu-cheng Yu
2018-07-11 15:06 ` Yu-cheng Yu
2018-07-11 15:06 ` Yu-cheng Yu
2018-07-11 15:06 ` Yu-cheng Yu
2018-07-11 15:30 ` Peter Zijlstra
2018-07-11 15:30 ` Peter Zijlstra
2018-07-11 15:30 ` Peter Zijlstra
2018-07-11 15:30 ` Peter Zijlstra
2018-07-11 9:45 ` Peter Zijlstra
2018-07-11 9:45 ` Peter Zijlstra
2018-07-11 9:45 ` Peter Zijlstra
2018-07-11 14:58 ` Yu-cheng Yu
2018-07-11 14:58 ` Yu-cheng Yu
2018-07-11 14:58 ` Yu-cheng Yu
2018-07-11 14:58 ` Yu-cheng Yu
2018-07-11 15:27 ` Peter Zijlstra
2018-07-11 15:27 ` Peter Zijlstra
2018-07-11 15:27 ` Peter Zijlstra
2018-07-11 15:27 ` Peter Zijlstra
2018-07-11 15:41 ` Yu-cheng Yu
2018-07-11 15:41 ` Yu-cheng Yu
2018-07-11 15:41 ` Yu-cheng Yu
2018-07-11 15:41 ` Yu-cheng Yu
2018-07-13 12:12 ` Dave Hansen
2018-07-13 12:12 ` Dave Hansen
2018-07-13 12:12 ` Dave Hansen
2018-07-13 17:37 ` Yu-cheng Yu
2018-07-13 17:37 ` Yu-cheng Yu
2018-07-13 17:37 ` Yu-cheng Yu
2018-07-13 17:37 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 19/27] x86/cet/shstk: Signal handling for shadow stack Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 20/27] x86/cet/shstk: ELF header parsing of CET Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 11:12 ` Florian Weimer
2018-07-11 11:12 ` Florian Weimer
2018-07-11 11:12 ` Florian Weimer
2018-07-11 19:37 ` Jann Horn
2018-07-11 19:37 ` Jann Horn
2018-07-11 19:37 ` Jann Horn
2018-07-11 20:53 ` Yu-cheng Yu
2018-07-11 20:53 ` Yu-cheng Yu
2018-07-11 20:53 ` Yu-cheng Yu
2018-07-11 20:53 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 21/27] x86/cet/ibt: Add Kconfig option for user-mode Indirect Branch Tracking Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 22/27] x86/cet/ibt: User-mode indirect branch tracking support Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 0:11 ` Dave Hansen
2018-07-11 0:11 ` Dave Hansen
2018-07-11 0:11 ` Dave Hansen
2018-07-11 22:10 ` Yu-cheng Yu
2018-07-11 22:10 ` Yu-cheng Yu
2018-07-11 22:10 ` Yu-cheng Yu
2018-07-11 22:10 ` Yu-cheng Yu
2018-07-11 22:40 ` Dave Hansen
2018-07-11 22:40 ` Dave Hansen
2018-07-11 22:40 ` Dave Hansen
2018-07-11 22:40 ` Dave Hansen
2018-07-11 23:00 ` Yu-cheng Yu
2018-07-11 23:00 ` Yu-cheng Yu
2018-07-11 23:00 ` Yu-cheng Yu
2018-07-11 23:00 ` Yu-cheng Yu
2018-07-11 23:16 ` Dave Hansen [this message]
2018-07-11 23:16 ` Dave Hansen
2018-07-11 23:16 ` Dave Hansen
2018-07-11 23:16 ` Dave Hansen
2018-07-13 17:56 ` Yu-cheng Yu
2018-07-13 17:56 ` Yu-cheng Yu
2018-07-13 17:56 ` Yu-cheng Yu
2018-07-13 17:56 ` Yu-cheng Yu
2018-07-13 18:05 ` Dave Hansen
2018-07-13 18:05 ` Dave Hansen
2018-07-13 18:05 ` Dave Hansen
2018-07-13 18:05 ` Dave Hansen
2018-07-11 21:07 ` Jann Horn
2018-07-11 21:07 ` Jann Horn
2018-07-11 21:07 ` Jann Horn
2018-07-10 22:26 ` [RFC PATCH v2 23/27] mm/mmap: Add IBT bitmap size to address space limit check Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:57 ` Dave Hansen
2018-07-10 23:57 ` Dave Hansen
2018-07-10 23:57 ` Dave Hansen
2018-07-11 16:56 ` Yu-cheng Yu
2018-07-11 16:56 ` Yu-cheng Yu
2018-07-11 16:56 ` Yu-cheng Yu
2018-07-11 16:56 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 24/27] x86: Insert endbr32/endbr64 to vDSO Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 25/27] x86/cet: Add PTRACE interface for CET Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 10:20 ` Ingo Molnar
2018-07-11 10:20 ` Ingo Molnar
2018-07-11 10:20 ` Ingo Molnar
2018-07-11 15:40 ` Yu-cheng Yu
2018-07-11 15:40 ` Yu-cheng Yu
2018-07-11 15:40 ` Yu-cheng Yu
2018-07-11 15:40 ` Yu-cheng Yu
2018-07-12 14:03 ` Ingo Molnar
2018-07-12 14:03 ` Ingo Molnar
2018-07-12 14:03 ` Ingo Molnar
2018-07-12 14:03 ` Ingo Molnar
2018-07-12 22:37 ` Yu-cheng Yu
2018-07-12 22:37 ` Yu-cheng Yu
2018-07-12 22:37 ` Yu-cheng Yu
2018-07-12 22:37 ` Yu-cheng Yu
2018-07-12 23:08 ` Thomas Gleixner
2018-07-12 23:08 ` Thomas Gleixner
2018-07-12 23:08 ` Thomas Gleixner
2018-07-13 16:07 ` Yu-cheng Yu
2018-07-13 16:07 ` Yu-cheng Yu
2018-07-13 16:07 ` Yu-cheng Yu
2018-07-13 16:07 ` Yu-cheng Yu
2018-07-13 6:28 ` Pavel Machek
2018-07-13 6:28 ` Pavel Machek
2018-07-13 13:33 ` Ingo Molnar
2018-07-13 13:33 ` Ingo Molnar
2018-07-13 13:33 ` Ingo Molnar
2018-07-14 6:27 ` Pavel Machek
2018-07-14 6:27 ` Pavel Machek
2018-07-10 22:26 ` [RFC PATCH v2 26/27] x86/cet/shstk: Handle thread shadow stack Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 27/27] x86/cet: Add arch_prctl functions for CET Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 12:19 ` Florian Weimer
2018-07-11 12:19 ` Florian Weimer
2018-07-11 12:19 ` Florian Weimer
2018-07-11 12:19 ` Florian Weimer
2018-07-11 21:02 ` Yu-cheng Yu
2018-07-11 21:02 ` Yu-cheng Yu
2018-07-11 21:02 ` Yu-cheng Yu
2018-07-11 21:02 ` Yu-cheng Yu
2018-07-11 19:45 ` Jann Horn
2018-07-11 19:45 ` Jann Horn
2018-07-11 19:45 ` Jann Horn
2018-07-11 20:55 ` Yu-cheng Yu
2018-07-11 20:55 ` Yu-cheng Yu
2018-07-11 20:55 ` Yu-cheng Yu
2018-07-11 20:55 ` Yu-cheng Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25675609-9ea7-55fb-6e73-b4a4c49b6c35@linux.intel.com \
--to=dave.hansen@linux.intel.com \
--cc=arnd@arndb.de \
--cc=bsingharora@gmail.com \
--cc=corbet@lwn.net \
--cc=fweimer@redhat.com \
--cc=gorcunov@gmail.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=keescook@chromiun.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=mike.kravetz@oracle.com \
--cc=mingo@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=oleg@redhat.com \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=tglx@linutronix.de \
--cc=vedvyas.shanbhogue@intel.com \
--cc=x86@kernel.org \
--cc=yu-cheng.yu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.