linux-kernel - 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]

Message-ID: <48163B0D.9000700@zytor.com>
Date:	Mon, 28 Apr 2008 14:01:01 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Andi Kleen <andi@...stfloor.org>,
	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
Subject: Re: [PATCH 1/1] x86: fix text_poke

Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
>> And once we accept the static markers, we might as well make them as 
>> cheap as possible.
> 
> Sure, so long as you take "as cheap as possible" to mean cheap in both 
> implementation complexity as well as runtime cost.
> 
> I don't have any specific objections to any of the stuff that Mathieu is 
> working on, but it does worry me that each time a problem is addressed 
> it ends up being an even more subtle piece of code.  I just haven't seen 
> enough concrete justification to make me feel comfortable with it all.
> 
> It seems to me that a relatively simple implementation which allows the 
> desired tracing/marking functionality is the first step.  If that proves 
> to cause a significant performance deficit then enabled then we can work 
> out how to address it in due course.  But doing it all at once before 
> merging anything seems like overkill, particularly when we're talking 
> about specifics of gcc's codegen patterns, disassembling code fragments, 
> etc.
> 

I really feel that the latest information that has come up has indicated 
that things are really not what they should be.  They are in line, have 
a substantial probe cost, and we're messing around with how to jump 
around them.

That's not the problem.

I maintain what I said before: a call instruction (which defaults to a 
NOP), and then extract the state based on debugging info or assembler 
annotations.

As far as patchable static jumps, I can see the utility of them, but I 
don't think this project is one of them.  However, I believe the right 
way to do them is via compiler support.

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