| 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
| ||
|
Message-ID: <1326984993.17534.125.camel@gandalf.stny.rr.com>
Date: Thu, 19 Jan 2012 09:56:33 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Frederic Weisbecker <fweisbec@...il.com>,
"H. Peter Anvin" <hpa@...or.com>, Jason Baron <jbaron@...hat.com>
Subject: Re: [PATCH 2/2] jump labels/x86: Use etiher 5 byte or 2 byte jumps
On Thu, 2012-01-19 at 09:41 -0500, Mathieu Desnoyers wrote:
> * Steven Rostedt (rostedt@...dmis.org) wrote:
> > From: Steven Rostedt <srostedt@...hat.com>
> >
> > Have the jump labels add a "jmp" in the assembly instead
> > of a default nop. This will cause the assembler to put in
> > either a 2 byte or 5 byte jmp depending on where the target
> > lable is.
> >
> > Then at compile time, the update_jump_label code will replace
> > the jmps with either 2 or 5 byte nops.
> >
> > On boot up, the code can be examined to see if the jump label
> > uses either a 2 or 5 byte nop and replace it.
> >
> > By allowing the jump labels to be 2 bytes, it speeds up the
> > nops, not only 2 byte nops are faster than 5 byte nops, but also
> > because it saves on cache foot print.
> >
> > text data bss dec hex filename
> > 13403667 3666856 2998272 20068795 13239bb ../nobackup/mxtest/vmlinux-old
> > 13398536 3666856 2998272 20063664 13225b0 ../nobackup/mxtest/vmlinux-new
> >
> > Converting the current v3.2 trace points saved 5,131 bytes.
> > As more places use jump labels, this will have a bigger savings.
> >
> > Signed-off-by: Steven Rostedt <rostedt@...dmis.org>
> > ---
> > arch/x86/Kconfig | 1 +
> > arch/x86/include/asm/jump_label.h | 2 +-
> > arch/x86/kernel/jump_label.c | 86 ++++++++++++++++++++++++++++++++++---
> > 3 files changed, 81 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index efb4294..b5004c1 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -61,6 +61,7 @@ config X86
> > select HAVE_ARCH_KMEMCHECK
> > select HAVE_USER_RETURN_NOTIFIER
> > select HAVE_ARCH_JUMP_LABEL
> > + select HAVE_BUILD_TIME_JUMP_LABEL
> > select HAVE_TEXT_POKE_SMP
> > select HAVE_GENERIC_HARDIRQS
> > select HAVE_SPARSE_IRQ
> > diff --git a/arch/x86/include/asm/jump_label.h b/arch/x86/include/asm/jump_label.h
> > index a32b18c..872b3e1 100644
> > --- a/arch/x86/include/asm/jump_label.h
> > +++ b/arch/x86/include/asm/jump_label.h
> > @@ -14,7 +14,7 @@
> > static __always_inline bool arch_static_branch(struct jump_label_key *key)
> > {
> > asm goto("1:"
> > - JUMP_LABEL_INITIAL_NOP
> > + "jmp %l[l_yes]\n"
>
> Is it possible that the compiler choose a jump that is not 2 or 5-byte ?
> e.g. a jmp rel16 (e9 opcode) on 32-bit x86, or any of the other
Isn't e9 the 5 byte opcode?
> instruction listed under the JMP-Jump instruction in the Intel insn
> manual ?
If it does, it will fail to compile. Look at the make_nop_x86(). It will
die if it doesn't see either a eb or e9
>
> > ".pushsection __jump_table, \"aw\" \n\t"
> > _ASM_ALIGN "\n\t"
> > _ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> > diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
> > index ea9d5f2f..d5b84de 100644
> > --- a/arch/x86/kernel/jump_label.c
> > +++ b/arch/x86/kernel/jump_label.c
> > @@ -16,12 +16,27 @@
> >
> > #ifdef HAVE_JUMP_LABEL
> >
> > +static unsigned char nop_short[] = { P6_NOP2 };
> > +
> > +/* These are the nops added at compile time */
> > +#ifdef CONFIG_X86_32
> > +static unsigned char default_nop[5] = { 0x3e, 0x8d, 0x74, 0x26, 0x00 };
> > +#else
> > +static unsigned char default_nop[5] = { 0x0f, 0x1f, 0x44, 0x00, 0x00 };
> > +#endif
> > +
> > +static int update_nops;
> > +
> > union jump_code_union {
> > char code[JUMP_LABEL_NOP_SIZE];
> > struct {
> > char jump;
> > int offset;
> > - } __attribute__((packed));
> > + } __packed;
> > + struct {
> > + char jump_short;
> > + char offset_short;
> > + } __packed;
> > };
> >
> > static void __jump_label_transform(struct jump_entry *entry,
> > @@ -29,20 +44,70 @@ static void __jump_label_transform(struct jump_entry *entry,
> > void *(*poker)(void *, const void *, size_t))
> > {
> > union jump_code_union code;
> > + unsigned char nop;
> > + unsigned char op;
> > + unsigned size;
> > + void *ip = (void *)entry->code;
> > + void *ideal = (void *)ideal_nops[NOP_ATOMIC5];
>
> "void *" should possibly be "unsigned char *" here to respect the nop
> place-holder typing.
>
> > +
> > + /* Use probe_kernel_read()? */
> > + op = *(unsigned char *)ip;
> > + nop = ideal_nops[NOP_ATOMIC5][0];
> >
> > if (type == JUMP_LABEL_ENABLE) {
> > - code.jump = 0xe9;
> > - code.offset = entry->target -
> > - (entry->code + JUMP_LABEL_NOP_SIZE);
> > - } else
> > - memcpy(&code, ideal_nops[NOP_ATOMIC5], JUMP_LABEL_NOP_SIZE);
> > + if (op == 0xe9 || op == 0xeb)
> > + /* Already enabled. Warn? */
>
> This could be caused by failure to run the link-time script, or running
> the transform twice. A warning would indeed be welcome, as this should
> never happen.
That's why I commented this :-)
-- Steve
--
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