linux-kernel - Re: Immediate values

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-next>] [day] [month] [year] [list]

Date:	Thu, 24 Sep 2009 12:29:46 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ingo Molnar <mingo@...e.hu>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:	Jason Baron <jbaron@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>, Andi Kleen <ak@...e.de>,
	linux-kernel@...r.kernel.org
Subject: Re: Immediate values

I would like to get an official ACK or NAK for this patching technique from inside Intel, and preferrably from AMD as well.  If it does work as described it would provide a very clean way to do one-shot alternative functions, which probably would be higher value than immediate data values.

Ingo Molnar <mingo@...e.hu> wrote:

>
>* Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote:
>
>> * Jason Baron (jbaron@...hat.com) wrote:
>> > 
>> > right we've proposed an alternative to the immediate values, which 
>> > I've been calling 'jump label', here:
>> > 
>> > http://marc.info/?l=linux-kernel&m=125200966226921&w=2
>> > 
>> > The basic idea is that gcc, 4.5 will have support for an 'asm goto' 
>> > construct which can refer to c code labels. Thus, we can replace a 
>> > nop in the code stream with a 'jmp' instruction to various branch 
>> > targets.
>> > 
>> > In terms of a comparison between the two, IMO, I think that the 
>> > syntax for the immediate variables can be more readable, since it 
>> > just looks like a conditional expression.
>> > 
>> > The immediate values do a 'mov', 'test' and then a jump, whereas 
>> > jump label can just do a jump. So in this respect, I believe jump 
>> > label can be more optimal. Additinally, if we want to mark sections 
>> > 'cold' so they don't impact the istruction cache, the jump label 
>> > already has the labels for doing so. Obviously, a performance 
>> > comparison would be interesting as well.
>> 
>> For branches, I'm convinced that a "static jump" approach will beat 
>> immediate values anytime, because you save the BPB hit completely.
>> 
>> However, there are other use-cases involving a variable read, and in 
>> that case immediate values are useful. Andi has been bugging me for a 
>> while to re-post this patchset, I'm pretty sure he has precise ideas 
>> about how he would like to use it.
>
>It depends on how significant that usecase is.
>
>Tracepoints used to be the biggest use-case for immediate values, and 
>without that the thing becomes rather complex to maintain, for probably 
>very little benefit.
>
>	Ingo