linux-kernel - Re: [PATCH] ftrace: use only 5 byte nops for x86

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, 15 Aug 2008 15:50:22 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Roland McGrath <roland@...hat.com>,
	Ulrich Drepper <drepper@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Gregory Haskins <ghaskins@...ell.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	"Luis Claudio R. Goncalves" <lclaudio@...g.org>,
	Clark Williams <williams@...hat.com>, srostedt@...hat.com
Subject: Re: [PATCH] ftrace: use only 5 byte nops for x86

Linus Torvalds wrote:
> I also suspect that we'd really be much better off just fixing the generic 
> NOP tables for the 5-byte nop. As far as I could tell, from all the 
> numbers that have been posted, absolutely _none_ show that there is any 
> point at all to the 2-instruction 3/2-byte sequence.
>
> So instead of having a magic special ftrace-only thing, why not just do it 
> right, and fix the generic 5-byte nop sequence?
>   

Well, there's two distinct issues here.  There's the need for a
single-instruction 5 byte nop, and the need for efficient nops.  It so
happens in this case that they're the same thing.  But in general, the
generic nop interface is intended to return the most efficient nop, not
an atomic nop (or with any other properties).  To handle it generically,
we'd either need to redefine the meaning of the existing nop-padding
interface, or add an "atomic nop" interface.

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