All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khalid Aziz <khalid.aziz@oracle.com>
To: Kees Cook <keescook@google.com>,
	Andy Lutomirski <luto@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Nadav Amit <nadav.amit@gmail.com>, Ingo Molnar <mingo@kernel.org>,
	Juerg Haefliger <juergh@gmail.com>,
	Tycho Andersen <tycho@tycho.ws>,
	Julian Stecklina <jsteckli@amazon.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Juerg Haefliger <juerg.haefliger@canonical.com>,
	deepa.srinivasan@oracle.com, chris hyser <chris.hyser@oracle.com>,
	Tyler Hicks <tyhicks@canonical.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jon Masters <jcm@redhat.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	iommu <iommu@lists.linux-foundation.org>, X86 ML <x86@kernel.org>,
	"linux-alpha@vger.kernel.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	Khalid Aziz <khalid@gonehiking.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Dave Hansen <dave@sr71.net>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO)
Date: Mon, 22 Apr 2019 13:30:41 -0600	[thread overview]
Message-ID: <302e3d5b-d2fd-3c25-335b-466ba83035c5@oracle.com> (raw)
In-Reply-To: <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com>

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 <luto@kernel.org> 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 erroneously set RSP (*not* RIP) to point there.
>>
>> Well, more than just ROP. Any of the various attack primitives. The NX
>> stuff is about moving RIP: SMEP-bypassing. But there is still basic
>> SMAP-bypassing for putting a malicious structure in userspace and
>> having the kernel access it via the linear mapping, etc.
>>
>>> I find this argument fairly weak for a couple reasons.  First, if
>>> we're worried about this, let's do in-kernel CFI, not XPFO, to
>>
>> CFI is getting much closer. Getting the kernel happy under Clang, LTO,
>> and CFI is under active development. (It's functional for arm64
>> already, and pieces have been getting upstreamed.)
>>
> 
> CFI theoretically offers protection with fairly low overhead. I have not
> played much with CFI in clang. I agree with Linus that probability of
> bugs in XPFO implementation itself is a cause of concern. If CFI in
> Clang can provide us the same level of protection as XPFO does, I
> wouldn't want to push for an expensive change like XPFO.
> 
> If Clang/CFI can't get us there for extended period of time, does it
> make sense to continue to poke at XPFO?

Any feedback on continued effort on XPFO? If it makes sense to have XPFO
available as a solution for ret2dir issue in case Clang/CFI does not
work out, I will continue to refine it.

--
Khalid


WARNING: multiple messages have this Message-ID (diff)
From: Khalid Aziz <khalid.aziz@oracle.com>
To: Kees Cook <keescook@google.com>,
	Andy Lutomirski <luto@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave@sr71.net>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	deepa.srinivasan@oracle.com, "H. Peter Anvin" <hpa@zytor.com>,
	Nadav Amit <nadav.amit@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tycho Andersen <tycho@tycho.ws>, X86 ML <x86@kernel.org>,
	iommu <iommu@lists.linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>,
	Julian Stecklina <jsteckli@amazon.de>,
	Arjan van de Ven <arjan@infradead.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jon Masters <jcm@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	chris hyser <chris.hyser@oracle.com>,
	"linux-alpha@vger.kernel.org"
	<linux-arm-kernel@lists.infradead.org>,
	Khalid Aziz <khalid@gonehiking.org>,
	Juerg Haefliger <juergh@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO)
Date: Mon, 22 Apr 2019 13:30:41 -0600	[thread overview]
Message-ID: <302e3d5b-d2fd-3c25-335b-466ba83035c5@oracle.com> (raw)
In-Reply-To: <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com>

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 <luto@kernel.org> 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 erroneously set RSP (*not* RIP) to point there.
>>
>> Well, more than just ROP. Any of the various attack primitives. The NX
>> stuff is about moving RIP: SMEP-bypassing. But there is still basic
>> SMAP-bypassing for putting a malicious structure in userspace and
>> having the kernel access it via the linear mapping, etc.
>>
>>> I find this argument fairly weak for a couple reasons.  First, if
>>> we're worried about this, let's do in-kernel CFI, not XPFO, to
>>
>> CFI is getting much closer. Getting the kernel happy under Clang, LTO,
>> and CFI is under active development. (It's functional for arm64
>> already, and pieces have been getting upstreamed.)
>>
> 
> CFI theoretically offers protection with fairly low overhead. I have not
> played much with CFI in clang. I agree with Linus that probability of
> bugs in XPFO implementation itself is a cause of concern. If CFI in
> Clang can provide us the same level of protection as XPFO does, I
> wouldn't want to push for an expensive change like XPFO.
> 
> If Clang/CFI can't get us there for extended period of time, does it
> make sense to continue to poke at XPFO?

Any feedback on continued effort on XPFO? If it makes sense to have XPFO
available as a solution for ret2dir issue in case Clang/CFI does not
work out, I will continue to refine it.

--
Khalid

WARNING: multiple messages have this Message-ID (diff)
From: Khalid Aziz <khalid.aziz@oracle.com>
To: Kees Cook <keescook@google.com>,
	Andy Lutomirski <luto@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave@sr71.net>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	deepa.srinivasan@oracle.com, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tycho Andersen <tycho@tycho.ws>, X86 ML <x86@kernel.org>,
	iommu <iommu@lists.linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>,
	Julian Stecklina <jsteckli@amazon.de>,
	Arjan van de Ven <arjan@infradead.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jon Masters <jcm@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	chris hyser <chris.hyser@oracle.com>,
	"linux-alpha@vger.kernel.org"
	<linux-arm-kernel@lists.infradead.org>,
	Khalid Aziz <khalid@gonehiking.org>,
	Juerg Haefliger <juergh@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	Tyler Hicks <tyhicks@canonical.com>,
	LSM List <linux-security-module@vger.kernel.org>,
	Juerg Haefliger <juerg.haefliger@canonical.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Woodhouse <dwmw@amazon.co.uk>
Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO)
Date: Mon, 22 Apr 2019 13:30:41 -0600	[thread overview]
Message-ID: <302e3d5b-d2fd-3c25-335b-466ba83035c5@oracle.com> (raw)
Message-ID: <20190422193041.FZj9I524i-W9LcPThCT4xhNywwP_sJYwVAN1TC__OYM@z> (raw)
In-Reply-To: <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com>

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 <luto@kernel.org> 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 erroneously set RSP (*not* RIP) to point there.
>>
>> Well, more than just ROP. Any of the various attack primitives. The NX
>> stuff is about moving RIP: SMEP-bypassing. But there is still basic
>> SMAP-bypassing for putting a malicious structure in userspace and
>> having the kernel access it via the linear mapping, etc.
>>
>>> I find this argument fairly weak for a couple reasons.  First, if
>>> we're worried about this, let's do in-kernel CFI, not XPFO, to
>>
>> CFI is getting much closer. Getting the kernel happy under Clang, LTO,
>> and CFI is under active development. (It's functional for arm64
>> already, and pieces have been getting upstreamed.)
>>
> 
> CFI theoretically offers protection with fairly low overhead. I have not
> played much with CFI in clang. I agree with Linus that probability of
> bugs in XPFO implementation itself is a cause of concern. If CFI in
> Clang can provide us the same level of protection as XPFO does, I
> wouldn't want to push for an expensive change like XPFO.
> 
> If Clang/CFI can't get us there for extended period of time, does it
> make sense to continue to poke at XPFO?

Any feedback on continued effort on XPFO? If it makes sense to have XPFO
available as a solution for ret2dir issue in case Clang/CFI does not
work out, I will continue to refine it.

--
Khalid

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Khalid Aziz <khalid.aziz@oracle.com>
To: Kees Cook <keescook@google.com>,
	Andy Lutomirski <luto@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave@sr71.net>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	deepa.srinivasan@oracle.com, "H. Peter Anvin" <hpa@zytor.com>,
	Nadav Amit <nadav.amit@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tycho Andersen <tycho@tycho.ws>, X86 ML <x86@kernel.org>,
	iommu <iommu@lists.linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>,
	Julian Stecklina <jsteckli@amazon.de>,
	Arjan van de Ven <arjan@infradead.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jon Masters <jcm@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	chris hyser <chris.hyser@oracle.com>,
	"linux-alpha@vger.kernel.org"
	<linux-arm-kernel@lists.infradead.org>,
	Khalid Aziz <khalid@gonehiking.org>,
	Juerg Haefliger <juergh@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	Tyler Hicks <tyhicks@canonical.com>,
	LSM List <linux-security-module@vger.kernel.org>,
	Juerg Haefliger <juerg.haefliger@canonical.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Woodhouse <dwmw@amazon.co.uk>
Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO)
Date: Mon, 22 Apr 2019 13:30:41 -0600	[thread overview]
Message-ID: <302e3d5b-d2fd-3c25-335b-466ba83035c5@oracle.com> (raw)
In-Reply-To: <8f9d059d-e720-cd24-faa6-45493fc012e0@oracle.com>

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 <luto@kernel.org> 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 erroneously set RSP (*not* RIP) to point there.
>>
>> Well, more than just ROP. Any of the various attack primitives. The NX
>> stuff is about moving RIP: SMEP-bypassing. But there is still basic
>> SMAP-bypassing for putting a malicious structure in userspace and
>> having the kernel access it via the linear mapping, etc.
>>
>>> I find this argument fairly weak for a couple reasons.  First, if
>>> we're worried about this, let's do in-kernel CFI, not XPFO, to
>>
>> CFI is getting much closer. Getting the kernel happy under Clang, LTO,
>> and CFI is under active development. (It's functional for arm64
>> already, and pieces have been getting upstreamed.)
>>
> 
> CFI theoretically offers protection with fairly low overhead. I have not
> played much with CFI in clang. I agree with Linus that probability of
> bugs in XPFO implementation itself is a cause of concern. If CFI in
> Clang can provide us the same level of protection as XPFO does, I
> wouldn't want to push for an expensive change like XPFO.
> 
> If Clang/CFI can't get us there for extended period of time, does it
> make sense to continue to poke at XPFO?

Any feedback on continued effort on XPFO? If it makes sense to have XPFO
available as a solution for ret2dir issue in case Clang/CFI does not
work out, I will continue to refine it.

--
Khalid


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-04-22 19:32 UTC|newest]

Thread overview: 202+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-03 17:34 [RFC PATCH v9 00/13] Add support for eXclusive Page Frame Ownership Khalid Aziz
2019-04-03 17:34 ` Khalid Aziz
2019-04-03 17:34 ` [RFC PATCH v9 01/13] mm: add MAP_HUGETLB support to vm_mmap Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-03 17:34 ` [RFC PATCH v9 02/13] x86: always set IF before oopsing from page fault Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-04  0:12   ` Andy Lutomirski
2019-04-04  0:12     ` Andy Lutomirski
2019-04-04  1:42     ` Tycho Andersen
2019-04-04  1:42       ` Tycho Andersen
2019-04-04  4:12       ` Andy Lutomirski
2019-04-04  4:12         ` Andy Lutomirski
2019-04-04 15:47         ` Tycho Andersen
2019-04-04 15:47           ` Tycho Andersen
2019-04-04 16:23           ` Sebastian Andrzej Siewior
2019-04-04 16:28           ` Thomas Gleixner
2019-04-04 16:28             ` Thomas Gleixner
2019-04-04 17:11             ` Andy Lutomirski
2019-04-04 17:11               ` Andy Lutomirski
2019-04-03 17:34 ` [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-04  7:21   ` Peter Zijlstra
2019-04-04  7:21     ` Peter Zijlstra
2019-04-04  9:25     ` Peter Zijlstra
2019-04-04  9:25       ` Peter Zijlstra
2019-04-04 14:48     ` Tycho Andersen
2019-04-04 14:48       ` Tycho Andersen
2019-04-04  7:43   ` Peter Zijlstra
2019-04-04  7:43     ` Peter Zijlstra
2019-04-04 15:15     ` Khalid Aziz
2019-04-04 15:15       ` Khalid Aziz
2019-04-04 17:01       ` Peter Zijlstra
2019-04-04 17:01         ` Peter Zijlstra
2019-04-17 16:15   ` Ingo Molnar
2019-04-17 16:15     ` Ingo Molnar
2019-04-17 16:15     ` Ingo Molnar
2019-04-17 16:15     ` Ingo Molnar
2019-04-17 16:49     ` Khalid Aziz
2019-04-17 16:49       ` Khalid Aziz
2019-04-17 16:49       ` Khalid Aziz
2019-04-17 16:49       ` Khalid Aziz
2019-04-17 17:09       ` Ingo Molnar
2019-04-17 17:09         ` Ingo Molnar
2019-04-17 17:09         ` Ingo Molnar
2019-04-17 17:09         ` Ingo Molnar
2019-04-17 17:19         ` Nadav Amit
2019-04-17 17:19           ` Nadav Amit
2019-04-17 17:19           ` Nadav Amit
2019-04-17 17:19           ` Nadav Amit
2019-04-17 17:26           ` Ingo Molnar
2019-04-17 17:26             ` Ingo Molnar
2019-04-17 17:26             ` Ingo Molnar
2019-04-17 17:26             ` Ingo Molnar
2019-04-17 17:44             ` Nadav Amit
2019-04-17 17:44               ` Nadav Amit
2019-04-17 17:44               ` Nadav Amit
2019-04-17 17:44               ` Nadav Amit
2019-04-17 21:19               ` Thomas Gleixner
2019-04-17 21:19                 ` Thomas Gleixner
2019-04-17 21:19                 ` Thomas Gleixner
2019-04-17 21:19                 ` Thomas Gleixner
2019-04-17 21:19                 ` Thomas Gleixner
2019-04-17 23:18                 ` Linus Torvalds
2019-04-17 23:18                   ` Linus Torvalds
2019-04-17 23:18                   ` Linus Torvalds
2019-04-17 23:42                   ` Thomas Gleixner
2019-04-17 23:42                     ` Thomas Gleixner
2019-04-17 23:42                     ` Thomas Gleixner
2019-04-17 23:42                     ` Thomas Gleixner
2019-04-17 23:42                     ` Thomas Gleixner
2019-04-17 23:52                     ` Linus Torvalds
2019-04-17 23:52                       ` Linus Torvalds
2019-04-17 23:52                       ` Linus Torvalds
2019-04-17 23:52                       ` Linus Torvalds
2019-04-17 23:52                       ` Linus Torvalds
2019-04-18  4:41                       ` Andy Lutomirski
2019-04-18  4:41                         ` Andy Lutomirski
2019-04-18  4:41                         ` Andy Lutomirski
2019-04-18  4:41                         ` Andy Lutomirski
2019-04-18  4:41                         ` Andy Lutomirski
2019-04-18  5:41                         ` Kees Cook
2019-04-18  5:41                           ` Kees Cook
2019-04-18  5:41                           ` Kees Cook via iommu
2019-04-18  5:41                           ` Kees Cook
2019-04-18  5:41                           ` Kees Cook
2019-04-18 14:34                           ` Khalid Aziz
2019-04-18 14:34                             ` Khalid Aziz
2019-04-18 14:34                             ` Khalid Aziz
2019-04-18 14:34                             ` Khalid Aziz
2019-04-22 19:30                             ` Khalid Aziz [this message]
2019-04-22 19:30                               ` Khalid Aziz
2019-04-22 19:30                               ` Khalid Aziz
2019-04-22 19:30                               ` Khalid Aziz
2019-04-22 22:23                             ` Kees Cook
2019-04-22 22:23                               ` Kees Cook
2019-04-22 22:23                               ` Kees Cook via iommu
2019-04-22 22:23                               ` Kees Cook via iommu
2019-04-22 22:23                               ` Kees Cook
2019-04-18  6:14                       ` Thomas Gleixner
2019-04-18  6:14                         ` Thomas Gleixner
2019-04-18  6:14                         ` Thomas Gleixner
2019-04-18  6:14                         ` Thomas Gleixner
2019-04-18  6:14                         ` Thomas Gleixner
2019-04-17 17:33         ` Khalid Aziz
2019-04-17 17:33           ` Khalid Aziz
2019-04-17 17:33           ` Khalid Aziz
2019-04-17 17:33           ` Khalid Aziz
2019-04-17 19:49           ` Andy Lutomirski
2019-04-17 19:49             ` Andy Lutomirski
2019-04-17 19:49             ` Andy Lutomirski
2019-04-17 19:49             ` Andy Lutomirski
2019-04-17 19:49             ` Andy Lutomirski
2019-04-17 19:52             ` Tycho Andersen
2019-04-17 19:52               ` Tycho Andersen
2019-04-17 19:52               ` Tycho Andersen
2019-04-17 19:52               ` Tycho Andersen
2019-04-17 20:12             ` Khalid Aziz
2019-04-17 20:12               ` Khalid Aziz
2019-04-17 20:12               ` Khalid Aziz
2019-04-17 20:12               ` Khalid Aziz
2019-05-01 14:49       ` Waiman Long
2019-05-01 14:49         ` Waiman Long
2019-05-01 14:49         ` Waiman Long
2019-05-01 14:49         ` Waiman Long
2019-05-01 15:18         ` Khalid Aziz
2019-05-01 15:18           ` Khalid Aziz
2019-05-01 15:18           ` Khalid Aziz
2019-05-01 15:18           ` Khalid Aziz
2019-04-03 17:34 ` [RFC PATCH v9 04/13] xpfo, x86: Add support for XPFO for x86-64 Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-04  7:52   ` Peter Zijlstra
2019-04-04  7:52     ` Peter Zijlstra
2019-04-04 15:40     ` Khalid Aziz
2019-04-04 15:40       ` Khalid Aziz
2019-04-03 17:34 ` [RFC PATCH v9 05/13] mm: add a user_virt_to_phys symbol Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-03 17:34 ` [RFC PATCH v9 06/13] lkdtm: Add test for XPFO Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-03 17:34 ` [RFC PATCH v9 07/13] arm64/mm: Add support " Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-03 17:34 ` [RFC PATCH v9 08/13] swiotlb: Map the buffer if it was unmapped by XPFO Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-03 17:34 ` [RFC PATCH v9 09/13] xpfo: add primitives for mapping underlying memory Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-03 17:34 ` [RFC PATCH v9 10/13] arm64/mm, xpfo: temporarily map dcache regions Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-03 17:34 ` [RFC PATCH v9 11/13] xpfo, mm: optimize spinlock usage in xpfo_kunmap Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-04  7:56   ` Peter Zijlstra
2019-04-04  7:56     ` Peter Zijlstra
2019-04-04 16:06     ` Khalid Aziz
2019-04-04 16:06       ` Khalid Aziz
2019-04-03 17:34 ` [RFC PATCH v9 12/13] xpfo, mm: Defer TLB flushes for non-current CPUs (x86 only) Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-04  4:10   ` Andy Lutomirski
2019-04-04  4:10     ` Andy Lutomirski
     [not found]     ` <CALCETrXMXxnWqN94d83UvGWhkD1BNWiwvH2vsUth1w0T3=0ywQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-04-04 22:55       ` Khalid Aziz
2019-04-05  7:17         ` Thomas Gleixner
2019-04-05  7:17           ` Thomas Gleixner
2019-04-05 14:44           ` Dave Hansen
2019-04-05 14:44             ` Dave Hansen
2019-04-05 15:24             ` Andy Lutomirski
2019-04-05 15:24               ` Andy Lutomirski
2019-04-05 15:24               ` Andy Lutomirski
2019-04-05 15:56               ` Tycho Andersen
2019-04-05 15:56                 ` Tycho Andersen
2019-04-05 15:56                 ` Tycho Andersen
2019-04-05 16:32                 ` Andy Lutomirski
2019-04-05 16:32                   ` Andy Lutomirski
2019-04-05 16:32                   ` Andy Lutomirski
2019-04-05 15:56               ` Khalid Aziz
2019-04-05 15:56                 ` Khalid Aziz
2019-04-05 15:56                 ` Khalid Aziz
2019-04-05 16:01               ` Dave Hansen
2019-04-05 16:01                 ` Dave Hansen
2019-04-05 16:01                 ` Dave Hansen
2019-04-05 16:27                 ` Andy Lutomirski
2019-04-05 16:27                   ` Andy Lutomirski
2019-04-05 16:27                   ` Andy Lutomirski
2019-04-05 16:41                   ` Peter Zijlstra
2019-04-05 16:41                     ` Peter Zijlstra
2019-04-05 16:41                     ` Peter Zijlstra
2019-04-05 17:35                   ` Khalid Aziz
2019-04-05 17:35                     ` Khalid Aziz
2019-04-05 17:35                     ` Khalid Aziz
2019-04-05 15:44             ` Khalid Aziz
2019-04-05 15:44               ` Khalid Aziz
2019-04-05 15:44               ` Khalid Aziz
2019-04-05 15:24         ` Andy Lutomirski
2019-04-05 15:24           ` Andy Lutomirski
2019-04-05 15:24           ` Andy Lutomirski
2019-04-04  8:18   ` Peter Zijlstra
2019-04-04  8:18     ` Peter Zijlstra
2019-04-03 17:34 ` [RFC PATCH v9 13/13] xpfo, mm: Optimize XPFO TLB flushes by batching them together Khalid Aziz
2019-04-03 17:34   ` Khalid Aziz
2019-04-04 16:44 ` [RFC PATCH v9 00/13] Add support for eXclusive Page Frame Ownership Nadav Amit
2019-04-04 16:44   ` Nadav Amit
2019-04-04 17:18   ` Khalid Aziz
2019-04-04 17:18     ` Khalid Aziz
2019-04-06  6:40 ` Jon Masters
2019-04-06  6:40   ` Jon Masters
2019-04-06  6:40   ` Jon Masters

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=302e3d5b-d2fd-3c25-335b-466ba83035c5@oracle.com \
    --to=khalid.aziz@oracle.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=arjan@infradead.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=chris.hyser@oracle.com \
    --cc=dave@sr71.net \
    --cc=deepa.srinivasan@oracle.com \
    --cc=dwmw@amazon.co.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jcm@redhat.com \
    --cc=jsteckli@amazon.de \
    --cc=juerg.haefliger@canonical.com \
    --cc=juergh@gmail.com \
    --cc=keescook@google.com \
    --cc=khalid@gonehiking.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=nadav.amit@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tycho@tycho.ws \
    --cc=tyhicks@canonical.com \
    --cc=x86@kernel.org \
    /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.