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 19:06:46 +0100
From:	"Alexander van Heukelum" <heukelum@...tmail.fm>
To:	"Andi Kleen" <andi@...stfloor.org>,
	"Cyrill Gorcunov" <gorcunov@...il.com>
Cc:	"Alexander van Heukelum" <heukelum@...lshack.com>,
	"LKML" <linux-kernel@...r.kernel.org>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, lguest@...abs.org,
	jeremy@...source.com, "Steven Rostedt" <srostedt@...hat.com>,
	"Mike Travis" <travis@....com>, "Andi Kleen" <andi@...stfloor.org>
Subject: Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

On Tue, 4 Nov 2008 18:05:01 +0100, "Andi Kleen" <andi@...stfloor.org>
said:
> > not taking into account the cost of cs reading (which I
> > don't suspect to be that expensive apart from writting,
> 
> GDT accesses have an implied LOCK prefix. Especially
> on some older CPUs that could be slow.
> 
> I don't know if it's a problem or not but it would need
> some careful benchmarking on different systems to make sure interrupt 
> latencies are not impacted.

That's good to know. I assume this LOCKed bus cycle only occurs
if the (hidden) segment information is not cached in some way?
How many segments are typically cached? In particular, does it
optimize switching between two segments?

> Another reason I would be also careful with this patch is that
> it will likely trigger slow paths in JITs like qemu/vmware/etc.

Software can be fixed ;).

> Also code segment switching is likely not something that
> current and future micro architectures will spend a lot of time
> optimizing.
> 
> I'm not sure that risk is worth the small improvement in code
> size.

I think it is worth exploring a bit more. I feel it should be
a neutral change worst-case performance-wise, but I really
think the new code is more readable/understandable.

> An alternative BTW to having all the stubs in the executable
> would be to just dynamically generate them when the interrupt
> is set up. Then you would only have the stubs around for the 
> interrupts which are actually used.

I was trying to simplify things, not make it even less
transparent ;).

> -Andi
-- 
  Alexander van Heukelum
  heukelum@...tmail.fm

-- 
http://www.fastmail.fm - A no graphics, no pop-ups email service

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