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
| ||
|
Date: Fri, 25 Apr 2008 14:02:07 -0700 (PDT) From: David Miller <davem@...emloft.net> To: hpa@...or.com 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 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. :-/ -- 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/
Powered by blists - more mailing lists