[ Sorry, had to trim the Cc: list from hell. Tried to keep all the
mailing lists and all x86 developers. ]
* Khalid Aziz <[email protected]> wrote:
> From: Juerg Haefliger <[email protected]>
>
> 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
> userspace is allocated, it is unmapped from physmap (the kernel's page
> table). When such a page is reclaimed from userspace, it is mapped back
> to physmap. Individual architectures can enable full XPFO support using
> this infrastructure by supplying architecture specific pieces.
I have a higher level, meta question:
Is there any updated analysis outlining why this XPFO overhead would be
required on x86-64 kernels running on SMAP/SMEP CPUs which should be all
recent Intel and AMD CPUs, and with kernel that mark all direct kernel
mappings as non-executable - which should be all reasonably modern
kernels later than v4.0 or so?
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.)
Thanks,
Ingo
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 <[email protected]> wrote:
>
>> From: Juerg Haefliger <[email protected]>
>>
>> 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
>> userspace is allocated, it is unmapped from physmap (the kernel's page
>> table). When such a page is reclaimed from userspace, it is mapped back
>> to physmap. Individual architectures can enable full XPFO support using
>> this infrastructure by supplying architecture specific pieces.
>
> I have a higher level, meta question:
>
> Is there any updated analysis outlining why this XPFO overhead would be
> required on x86-64 kernels running on SMAP/SMEP CPUs which should be all
> recent Intel and AMD CPUs, and with kernel that mark all direct kernel
> mappings as non-executable - which should be all reasonably modern
> kernels later than v4.0 or so?
>
> 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 Ingo,
That is a good question. Because of the cost of XPFO, we have to be very
sure we need this protection. The paper from Vasileios, Michalis and
Angelos - <http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf>,
does go into how ret2dir attacks can bypass SMAP/SMEP in sections 6.1
and 6.2.
Thanks,
Khalid
* Khalid Aziz <[email protected]> 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 Ingo,
>
> That is a good question. Because of the cost of XPFO, we have to be very
> sure we need this protection. The paper from Vasileios, Michalis and
> Angelos - <http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf>,
> does go into how ret2dir attacks can bypass SMAP/SMEP in sections 6.1
> and 6.2.
So it would be nice if you could generally summarize external arguments
when defending a patchset, instead of me having to dig through a PDF
which not only causes me to spend time that you probably already spent
reading that PDF, but I might also interpret it incorrectly. ;-)
The PDF you cited says this:
"Unfortunately, as shown in Table 1, the W^X prop-erty is not enforced
in many platforms, including x86-64. In our example, the content of
user address 0xBEEF000 is also accessible through kernel address
0xFFFF87FF9F080000 as plain, executable code."
Is this actually true of modern x86-64 kernels? We've locked down W^X
protections in general.
I.e. this conclusion:
"Therefore, by simply overwriting kfptr with 0xFFFF87FF9F080000 and
triggering the kernel to dereference it, an attacker can directly
execute shell code with kernel privileges."
... appears to be predicated on imperfect W^X protections on the x86-64
kernel.
Do such holes exist on the latest x86-64 kernel? If yes, is there a
reason to believe that these W^X holes cannot be fixed, or that any fix
would be more expensive than XPFO?
Thanks,
Ingo
> On Apr 17, 2019, at 10:09 AM, Ingo Molnar <[email protected]> wrote:
>
>
> * Khalid Aziz <[email protected]> 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 Ingo,
>>
>> That is a good question. Because of the cost of XPFO, we have to be very
>> sure we need this protection. The paper from Vasileios, Michalis and
>> Angelos - <http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf>,
>> does go into how ret2dir attacks can bypass SMAP/SMEP in sections 6.1
>> and 6.2.
>
> So it would be nice if you could generally summarize external arguments
> when defending a patchset, instead of me having to dig through a PDF
> which not only causes me to spend time that you probably already spent
> reading that PDF, but I might also interpret it incorrectly. ;-)
>
> The PDF you cited says this:
>
> "Unfortunately, as shown in Table 1, the W^X prop-erty is not enforced
> in many platforms, including x86-64. In our example, the content of
> user address 0xBEEF000 is also accessible through kernel address
> 0xFFFF87FF9F080000 as plain, executable code."
>
> Is this actually true of modern x86-64 kernels? We've locked down W^X
> protections in general.
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 by mapping the entire region
as “readable, writeable, and executable” (RWX)—only very recent kernels
(≥v3.9) use the more conservative RW mapping.”
* Nadav Amit <[email protected]> wrote:
> > On Apr 17, 2019, at 10:09 AM, Ingo Molnar <[email protected]> wrote:
> >
> >
> > * Khalid Aziz <[email protected]> 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 Ingo,
> >>
> >> That is a good question. Because of the cost of XPFO, we have to be very
> >> sure we need this protection. The paper from Vasileios, Michalis and
> >> Angelos - <http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf>,
> >> does go into how ret2dir attacks can bypass SMAP/SMEP in sections 6.1
> >> and 6.2.
> >
> > So it would be nice if you could generally summarize external arguments
> > when defending a patchset, instead of me having to dig through a PDF
> > which not only causes me to spend time that you probably already spent
> > reading that PDF, but I might also interpret it incorrectly. ;-)
> >
> > The PDF you cited says this:
> >
> > "Unfortunately, as shown in Table 1, the W^X prop-erty is not enforced
> > in many platforms, including x86-64. In our example, the content of
> > user address 0xBEEF000 is also accessible through kernel address
> > 0xFFFF87FF9F080000 as plain, executable code."
> >
> > Is this actually true of modern x86-64 kernels? We've locked down W^X
> > protections in general.
>
> 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 by mapping the entire region
> as “readable, writeable, and executable” (RWX)—only very recent kernels
> (≥v3.9) use the more conservative RW mapping.”
But v3.8.13 is a 5+ years old kernel, it doesn't count as a "modern"
kernel in any sense of the word. For any proposed patchset with
significant complexity and non-trivial costs the benchmark version
threshold is the "current upstream kernel".
So does that quote address my followup questions:
> Is this actually true of modern x86-64 kernels? We've locked down W^X
> protections in general.
>
> I.e. this conclusion:
>
> "Therefore, by simply overwriting kfptr with 0xFFFF87FF9F080000 and
> triggering the kernel to dereference it, an attacker can directly
> execute shell code with kernel privileges."
>
> ... appears to be predicated on imperfect W^X protections on the x86-64
> kernel.
>
> Do such holes exist on the latest x86-64 kernel? If yes, is there a
> reason to believe that these W^X holes cannot be fixed, or that any fix
> would be more expensive than XPFO?
?
What you are proposing here is a XPFO patch-set against recent kernels
with significant runtime overhead, so my questions about the W^X holes
are warranted.
Thanks,
Ingo
On 4/17/19 11:09 AM, Ingo Molnar wrote:
>
> * Khalid Aziz <[email protected]> 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 Ingo,
>>
>> That is a good question. Because of the cost of XPFO, we have to be very
>> sure we need this protection. The paper from Vasileios, Michalis and
>> Angelos - <http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf>,
>> does go into how ret2dir attacks can bypass SMAP/SMEP in sections 6.1
>> and 6.2.
>
> So it would be nice if you could generally summarize external arguments
> when defending a patchset, instead of me having to dig through a PDF
> which not only causes me to spend time that you probably already spent
> reading that PDF, but I might also interpret it incorrectly. ;-)
Sorry, you are right. Even though that paper explains it well, a summary
is always useful.
>
> The PDF you cited says this:
>
> "Unfortunately, as shown in Table 1, the W^X prop-erty is not enforced
> in many platforms, including x86-64. In our example, the content of
> user address 0xBEEF000 is also accessible through kernel address
> 0xFFFF87FF9F080000 as plain, executable code."
>
> Is this actually true of modern x86-64 kernels? We've locked down W^X
> protections in general.
>
> I.e. this conclusion:
>
> "Therefore, by simply overwriting kfptr with 0xFFFF87FF9F080000 and
> triggering the kernel to dereference it, an attacker can directly
> execute shell code with kernel privileges."
>
> ... appears to be predicated on imperfect W^X protections on the x86-64
> kernel.
>
> Do such holes exist on the latest x86-64 kernel? If yes, is there a
> reason to believe that these W^X holes cannot be fixed, or that any fix
> would be more expensive than XPFO?
Even if physmap is not executable, return-oriented programming (ROP) can
still be used to launch an attack. Instead of placing executable code at
user address 0xBEEF000, attacker can place an ROP payload there. kfptr
is then overwritten to point to a stack-pivoting gadget. Using the
physmap address aliasing, the ROP payload becomes kernel-mode stack. The
execution can then be hijacked upon execution of ret instruction. This
is a gist of the subsection titled "Non-executable physmap" under
section 6.2 and it looked convincing enough to me. If you have a
different take on this, I am very interested in your point of view.
Thanks,
Khalid
> On Apr 17, 2019, at 10:26 AM, Ingo Molnar <[email protected]> wrote:
>
>
> * Nadav Amit <[email protected]> wrote:
>
>>> On Apr 17, 2019, at 10:09 AM, Ingo Molnar <[email protected]> wrote:
>>>
>>>
>>> * Khalid Aziz <[email protected]> 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 Ingo,
>>>>
>>>> That is a good question. Because of the cost of XPFO, we have to be very
>>>> sure we need this protection. The paper from Vasileios, Michalis and
>>>> Angelos - <http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf>,
>>>> does go into how ret2dir attacks can bypass SMAP/SMEP in sections 6.1
>>>> and 6.2.
>>>
>>> So it would be nice if you could generally summarize external arguments
>>> when defending a patchset, instead of me having to dig through a PDF
>>> which not only causes me to spend time that you probably already spent
>>> reading that PDF, but I might also interpret it incorrectly. ;-)
>>>
>>> The PDF you cited says this:
>>>
>>> "Unfortunately, as shown in Table 1, the W^X prop-erty is not enforced
>>> in many platforms, including x86-64. In our example, the content of
>>> user address 0xBEEF000 is also accessible through kernel address
>>> 0xFFFF87FF9F080000 as plain, executable code."
>>>
>>> Is this actually true of modern x86-64 kernels? We've locked down W^X
>>> protections in general.
>>
>> 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 by mapping the entire region
>> as “readable, writeable, and executable” (RWX)—only very recent kernels
>> (≥v3.9) use the more conservative RW mapping.”
>
> But v3.8.13 is a 5+ years old kernel, it doesn't count as a "modern"
> kernel in any sense of the word. For any proposed patchset with
> significant complexity and non-trivial costs the benchmark version
> threshold is the "current upstream kernel".
>
> So does that quote address my followup questions:
>
>> Is this actually true of modern x86-64 kernels? We've locked down W^X
>> protections in general.
>>
>> I.e. this conclusion:
>>
>> "Therefore, by simply overwriting kfptr with 0xFFFF87FF9F080000 and
>> triggering the kernel to dereference it, an attacker can directly
>> execute shell code with kernel privileges."
>>
>> ... appears to be predicated on imperfect W^X protections on the x86-64
>> kernel.
>>
>> Do such holes exist on the latest x86-64 kernel? If yes, is there a
>> reason to believe that these W^X holes cannot be fixed, or that any fix
>> would be more expensive than XPFO?
>
> ?
>
> What you are proposing here is a XPFO patch-set against recent kernels
> with significant runtime overhead, so my questions about the W^X holes
> are warranted.
>
Just to clarify - I am an innocent bystander and have no part in this work.
I was just looking (again) at the paper, as I was curious due to the recent
patches that I sent that improve W^X protection.
On Wed, Apr 17, 2019 at 10:33 AM Khalid Aziz <[email protected]> wrote:
>
> On 4/17/19 11:09 AM, Ingo Molnar wrote:
> >
> > * Khalid Aziz <[email protected]> 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 Ingo,
> >>
> >> That is a good question. Because of the cost of XPFO, we have to be very
> >> sure we need this protection. The paper from Vasileios, Michalis and
> >> Angelos - <http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf>,
> >> does go into how ret2dir attacks can bypass SMAP/SMEP in sections 6.1
> >> and 6.2.
> >
> > So it would be nice if you could generally summarize external arguments
> > when defending a patchset, instead of me having to dig through a PDF
> > which not only causes me to spend time that you probably already spent
> > reading that PDF, but I might also interpret it incorrectly. ;-)
>
> Sorry, you are right. Even though that paper explains it well, a summary
> is always useful.
>
> >
> > The PDF you cited says this:
> >
> > "Unfortunately, as shown in Table 1, the W^X prop-erty is not enforced
> > in many platforms, including x86-64. In our example, the content of
> > user address 0xBEEF000 is also accessible through kernel address
> > 0xFFFF87FF9F080000 as plain, executable code."
> >
> > Is this actually true of modern x86-64 kernels? We've locked down W^X
> > protections in general.
> >
> > I.e. this conclusion:
> >
> > "Therefore, by simply overwriting kfptr with 0xFFFF87FF9F080000 and
> > triggering the kernel to dereference it, an attacker can directly
> > execute shell code with kernel privileges."
> >
> > ... appears to be predicated on imperfect W^X protections on the x86-64
> > kernel.
> >
> > Do such holes exist on the latest x86-64 kernel? If yes, is there a
> > reason to believe that these W^X holes cannot be fixed, or that any fix
> > would be more expensive than XPFO?
>
> Even if physmap is not executable, return-oriented programming (ROP) can
> still be used to launch an attack. Instead of placing executable code at
> user address 0xBEEF000, attacker can place an ROP payload there. kfptr
> is then overwritten to point to a stack-pivoting gadget. Using the
> physmap address aliasing, the ROP payload becomes kernel-mode stack. The
> execution can then be hijacked upon execution of ret instruction. This
> is a gist of the subsection titled "Non-executable physmap" under
> section 6.2 and it looked convincing enough to me. If you have a
> different take on this, I am very interested in your point of view.
My issue with all this is that XPFO is really very expensive. I think
that, if we're going to seriously consider upstreaming expensive
exploit mitigations like this, we should consider others first, in
particular CFI techniques. grsecurity's RAP would be a great start.
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 quite a bit harder.
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 quite a bit harder.
I've been playing around with this for a bit, and hope to have
something to post Soon :)
Tycho
On 4/17/19 1:49 PM, Andy Lutomirski wrote:
> On Wed, Apr 17, 2019 at 10:33 AM Khalid Aziz <[email protected]> wrote:
>>
>> On 4/17/19 11:09 AM, Ingo Molnar wrote:
>>>
>>> * Khalid Aziz <[email protected]> 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 Ingo,
>>>>
>>>> That is a good question. Because of the cost of XPFO, we have to be very
>>>> sure we need this protection. The paper from Vasileios, Michalis and
>>>> Angelos - <http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf>,
>>>> does go into how ret2dir attacks can bypass SMAP/SMEP in sections 6.1
>>>> and 6.2.
>>>
>>> So it would be nice if you could generally summarize external arguments
>>> when defending a patchset, instead of me having to dig through a PDF
>>> which not only causes me to spend time that you probably already spent
>>> reading that PDF, but I might also interpret it incorrectly. ;-)
>>
>> Sorry, you are right. Even though that paper explains it well, a summary
>> is always useful.
>>
>>>
>>> The PDF you cited says this:
>>>
>>> "Unfortunately, as shown in Table 1, the W^X prop-erty is not enforced
>>> in many platforms, including x86-64. In our example, the content of
>>> user address 0xBEEF000 is also accessible through kernel address
>>> 0xFFFF87FF9F080000 as plain, executable code."
>>>
>>> Is this actually true of modern x86-64 kernels? We've locked down W^X
>>> protections in general.
>>>
>>> I.e. this conclusion:
>>>
>>> "Therefore, by simply overwriting kfptr with 0xFFFF87FF9F080000 and
>>> triggering the kernel to dereference it, an attacker can directly
>>> execute shell code with kernel privileges."
>>>
>>> ... appears to be predicated on imperfect W^X protections on the x86-64
>>> kernel.
>>>
>>> Do such holes exist on the latest x86-64 kernel? If yes, is there a
>>> reason to believe that these W^X holes cannot be fixed, or that any fix
>>> would be more expensive than XPFO?
>>
>> Even if physmap is not executable, return-oriented programming (ROP) can
>> still be used to launch an attack. Instead of placing executable code at
>> user address 0xBEEF000, attacker can place an ROP payload there. kfptr
>> is then overwritten to point to a stack-pivoting gadget. Using the
>> physmap address aliasing, the ROP payload becomes kernel-mode stack. The
>> execution can then be hijacked upon execution of ret instruction. This
>> is a gist of the subsection titled "Non-executable physmap" under
>> section 6.2 and it looked convincing enough to me. If you have a
>> different take on this, I am very interested in your point of view.
>
> My issue with all this is that XPFO is really very expensive. I think
> that, if we're going to seriously consider upstreaming expensive
> exploit mitigations like this, we should consider others first, in
> particular CFI techniques. grsecurity's RAP would be a great start.
> 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 quite a bit harder.
>
Yes, XPFO is expensive. I have been able to reduce the overhead of XPFO
from 2537% to 28% (on large servers) but 28% is still quite significant.
Alternative mitigation techniques with lower impact would easily be more
acceptable as long as they provide same level of protection. If we have
to go with XPFO, we will continue to look for more performance
improvement to bring that number down further from 28%. Hopefully what
Tycho is working on will yield better results. I am continuing to look
for improvements to XPFO in parallel.
Thanks,
Khalid
On Wed, 17 Apr 2019, Nadav Amit wrote:
> > On Apr 17, 2019, at 10:26 AM, Ingo Molnar <[email protected]> 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 by mapping the entire region
> >> as “readable, writeable, and executable” (RWX)—only very recent kernels
> >> (≥v3.9) use the more conservative RW mapping.”
> >
> > But v3.8.13 is a 5+ years old kernel, it doesn't count as a "modern"
> > kernel in any sense of the word. For any proposed patchset with
> > significant complexity and non-trivial costs the benchmark version
> > threshold is the "current upstream kernel".
> >
> > So does that quote address my followup questions:
> >
> >> Is this actually true of modern x86-64 kernels? We've locked down W^X
> >> protections in general.
> >>
> >> I.e. this conclusion:
> >>
> >> "Therefore, by simply overwriting kfptr with 0xFFFF87FF9F080000 and
> >> triggering the kernel to dereference it, an attacker can directly
> >> execute shell code with kernel privileges."
> >>
> >> ... appears to be predicated on imperfect W^X protections on the x86-64
> >> kernel.
> >>
> >> Do such holes exist on the latest x86-64 kernel? If yes, is there a
> >> reason to believe that these W^X holes cannot be fixed, or that any fix
> >> would be more expensive than XPFO?
> >
> > ?
> >
> > What you are proposing here is a XPFO patch-set against recent kernels
> > with significant runtime overhead, so my questions about the W^X holes
> > are warranted.
> >
>
> Just to clarify - I am an innocent bystander and have no part in this work.
> I was just looking (again) at the paper, as I was curious due to the recent
> patches that I sent that improve W^X protection.
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!
Thanks,
tglx
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
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2997,6 +2997,12 @@
>
> nox2apic [X86-64,APIC] Do not enable x2APIC mode.
>
> + noxpfo [XPFO] Disable eXclusive Page Frame Ownership (XPFO)
> + when CONFIG_XPFO is on. Physical pages mapped into
> + user applications will also be mapped in the
> + kernel's address space as if CONFIG_XPFO was not
> + enabled.
> +
> cpu0_hotplug [X86] Turn on CPU0 hotplug feature when
> CONFIG_BO OTPARAM_HOTPLUG_CPU0 is off.
> Some features depend on CPU0. Known dependencies are:
Given the big performance impact that XPFO can have. It should be off by
default when configured. Instead, the xpfo option should be used to
enable it.
Cheers,
Longman
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
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2997,6 +2997,12 @@
>>
>> nox2apic [X86-64,APIC] Do not enable x2APIC mode.
>>
>> + noxpfo [XPFO] Disable eXclusive Page Frame Ownership (XPFO)
>> + when CONFIG_XPFO is on. Physical pages mapped into
>> + user applications will also be mapped in the
>> + kernel's address space as if CONFIG_XPFO was not
>> + enabled.
>> +
>> cpu0_hotplug [X86] Turn on CPU0 hotplug feature when
>> CONFIG_BO OTPARAM_HOTPLUG_CPU0 is off.
>> Some features depend on CPU0. Known dependencies are:
>
> Given the big performance impact that XPFO can have. It should be off by
> default when configured. Instead, the xpfo option should be used to
> enable it.
Agreed. I plan to disable it by default in the next version of the
patch. This is likely to end up being a feature for extreme security
conscious folks only, unless I or someone else comes up with further
significant performance boost.
Thanks,
Khalid