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: <48124901.90800@zytor.com>
Date:	Fri, 25 Apr 2008 14:11:29 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	David Miller <davem@...emloft.net>
CC:	mathieu.desnoyers@...ymtl.ca, andi@...stfloor.org,
	torvalds@...ux-foundation.org, mingo@...e.hu, jirislaby@...il.com,
	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@...p.org
Subject: Re: [PATCH 1/1] x86: fix text_poke

David Miller wrote:
> From: "H. Peter Anvin" <hpa@...or.com>
> Date: Fri, 25 Apr 2008 13:41:00 -0700
> 
>> Yes, that should work.  It's still ugly, and I have to say I find the 
>> complexity rather distasteful.  I am willing to be convinced it's worth 
>> it, but I would really like to see hard numbers.
> 
> This stuff would have been a lot easier if it just worked with
> normal relocations generated by the assembler, and that would
> work in such a straightforward way on EVERY architecture.
> 
> The immediate instance generators could just use macros that
> architectures define, which are given a range of legal values for the
> immediate, and the macro emits the inline asm sequence that can
> support an immediate value of that range.
> 
> Then we do a half-link of the kernel, collect the unresolved
> relocations from generated by the immediate macros into a table which
> gets linked into the kernel, then resolve them in the final link all
> to zero or some defined initial value.
> 
> Then it's just a matter of running through the relocation handling
> we already have for module loading when changing an immediate
> value.
> 
> None of this crazy instruction parsing and branch following crap.
> I can't believe we're seriously considering this crud. :-/

That's already there, for all practical purposes.  The point of 
contention here is trying to go from immediate value rewriting to branch 
rewriting, which is probably the vast majority of all desired uses. 
However, branch rewriting affects the flow of control, and flow of 
control is inherently vital for gcc to understand.

I'm not inherently opposed to branch target rewriting, but I believe gcc 
really needs to be involved in the process.  On systems compiled with 
older compilers, we just won't use that feature -- similar to most other 
features introduced in a new compiler.

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