On 5/1/19 8:49 AM, Waiman Long wrote:
> On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
>
>> index 858b6c0b9a15..9b36da94760e 100644
>> ---
On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
> index 858b6c0b9a15..9b36da94760e 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++
On Thu, Apr 18, 2019 at 7:35 AM Khalid Aziz wrote:
>
> On 4/17/19 11:41 PM, Kees Cook wrote:
> > On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote:
> >> I don't think this type of NX goof was ever the argument for XPFO.
> >> The main argument I've heard is that a malicious user program
On 4/18/19 8:34 AM, Khalid Aziz wrote:
> On 4/17/19 11:41 PM, Kees Cook wrote:
>> On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote:
>>> I don't think this type of NX goof was ever the argument for XPFO.
>>> The main argument I've heard is that a malicious user program writes a
>>> ROP
On 4/17/19 11:41 PM, Kees Cook wrote:
> On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote:
>> I don't think this type of NX goof was ever the argument for XPFO.
>> The main argument I've heard is that a malicious user program writes a
>> ROP payload into user memory (regular anonymous user
On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote:
> I don't think this type of NX goof was ever the argument for XPFO.
> The main argument I've heard is that a malicious user program writes a
> ROP payload into user memory (regular anonymous user memory) and then
> gets the kernel to
On Wed, 17 Apr 2019, Linus Torvalds wrote:
> On Wed, Apr 17, 2019 at 4:42 PM Thomas Gleixner wrote:
> > On Wed, 17 Apr 2019, Linus Torvalds wrote:
> > > With SMEP, user space pages are always NX.
> >
> > We talk past each other. The user space page in the ring3 valid virtual
> > address space
On Wed, Apr 17, 2019 at 5:00 PM Linus Torvalds
wrote:
>
> On Wed, Apr 17, 2019 at 4:42 PM Thomas Gleixner wrote:
> >
> > On Wed, 17 Apr 2019, Linus Torvalds wrote:
> >
> > > With SMEP, user space pages are always NX.
> >
> > We talk past each other. The user space page in the ring3 valid virtual
On Wed, Apr 17, 2019 at 4:42 PM Thomas Gleixner wrote:
>
> On Wed, 17 Apr 2019, Linus Torvalds wrote:
>
> > With SMEP, user space pages are always NX.
>
> We talk past each other. The user space page in the ring3 valid virtual
> address space (non negative) is of course protected by SMEP.
>
> The
On Wed, 17 Apr 2019, Linus Torvalds wrote:
> On Wed, Apr 17, 2019, 14:20 Thomas Gleixner wrote:
>
> >
> > It's not necessarily a W+X issue. The user space text is mapped in the
> > kernel as well and even if it is mapped RX then this can happen. So any
> > kernel mappings of user space text
On Wed, Apr 17, 2019, 14:20 Thomas Gleixner wrote:
>
> It's not necessarily a W+X issue. The user space text is mapped in the
> kernel as well and even if it is mapped RX then this can happen. So any
> kernel mappings of user space text need to be mapped NX!
With SMEP, user space pages are
On Wed, 17 Apr 2019, Nadav Amit wrote:
> > On Apr 17, 2019, at 10:26 AM, Ingo Molnar wrote:
> >> As I was curious, I looked at the paper. Here is a quote from it:
> >>
> >> "In x86-64, however, the permissions of physmap are not in sane state.
> >> Kernels up to v3.8.13 violate the W^X property
On 4/17/19 1:49 PM, Andy Lutomirski wrote:
> On Wed, Apr 17, 2019 at 10:33 AM Khalid Aziz wrote:
>>
>> On 4/17/19 11:09 AM, Ingo Molnar wrote:
>>>
>>> * Khalid Aziz wrote:
>>>
> I.e. the original motivation of the XPFO patches was to prevent execution
> of direct kernel mappings. Is this
On Wed, Apr 17, 2019 at 12:49:04PM -0700, Andy Lutomirski wrote:
> I also proposed using a gcc plugin (or upstream gcc feature) to add
> some instrumentation to any code that pops RSP to verify that the
> resulting (unsigned) change in RSP is between 0 and THREAD_SIZE bytes.
> This will make ROP
On Wed, Apr 17, 2019 at 10:33 AM Khalid Aziz wrote:
>
> On 4/17/19 11:09 AM, Ingo Molnar wrote:
> >
> > * Khalid Aziz wrote:
> >
> >>> I.e. the original motivation of the XPFO patches was to prevent execution
> >>> of direct kernel mappings. Is this motivation still present if those
> >>>
> On Apr 17, 2019, at 10:26 AM, Ingo Molnar wrote:
>
>
> * Nadav Amit wrote:
>
>>> On Apr 17, 2019, at 10:09 AM, Ingo Molnar wrote:
>>>
>>>
>>> * Khalid Aziz wrote:
>>>
> I.e. the original motivation of the XPFO patches was to prevent execution
> of direct kernel mappings. Is
On 4/17/19 11:09 AM, Ingo Molnar wrote:
>
> * Khalid Aziz wrote:
>
>>> I.e. the original motivation of the XPFO patches was to prevent execution
>>> of direct kernel mappings. Is this motivation still present if those
>>> mappings are non-executable?
>>>
>>> (Sorry if this has been asked and
* Nadav Amit wrote:
> > On Apr 17, 2019, at 10:09 AM, Ingo Molnar wrote:
> >
> >
> > * Khalid Aziz wrote:
> >
> >>> I.e. the original motivation of the XPFO patches was to prevent execution
> >>> of direct kernel mappings. Is this motivation still present if those
> >>> mappings are
> On Apr 17, 2019, at 10:09 AM, Ingo Molnar wrote:
>
>
> * Khalid Aziz wrote:
>
>>> I.e. the original motivation of the XPFO patches was to prevent execution
>>> of direct kernel mappings. Is this motivation still present if those
>>> mappings are non-executable?
>>>
>>> (Sorry if this has
* Khalid Aziz wrote:
> > I.e. the original motivation of the XPFO patches was to prevent execution
> > of direct kernel mappings. Is this motivation still present if those
> > mappings are non-executable?
> >
> > (Sorry if this has been asked and answered in previous discussions.)
>
> Hi
On 4/17/19 10:15 AM, Ingo Molnar wrote:
>
> [ Sorry, had to trim the Cc: list from hell. Tried to keep all the
> mailing lists and all x86 developers. ]
>
> * Khalid Aziz wrote:
>
>> From: Juerg Haefliger
>>
>> This patch adds basic support infrastructure for XPFO which protects
>>
[ Sorry, had to trim the Cc: list from hell. Tried to keep all the
mailing lists and all x86 developers. ]
* Khalid Aziz wrote:
> From: Juerg Haefliger
>
> This patch adds basic support infrastructure for XPFO which protects
> against 'ret2dir' kernel attacks. The basic idea is to
On Thu, Apr 04, 2019 at 09:15:46AM -0600, Khalid Aziz wrote:
> Thanks Peter. I really appreciate your review. Your feedback helps make
> this code better and closer to where I can feel comfortable not calling
> it RFC any more.
>
> The more I look at xpfo_kmap()/xpfo_kunmap() code, the more I get
On 4/4/19 1:43 AM, Peter Zijlstra wrote:
>
> You must be so glad I no longer use kmap_atomic from NMI context :-)
>
> On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
>> +static inline void xpfo_kmap(void *kaddr, struct page *page)
>> +{
>> +unsigned long flags;
>> +
>> +if
On Thu, Apr 04, 2019 at 09:21:52AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 2c471a2c43fa..d17d33f36a01 100644
> > --- a/include/linux/mm_types.h
> > +++
On Thu, Apr 04, 2019 at 09:21:52AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 2c471a2c43fa..d17d33f36a01 100644
> > --- a/include/linux/mm_types.h
> > +++
You must be so glad I no longer use kmap_atomic from NMI context :-)
On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
> +static inline void xpfo_kmap(void *kaddr, struct page *page)
> +{
> + unsigned long flags;
> +
> + if (!static_branch_unlikely(_inited))
> +
On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 2c471a2c43fa..d17d33f36a01 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -204,6 +204,14 @@ struct page {
> #ifdef
From: Juerg Haefliger
This patch adds basic support infrastructure for XPFO which protects
against 'ret2dir' kernel attacks. The basic idea is to enforce exclusive
ownership of page frames by either the kernel or userspace, unless
explicitly requested by the kernel. Whenever a page destined for
29 matches
Mail list logo
