From: Vitaly Kuznetsov <vkuznets@redhat.com>
Sent: Monday, June 15, 2020 1:35 AM
Dexuan Cui [off-list ref] writes:

quoted

quoted

From: linux-hyperv-owner@vger.kernel.org
[off-list ref] On Behalf Of Andy Lutomirski
Sent: Tuesday, April 7, 2020 2:01 PM

quoted

On Apr 7, 2020, at 12:38 AM, Christoph Hellwig [off-list ref] wrote:

On Tue, Apr 07, 2020 at 09:28:01AM +0200, Vitaly Kuznetsov wrote:

quoted

Christoph Hellwig [off-list ref] writes:

quoted

Hi all,

The x86 Hyper-V hypercall page (hv_hypercall_pg) is the only allocation
in the kernel using __vmalloc with exectutable persmissions, and the
only user of PAGE_KERNEL_RX.  Is there any good reason it needs to
be readable?  Otherwise we could use vmalloc_exec and kill off
PAGE_KERNEL_RX.  Note that before 372b1e91343e6 ("drivers: hv:

Turn

quoted

quoted

off

quoted

quoted

quoted

write permission on the hypercall page") it was even mapped writable..

[There is nothing secret in the hypercall page, by reading it you can
figure out if you're running on Intel or AMD (VMCALL/VMMCALL) but it's
likely not the only possible way :-)]

I see no reason for hv_hypercall_pg to remain readable. I just
smoke-tested

Thanks, I have the same in my WIP tree, but just wanted to confirm this
makes sense.

Just to make sure we’re all on the same page: x86 doesn’t normally have

an

quoted

quoted

execute-only mode. Executable memory in the kernel is readable unless you
are using fancy hypervisor-based XO support.

Hi hch,
The patch is merged into the mainine recently, but unluckily we noticed
a warning with CONFIG_DEBUG_WX=y (it looks typically this config is defined
by default in Linux distros, at least in Ubuntu 18.04's
/boot/config-4.18.0-11-generic).

Should we revert this patch, or figure out a way to ask the DEBUG_WX code

to

quoted

ignore this page?

Are you sure it is hv_hypercall_pg? 

Yes, 100% sure. I printed the value of hv_hypercall_pg and and it matched the
address in the warning line " x86/mm: Found insecure W+X mapping at address".

AFAIU it shouldn't be W+X as we
are allocating it with vmalloc_exec(). In other words, if you revert
78bb17f76edc, does the issue go away?

Vitaly

Yes, the warning goes away if I revert
78bb17f76edc ("x86/hyperv: use vmalloc_exec for the hypercall page")
88dca4ca5a93 ("mm: remove the pgprot argument to __vmalloc") 
(I have to revert the second as well with some manual adjustments, since
__vmalloc() has 2 parameters now.)

Thanks,
Dexuan