lkml.org 
[lkml]   [2020]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: hv_hypercall_pg page permissios
    On Tue, Apr 07, 2020 at 06:10:42PM +0000, Dexuan Cui wrote:
    > > From: linux-hyperv-owner@vger.kernel.org
    > > <linux-hyperv-owner@vger.kernel.org> On Behalf Of Vitaly Kuznetsov
    > > Sent: Tuesday, April 7, 2020 12:28 AM
    > > Christoph Hellwig <hch@lst.de> 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.

    \
     
     \ /
      Last update: 2020-04-07 22:43    [W:4.668 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site