In commit 185be15143aa ("x86/mm: Remove set_pages_x() and set_pages_nx()"),
the wrappers were removed as they did not provide a real benefit over
set_memory_x() and set_memory_nx(). This change causes a problem because
the wrappers were exported, but the underlying routines were not. As a
result, external modules that used the wrappers would need to recreate
a significant part of memory management.
Signed-off-by: Larry Finger <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Peter Zijlstra (Intel) <[email protected]>
Fixes: 185be15143aa ("x86/mm: Remove set_pages_x() and set_pages_nx()")
Cc: Ingo Molnar <[email protected]>
---
arch/x86/mm/pageattr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 0d09cc5aad61..755867fc7c19 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1885,6 +1885,7 @@ int set_memory_x(unsigned long addr, int numpages)
return change_page_attr_clear(&addr, numpages, __pgprot(_PAGE_NX), 0);
}
+EXPORT_SYMBOL(set_memory_x);
int set_memory_nx(unsigned long addr, int numpages)
{
@@ -1893,6 +1894,7 @@ int set_memory_nx(unsigned long addr, int numpages)
return change_page_attr_set(&addr, numpages, __pgprot(_PAGE_NX), 0);
}
+EXPORT_SYMBOL(set_memory_nx);
int set_memory_ro(unsigned long addr, int numpages)
{
--
2.23.0
On 9/18/19 11:45 AM, Christoph Hellwig wrote:
> On Wed, Sep 18, 2019 at 11:41:21AM -0500, Larry Finger wrote:
>> In commit 185be15143aa ("x86/mm: Remove set_pages_x() and set_pages_nx()"),
>> the wrappers were removed as they did not provide a real benefit over
>> set_memory_x() and set_memory_nx(). This change causes a problem because
>> the wrappers were exported, but the underlying routines were not. As a
>> result, external modules that used the wrappers would need to recreate
>> a significant part of memory management.
>
> And external modules do not matter for mainline decisions. In fact
> ensuring random modules can't mess with the NX state was one of the
> reasons for this patch, as that is a security issue waiting to happen.
>
Christoph,
Is there approved way for pages to be set to be executable by an external module
that would not be a security issue?
Larry
On Wed, Sep 18, 2019 at 10:50 AM Larry Finger <[email protected]> wrote:
>
> Is there approved way for pages to be set to be executable by an external module
> that would not be a security issue?
Point to what external module and why.
Honestly, the likely answer is simply "no". Why would an external
module ever need to make something executable that isn't read-only
code? That's pretty fundamental. Marking data executable is fairly
questionable these days.
Instead, what might work is to have some higher-level concept that we
actually trust, and that isn't about making data executable, but about
doing something reasonable.
See the difference? Making things executable is not ok, but perhaps a
"alternative runtime code sequence" is ok.
Linus
On 9/18/19 12:53 PM, Linus Torvalds wrote:
> On Wed, Sep 18, 2019 at 10:50 AM Larry Finger <[email protected]> wrote:
>>
>> Is there approved way for pages to be set to be executable by an external module
>> that would not be a security issue?
>
> Point to what external module and why.
>
> Honestly, the likely answer is simply "no". Why would an external
> module ever need to make something executable that isn't read-only
> code? That's pretty fundamental. Marking data executable is fairly
> questionable these days.
>
> Instead, what might work is to have some higher-level concept that we
> actually trust, and that isn't about making data executable, but about
> doing something reasonable.
>
> See the difference? Making things executable is not ok, but perhaps a
> "alternative runtime code sequence" is ok.
>
> Linus
Linus,
Yes, I do see the difference.
The external module is vboxdrv, which is part of VirtualBox. The setting of
pages to be executable appears to have been added in kernel 2.4.20.
I am now testing with the former calls to set_pages_x() and set_pages_nx()
disabled. Thus far, VMs seem to be running OK. I will contact Oracle to discuss
the matter with them and see if there is some special case that requires this
facility. If there is one, then they will need to discuss it with you and Christoph.
Larry
On Wed, Sep 18, 2019 at 11:41:21AM -0500, Larry Finger wrote:
> In commit 185be15143aa ("x86/mm: Remove set_pages_x() and set_pages_nx()"),
> the wrappers were removed as they did not provide a real benefit over
> set_memory_x() and set_memory_nx(). This change causes a problem because
> the wrappers were exported, but the underlying routines were not. As a
> result, external modules that used the wrappers would need to recreate
> a significant part of memory management.
And external modules do not matter for mainline decisions. In fact
ensuring random modules can't mess with the NX state was one of the
reasons for this patch, as that is a security issue waiting to happen.
On Wed, Sep 18, 2019 at 12:49:56PM -0500, Larry Finger wrote:
> Is there approved way for pages to be set to be executable by an external
> module that would not be a security issue?
There is approved way for modules to set kernel code executable,
because well they shouldn't. And as stated many times we do not
add interfaces for things not in mainline to start with. So as a first
step please submit your module for inclusion and then we can discuss
if it actually happens to be a valid use case or not, and how to best
accomodate it.
On Wed, Sep 18, 2019 at 01:17:13PM -0500, Larry Finger wrote:
> The external module is vboxdrv, which is part of VirtualBox. The setting of
> pages to be executable appears to have been added in kernel 2.4.20.
>
> I am now testing with the former calls to set_pages_x() and set_pages_nx()
> disabled. Thus far, VMs seem to be running OK. I will contact Oracle to
> discuss the matter with them and see if there is some special case that
> requires this facility. If there is one, then they will need to discuss it
> with you and Christoph.
Well, in this case the API is called /dev/kvm. There is really
absolutely no reason for anyone badly reinventing the low-level
VT and SVM code when they can just use the kernel kvm support, which
already has at least half a dozen users.