From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B5F8C2BB1D for ; Tue, 7 Apr 2020 20:42:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CF2BC2074B for ; Tue, 7 Apr 2020 20:42:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586292137; bh=eHcGgZ846Ryt7rh09LVZWCLBcok82M6/lo0T07EG498=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=ZKQGyxlh4SYYTMERLUfLkYmGvroyFOLwOrhmdt60pQTCCO482ZsWt1o0mRQf8kPBD p1fWfXQN+ph2aJnT30trujh40xwSkXfryj76hxcB8LwnfmXe3vVObZV6AauE+QBlR8 Qv+dR7ImTpyHtfUwWfufHo86pQ22DbWFk3P3rg+0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726426AbgDGUmP (ORCPT ); Tue, 7 Apr 2020 16:42:15 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:35034 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726365AbgDGUmP (ORCPT ); Tue, 7 Apr 2020 16:42:15 -0400 Received: by mail-wm1-f68.google.com with SMTP id r26so3280416wmh.0; Tue, 07 Apr 2020 13:42:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/+kyW4mDgVYbrX53+0yy/aJtZBiiNTJiMN1q3teN/Bg=; b=anNbNsEYurSzE6xrCEwNPSbQlO6BYjDLFtgLhqayNOahXLxt1d6078ev0yJ4D2AVwG IXASDIpYVm3wME6K5+8RHUiSbvBr0T8c82VFlBxg09efC3wVeFQcxEgIjJ/xrzL58a7H nP8D8ZzXKcKPBRPD/Oqpwidzt3Qf3sAfxuTiJ0GT6weFU96z1ccmFqq3Mr0c2/hvXpF7 H3ji4y3VsCuSEtEn+2d/fPlr575QkrJ0so+lApqqKhuO5mlq7cdxAomJomz/kRs8hUG0 R3nRrwg3oPtDS/NblBu2SIB+l4QcjhSmHJT+kHX0C3YAwSAsmUuxVI3gje4/sF0SGSWq XrqA== X-Gm-Message-State: AGi0PubRtP68G/DouNfI8DOpiKa/k5MQDoeuoO13OR7MwWZQoDAFe5tq L2r1htLl1GknOVuGpCzWz6A= X-Google-Smtp-Source: APiQypKRJ8P0Fsa153hShEIVJFf7A48GlpRok+1kr6C+mLHm9baJlhBfyOJ3pt5jmKv0OIN+ezqq4A== X-Received: by 2002:a7b:c051:: with SMTP id u17mr1022612wmc.129.1586292132710; Tue, 07 Apr 2020 13:42:12 -0700 (PDT) Received: from debian (44.142.6.51.dyn.plus.net. [51.6.142.44]) by smtp.gmail.com with ESMTPSA id d13sm32503523wrv.34.2020.04.07.13.42.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2020 13:42:11 -0700 (PDT) Date: Tue, 7 Apr 2020 21:42:09 +0100 From: Wei Liu To: Dexuan Cui Cc: vkuznets , Christoph Hellwig , "x86@kernel.org" , "linux-hyperv@vger.kernel.org" , "linux-kernel@vger.kernel.org" , KY Srinivasan , Stephen Hemminger , Andy Lutomirski , Peter Zijlstra , Wei Liu Subject: Re: hv_hypercall_pg page permissios Message-ID: <20200407204209.ji655odu7b4tt7oh@debian> References: <20200407065500.GA28490@lst.de> <87v9mblpq6.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 07, 2020 at 06:10:42PM +0000, Dexuan Cui wrote: > > From: linux-hyperv-owner@vger.kernel.org > > On Behalf Of Vitaly Kuznetsov > > Sent: Tuesday, April 7, 2020 12:28 AM > > Christoph Hellwig 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.