linux-kernel - Re: [PATCH 18/25] [PATCH] turn priviled operations into macros in entry.S

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 8 Aug 2007 16:03:19 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Steven Rostedt <rostedt@...dmis.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, jeremy@...p.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, Aug 08, 2007 at 09:47:05AM -0400, Steven Rostedt wrote:
> /me working very hard to get lguest64 ready for public display
> 
> Here's a snippet from my version of core.c.  I've been thinking of ways to
> optimize it, but for now it works fine. This was done for both ring 3 and
> ring 1 lguest versions (this is the host running):
> 
> 
> 	/*
> 	 * Update the LSTAR to point to the HV syscall handler.
> 	 * Also update the fsbase if the guest uses one.
> 	 */
> 	wrmsrl(MSR_LSTAR, (unsigned long)HV_OFFSET(&lguest_syscall_trampoline));
> 
> [...]
> 	asm volatile ("pushq %2; pushq %%rsp; pushfq; pushq %3; call *%6;"
> 		      /* The stack we pushed is off by 8, due to the
> previous pushq */
> 		      "addq $8, %%rsp"

Weird stack inbalance, i'm surprised that works. %6 must be doing strange
things.

> 	/* Need to read manual, does rdmsr clear
> 	 * the top 32 bits of rax? */
> 	xor	%rax, %rax
> 
> 	movl  	$MSR_GS_BASE,%ecx
> 	rdmsr


This seems incredibly slow. Since GS changes are controlled in 
the kernel why don't you just cache them in the per cpu area? 
The only case where user can reload it is using segment
selector changes, which can be also handled.

Also why do you need the guest gs value anyways? 

You could just use your own stack and let the guest
switch to its own.

-Andi
-
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/