linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Dexuan Cui <decui@microsoft.com>, vkuznets <vkuznets@redhat.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Andy Lutomirski <luto@kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Michael Kelley <mikelley@microsoft.com>,
	Ju-Hyoung Lee <juhlee@microsoft.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	KY Srinivasan <kys@microsoft.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: hv_hypercall_pg page permissios
Date: Tue, 16 Jun 2020 12:18:07 +0200	[thread overview]
Message-ID: <20200616101807.GO2531@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200616072318.GA17600@lst.de>

On Tue, Jun 16, 2020 at 09:23:18AM +0200, Christoph Hellwig wrote:
> On Mon, Jun 15, 2020 at 07:49:41PM +0000, Dexuan Cui wrote:
> > I did this experiment:
> >   1. export vmalloc_exec and ptdump_walk_pgd_level_checkwx.
> >   2. write a test module that calls them.
> >   3. It turns out that every call of vmalloc_exec() triggers such a warning.
> > 
> > vmalloc_exec() uses PAGE_KERNEL_EXEC, which is defined as
> >    (__PP|__RW|   0|___A|   0|___D|   0|___G)
> > 
> > It looks the logic in note_page() is: for_each_RW_page, if the NX bit is unset,
> > then report the page as an insecure W+X mapping. IMO this explains the
> > warning?
> 
> It does.  But it also means every other user of PAGE_KERNEL_EXEC
> should trigger this, of which there are a few (kexec, tboot, hibernate,
> early xen pv mapping, early SEV identity mapping)

There are only 3 users in the entire tree afaict:

arch/arm64/kernel/probes/kprobes.c:     page = vmalloc_exec(PAGE_SIZE);
arch/x86/hyperv/hv_init.c:      hv_hypercall_pg = vmalloc_exec(PAGE_SIZE);
kernel/module.c:        return vmalloc_exec(size);

And that last one is a weak function that any arch that has STRICT_RWX
ought to override.

> We really shouldn't create mappings like this by default.  Either we
> need to flip PAGE_KERNEL_EXEC itself based on the needs of the above
> users, or add another define to overload vmalloc_exec as there is no
> other user of that for x86.

We really should get rid of the two !module users of this though; both
x86 and arm64 have STRICT_RWX and sufficient primitives to DTRT.

What is HV even trying to do with that page? AFAICT it never actually
writes to it, it seens to give the physica address to an MSR (which I
suspect then writes crud into the page for us from host context).

Suggesting the page really only needs to be RX.

On top of that, vmalloc_exec() gets us a page from the entire vmalloc
range, which can be outside of the 2G executable range, which seems to
suggest vmalloc_exec() is wrong too and all this works by accident.

How about something like this:


diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index a54c6a401581..82a3a4a9481f 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -375,12 +375,15 @@ 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_exec(PAGE_SIZE);
+	hv_hypercall_pg = module_alloc(PAGE_SIZE);
 	if (hv_hypercall_pg == NULL) {
 		wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
 		goto remove_cpuhp_state;
 	}
 
+	set_memory_ro((unsigned long)hv_hypercall_pg, 1);
+	set_memory_x((unsigned long)hv_hypercall_pg, 1);
+
 	rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
 	hypercall_msr.enable = 1;
 	hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);

  reply	other threads:[~2020-06-16 10:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-07  6:55 hv_hypercall_pg page permissios Christoph Hellwig
2020-04-07  7:28 ` Vitaly Kuznetsov
2020-04-07  7:38   ` Christoph Hellwig
2020-04-07 21:01     ` Andy Lutomirski
2020-06-12  7:48       ` Dexuan Cui
2020-06-15  8:35         ` Vitaly Kuznetsov
2020-06-15 17:41           ` Dexuan Cui
2020-06-15 19:49             ` Dexuan Cui
2020-06-16  7:23               ` Christoph Hellwig
2020-06-16 10:18                 ` Peter Zijlstra [this message]
2020-06-16 10:23                   ` Christoph Hellwig
2020-06-16 10:24                     ` Christoph Hellwig
2020-06-16 10:31                       ` Peter Zijlstra
2020-06-16 10:33                         ` Christoph Hellwig
2020-06-16 10:40                           ` Peter Zijlstra
2020-06-16 10:42                             ` Christoph Hellwig
2020-06-16 10:52                               ` Christoph Hellwig
2020-06-16 11:24                                 ` Peter Zijlstra
2020-06-16 14:39                                   ` Christoph Hellwig
2020-06-16  9:29               ` Vitaly Kuznetsov
2020-06-16  9:33                 ` Christoph Hellwig
2020-06-16  9:55                   ` Christoph Hellwig
2020-06-16 10:08                     ` Christoph Hellwig
2020-06-16 10:50                       ` Vitaly Kuznetsov
2020-06-16 10:20                     ` Peter Zijlstra
2020-04-07 18:10   ` Dexuan Cui
2020-04-07 20:42     ` Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200616101807.GO2531@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=decui@microsoft.com \
    --cc=hch@lst.de \
    --cc=juhlee@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mikelley@microsoft.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas.lendacky@amd.com \
    --cc=vkuznets@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).