[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.58.0708090813450.29847@gandalf.stny.rr.com>
Date: Thu, 9 Aug 2007 08:17:26 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Jeremy Fitzhardinge <jeremy@...p.org>
cc: Andi Kleen <andi@...stfloor.org>,
Glauber de Oliveira Costa <gcosta@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, akpm@...ux-foundation.org,
rusty@...tcorp.com.au, Ingo Molnar <mingo@...e.hu>,
chrisw@...s-sol.org, avi@...ranet.com, anthony@...emonkey.ws,
virtualization@...ts.linux-foundation.org, lguest@...abs.org
Subject: Re: [PATCH 18/25] [PATCH] turn priviled operations into macros in
entry.S
--
On Wed, 8 Aug 2007, Jeremy Fitzhardinge wrote:
> Steven Rostedt wrote:
> > /*
> > * x86 arch doesn't have an easy way to find out where
> > * gs is located. So we need to read the MSR. But first
> > * we need to save off the rcx, rax and rdx.
> >
> Why don't you store it in gs? movq %gs:my_gs_base, %rax?
Because it can't be trusted. After the swapgs, we are pointing to the RW
section of the HV. But by running the guest kernel in ring 1, we have no
protection from the guest writing into that area too. So we can't put
anything in that section and expect it to be safe after jumping to guest
code. The only trusted values, is jumping in after getting there by an
interrupt, where the hardware places the values onto the stack.
But with Andi's comments, I realized I can point the gs pointer to the
RO area. And make a constant offset that will point up into the RW area,
so we could save the stack and replace it.
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists