linux-ext4 - Re: [PATCH 1/1] x86: fix text

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:	Fri, 25 Apr 2008 11:47:42 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:	Andi Kleen <andi@...stfloor.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Jiri Slaby <jirislaby@...il.com>,
	David Miller <davem@...emloft.net>, zdenek.kabelac@...il.com,
	rjw@...k.pl, paulmck@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
	linux-ext4@...r.kernel.org, herbert@...dor.apana.org.au,
	penberg@...helsinki.fi, clameter@....com,
	linux-kernel@...r.kernel.org, pageexec@...email.hu,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [PATCH 1/1] x86: fix text_poke

Mathieu Desnoyers wrote:
> 
> Thinking about it, there could be a way to insure limited ZF and %al
> liveliness: adding an epilogue to the expected instruction sequence
> formed by an asm statement which clobbers the flags (flags are clobbered
> in any asm statement on x86) and clobbers %al.
> 
> From that point, we just have to find a specific signature that gcc
> could not imitate to put in this asm statement, so we can detect if
> other instructions have been placed in the middle of our sequence by
> gcc. Actually, I think the best thing to do with this asm statement is
> to put the instruction pointer in a special section, so we know that
> this code location marks the end of ZF and %al liveliness. There would
> be therefore no added code, just asm constraints.
> 
> This epilogue should then be used on both branches of the condition,
> like this :
> 
> if (unlikely(imv_cond(var))) {
>   imv_cond_end();
>   ...
> } else {
>   imv_cond_end();
>    ...
> }
> 

[...]

> 
> Does it make sense ?
> 

I don't think so.  You're making way too many assumptions about the code 
generated by gcc.

This kind of stuff absolutely can be done, *BUT* it requires the 
cooperation of the compiler.  The right way to do this is to negotiate a 
set of appropriate builtins with the gcc people, and use them.  This 
means this optimization will only work when compiled with the new gcc, 
so there is a substantial lag, but it's the only sane way to do this 
kind of stuff.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html