linux-kernel - Re: [PATCH ftrace.git] Immedate Values Optimized Jump Fix

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]

Message-ID: <4880F410.3090804@zytor.com>
Date:	Fri, 18 Jul 2008 12:50:40 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
CC:	Ingo Molnar <mingo@...e.hu>, Ingo Molnar <mingo@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH ftrace.git] Immedate Values Optimized Jump Fix

Mathieu Desnoyers wrote:
>>
>>  $ git-log-line linus.. arch/x86/kernel/immediate.c
>>  ee563d6: immediate values: jump liveliness
>>  e26875a: Immediate Values - Jump
>>  3fc8d03: Immediate Values - x86 Optimization NMI and MCE support
>>
>> ... but the topic is stalled right now, due to hpa having had 
>> objections. Have those concerns been resolved? (Peter Cc:-ed)
>>
>> i'd have applied this fix, but it does not apply. The first chunk seems 
>> already be present (in a different form), the second chunk looks much 
>> different.
> 
> Hrm, I've edited directly the immediate values: jump liveliness patches,
> which explains why it does not apply. I'll try to unapply/reapply/fold
> the patches and see what it gives.
> 
> Plus, I've noticed that the "Text Edit Lock" patches are not in the
> immediates branch, thus it fails to compile. Immediate values depends on
> the Text Edit Lock patches.
> 

My previous objection was that flow of control really does need to be 
understood by the compiler, and I don't see how that could have been 
resolved without involving gcc.

I'm not opposed to static jump optimization in general, far from it, but 
doing it behind the back of the compiler is fraught with peril, and even 
if it can be made correct is going to generate bad enough code that I 
have to question if it is worth the additional complexity.

I definitely do not approve of the attempt to truncate liveliness by 
putting a clobber after the if branch; there is still intervening code 
generated by the C compiler which is going to cause some extremely hard 
to debug problems at some point.

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