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]

Date:	Fri, 25 Apr 2008 15:04:51 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
cc:	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.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

On Fri, 25 Apr 2008, Mathieu Desnoyers wrote:
> 
> The point is to provide a way to dynamically enable code at runtime
> without noticeable performance impact on the system.

Quite frankly, maybe I'm a bit dense, but why don't you just recompile the 
whole original function (at run-time), load that new version of a function 
as a mini-module, and then insert a marker at the top of the old function 
that just does a "jmp replacementfunction".

That has _zero_ cost for the non-marker case, and allows you to do pretty 
much any arbitrary code changes for the marker case.

It's also a much simpler replacement.

Yeah, that "jmp replacementfunction" is five or more bytes, but you can 
trivially do the actual _replacement_ write by writing it first as a 
single-byte debug trap, and after that has been written, write the target 
address after it, and then write the first byte of the "jmp" instruction 
last. In the (very unlikely) case that another CPU hits that debug trap, 
you just fix it up in the debug handler - you only need a single datum of 
"this is where that debug trap should relocate", because you simply create 
a triial spinlock around the code-sequence that does the instruction 
rewrite.

When undoing it, just do the same thing in reverse.

Yeah, this requires you to basically recompile some function snippet when 
you insert a probe, but if that scares people, you could basically do it 
using the old code and inserting the markers and "relinking" it - avoiding 
the C compiler, and just basically have an "assembly recompiler".

And yeah, maybe you want to do without the use of modules, and you'd just 
have a memory area that is kept free for these kinds of code replacement 
issues. And you can optimize it to not recompile the whole function, but 
do it on a finer granularity if you want.

And sure, you want to really make sure that there is security in place so 
that this isn't used for rootkits, but isn't that true of pretty much 
*any* trace facility?

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