linux-kernel - Re: [PATCH] Add I/O hypercalls for i386 paravirt

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]

Message-ID: <20070822194632.GD8058@bingen.suse.de>
Date:	Wed, 22 Aug 2007 21:46:32 +0200
From:	Andi Kleen <ak@...e.de>
To:	Zachary Amsden <zach@...are.com>
Cc:	Andi Kleen <ak@...e.de>, Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Virtualization Mailing List <virtualization@...ts.osdl.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Chris Wright <chrisw@...s-sol.org>,
	Avi Kivity <avi@...ranet.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [PATCH] Add I/O hypercalls for i386 paravirt

On Wed, Aug 22, 2007 at 10:07:47AM -0700, Zachary Amsden wrote:
> >Also I fail to see the fundamental speed difference between
> >
> >mov index,register
> >int 0x...
> >...
> >switch (register) 
> >case xxxx: do emulation
> >  
> 
> Int (on p4 == ~680 cycles).
> 
> >versus
> >
> >out ...
> >#gp
> >-> switch (*eip) {
> >case 0xee:  /* etc. */ 
> >	do emulation
> >  
> 
> GP = ~2000 cycles.

How is that measured? In a loop? In the same pipeline state?

It seems a little dubious to me.

> 
> >>to verify protection in the page tables mapping the page allows 
> >>execution (P, !NX, and U/S check).  This is a lot more expensive than a 
> >>    
> >
> >When the page is not executable or not present you get #PF not #GP. 
> >So the hardware already checks that.
> >
> >The only case where you would need to check yourself is if you emulate
> >NX on non NX capable hardware, but I can't see you doing that.
> >  
> 
> No, it doesn't.  Between the #GP and decode, you have an SMP race where 
> another processor can rewrite the instruction.

That can be ignored imho. If the page goes away you'll notice
when you handle the page fault on read. If it becomes NX then the execution
just happened to be logically a little earlier.

My other objection to this scheme is that you'll change a zillion
drivers you'll never emulate which seems just stupid. You could
just change the small handful that you emulate to use hypercalls.

Or easier to just write a backend for the lguest virtio drivers,
that will be likely faster in the end anyways than this gross
hack.

Really LinuxHAL^wparavirt ops is already so complicated that
any new hooks need an extremly good justification and that is
just not here for this.

We can add it if you find an equivalent number of hooks
to eliminate.

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