On Tue, Apr 07, 2020 at 06:10:42PM +0000, Dexuan Cui wrote: > > From: linux-hyperv-owner@xxxxxxxxxxxxxxx > > <linux-hyperv-owner@xxxxxxxxxxxxxxx> On Behalf Of Vitaly Kuznetsov > > Sent: Tuesday, April 7, 2020 12:28 AM > > Christoph Hellwig <hch@xxxxxx> writes: > > > > > 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 > > off > > > 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 > > > > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c > > index 7581cab74acb..17845db67fe2 100644 > > --- a/arch/x86/hyperv/hv_init.c > > +++ b/arch/x86/hyperv/hv_init.c > > @@ -382,7 +382,7 @@ void __init hyperv_init(void) > > guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0); > > wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id); > > > > - hv_hypercall_pg = __vmalloc(PAGE_SIZE, GFP_KERNEL, > > PAGE_KERNEL_RX); > > + hv_hypercall_pg = vmalloc_exec(PAGE_SIZE); > > If we try to write into the page, Hyper-V will kill the guest immediately > by a virtual double-fault (or triple fault?), IIRC. > The guest would get injected a #GP fault in that case FWIW. Perhaps that leads to further double-fault or triple-fault. Wei.