linux-kernel - Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

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:	Tue, 04 Nov 2008 12:02:14 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Alexander van Heukelum <heukelum@...lshack.com>,
	LKML <linux-kernel@...r.kernel.org>, heukelum@...tmail.fm,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, lguest@...abs.org,
	jeremy@...source.com, Steven Rostedt <srostedt@...hat.com>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Mike Travis <travis@....com>,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

Ingo Molnar wrote:
> .. which we were able to avoid before. A couple of segment register 
> accesses, shifts, etc to calculate the vector - each of which can be 
> quite costly (especially the segment register access - this is a 
> relatively rare instruction pattern).
>
> I'm not unconvicable, but we need to be conservative here: could you 
> try to measure the full before/after cost of IRQ entry, to the cycle 
> level? I'm curious what the performance impact is.
>
> Also, this makes life probably a bit harder for Xen, which assumes 
> that the GDT of the guest OS is small-ish. (Jeremy Cc:-ed)
>   

It doesn't increase the GDT to more than one page, so there's no issue 
there.  The only reason the GDT uses a whole page is because of Xen's 
requirements anyway, so if we can make good use of the rest of the 
entries, so much the better.

The other possible concern with Xen is whether Xen will properly load an 
arbitrary %cs on exception entry, or if it always loads KERNEL_CS; looks 
like it will load any %cs, so we should be fine there.

Overall the patch looks good.  Saving a segment register should be much 
faster than loading it, so I don't think the %cs read on entry should 
cost too much, but reloading %cs with KERNEL_CS might be a bit more of a 
cost (or does it run the whole exception with the new %cs?).

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