linux-kernel - Re: [tip:perfcounters/core] perf_counter: x86: Fix call-chain support to use NMI-safe methods

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:	Mon, 15 Jun 2009 15:16:17 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, mingo@...hat.com, hpa@...or.com,
	paulus@...ba.org, acme@...hat.com, linux-kernel@...r.kernel.org,
	a.p.zijlstra@...llo.nl, penberg@...helsinki.fi,
	vegard.nossum@...il.com, efault@....de, jeremy@...p.org,
	npiggin@...e.de, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perfcounters/core] perf_counter: x86: Fix call-chain
	support to use NMI-safe methods

* Linus Torvalds (torvalds@...ux-foundation.org) wrote:
> 
> 
> On Mon, 15 Jun 2009, Ingo Molnar wrote:
> > 
> > [ If on the other hand it's a speedup of a few cycles then we have 
> >   the problem of me suddenly liking this patch a whole lot more ;-) ]
> 
> I missed the patch.
> 
> It's quite possible that replacing "iret" with a regular "ret" (for the 
> kernel->kernel transition) is a real speedup. That said, there's a few 
> things to think about:
> 
>  - CPU return stack caches/predictors. I suspect that "iret" and 
>    exceptions don't generally touch them (but who knows - maybe they do), 
>    while a regular "ret" definitely does. I dunno about "retf".
> 

Also, I don't think popf acts as a serializing instruction. (reading the
Intel Architecture Software Developer's Manual, vol 3 System programming
section 7.4 Serializing Instructions). And ret clearly doesn't.
Therefore I'd be worried of iret serialization assumptions which could
be done within the kernel code. Maybe it would be safer to add a cpuid
or mfence instruction in there to ensure correct core serialization.

This would turn the hand-made iret into a :

popf
mfence
ret

Or something like that.

Mathieu


>    This can cause very subtle performance slowdowns, where the slowdown 
>    happens somewhere else. And it could be _very_ uarch-dependent (ie only 
>    happen on some architectures, while having no performance downside on 
>    others)
> 
>  - kernel->kernel exceptions _should_ be rare, with the exception of 
>    actual real external interrupts. So the path to optimize should always 
>    be the user-space exception path. That one will need 'iret', but I'd 
>    also not want to see more testing in that hot-path. I suspect we 
>    already always test for user-mode anyway (due to signal handling etc 
>    work), but if it adds new tests to that path, any kernel->kernel 
>    speedup is likely totally pointless.
> 
> That said, it would be nice to avoid 'iret' if only because of its subtle 
> interactions with the while NMI flag.
> 
> 		Linus

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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/