2019-05-19 20:08:55 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2012-05-22 10:50:07 +08:00
|
|
|
#define pr_fmt(fmt) "SMP alternatives: " fmt
|
|
|
|
|
2006-03-23 18:59:32 +08:00
|
|
|
#include <linux/module.h>
|
2006-10-18 13:47:25 +08:00
|
|
|
#include <linux/sched.h>
|
2008-05-13 03:21:01 +08:00
|
|
|
#include <linux/mutex.h>
|
2006-03-23 18:59:32 +08:00
|
|
|
#include <linux/list.h>
|
2009-08-19 15:40:48 +08:00
|
|
|
#include <linux/stringify.h>
|
2007-07-22 17:12:31 +08:00
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/vmalloc.h>
|
2009-03-06 23:37:22 +08:00
|
|
|
#include <linux/memory.h>
|
2010-02-25 21:34:38 +08:00
|
|
|
#include <linux/stop_machine.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2013-07-12 17:21:48 +08:00
|
|
|
#include <linux/kdebug.h>
|
2019-02-13 00:12:15 +08:00
|
|
|
#include <linux/kprobes.h>
|
2019-04-26 08:11:27 +08:00
|
|
|
#include <linux/mmu_context.h>
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
#include <linux/bsearch.h>
|
2016-04-27 03:23:24 +08:00
|
|
|
#include <asm/text-patching.h>
|
2006-03-23 18:59:32 +08:00
|
|
|
#include <asm/alternative.h>
|
|
|
|
#include <asm/sections.h>
|
2007-07-22 17:12:31 +08:00
|
|
|
#include <asm/pgtable.h>
|
2007-07-22 17:12:32 +08:00
|
|
|
#include <asm/mce.h>
|
|
|
|
#include <asm/nmi.h>
|
2008-03-06 21:48:49 +08:00
|
|
|
#include <asm/cacheflush.h>
|
2009-03-06 23:37:54 +08:00
|
|
|
#include <asm/tlbflush.h>
|
2008-03-06 21:48:49 +08:00
|
|
|
#include <asm/io.h>
|
2009-03-06 23:37:54 +08:00
|
|
|
#include <asm/fixmap.h>
|
2006-03-23 18:59:32 +08:00
|
|
|
|
2015-04-30 15:09:26 +08:00
|
|
|
int __read_mostly alternatives_patched;
|
|
|
|
|
|
|
|
EXPORT_SYMBOL_GPL(alternatives_patched);
|
|
|
|
|
2007-08-11 04:31:03 +08:00
|
|
|
#define MAX_PATCH_LEN (255-1)
|
|
|
|
|
2009-08-19 15:40:48 +08:00
|
|
|
static int __initdata_or_module debug_alternative;
|
2007-05-03 01:27:13 +08:00
|
|
|
|
2006-06-26 19:56:16 +08:00
|
|
|
static int __init debug_alt(char *str)
|
|
|
|
{
|
|
|
|
debug_alternative = 1;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("debug-alternative", debug_alt);
|
|
|
|
|
2007-07-21 23:10:25 +08:00
|
|
|
static int noreplace_smp;
|
|
|
|
|
2007-05-03 01:27:13 +08:00
|
|
|
static int __init setup_noreplace_smp(char *str)
|
|
|
|
{
|
|
|
|
noreplace_smp = 1;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("noreplace-smp", setup_noreplace_smp);
|
|
|
|
|
2014-12-31 03:27:09 +08:00
|
|
|
#define DPRINTK(fmt, args...) \
|
|
|
|
do { \
|
|
|
|
if (debug_alternative) \
|
|
|
|
printk(KERN_DEBUG "%s: " fmt "\n", __func__, ##args); \
|
2012-05-22 10:50:07 +08:00
|
|
|
} while (0)
|
2006-06-26 19:56:16 +08:00
|
|
|
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
#define DUMP_BYTES(buf, len, fmt, args...) \
|
|
|
|
do { \
|
|
|
|
if (unlikely(debug_alternative)) { \
|
|
|
|
int j; \
|
|
|
|
\
|
|
|
|
if (!(len)) \
|
|
|
|
break; \
|
|
|
|
\
|
|
|
|
printk(KERN_DEBUG fmt, ##args); \
|
|
|
|
for (j = 0; j < (len) - 1; j++) \
|
|
|
|
printk(KERN_CONT "%02hhx ", buf[j]); \
|
|
|
|
printk(KERN_CONT "%02hhx\n", buf[j]); \
|
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
|
2011-04-19 06:19:51 +08:00
|
|
|
/*
|
|
|
|
* Each GENERIC_NOPX is of X bytes, and defined as an array of bytes
|
|
|
|
* that correspond to that nop. Getting from one nop to the next, we
|
|
|
|
* add to the array the offset that is equal to the sum of all sizes of
|
|
|
|
* nops preceding the one we are after.
|
|
|
|
*
|
|
|
|
* Note: The GENERIC_NOP5_ATOMIC is at the end, as it breaks the
|
|
|
|
* nice symmetry of sizes of the previous nops.
|
|
|
|
*/
|
2009-08-19 15:40:48 +08:00
|
|
|
#if defined(GENERIC_NOP1) && !defined(CONFIG_X86_64)
|
2011-04-19 06:19:51 +08:00
|
|
|
static const unsigned char intelnops[] =
|
|
|
|
{
|
|
|
|
GENERIC_NOP1,
|
|
|
|
GENERIC_NOP2,
|
|
|
|
GENERIC_NOP3,
|
|
|
|
GENERIC_NOP4,
|
|
|
|
GENERIC_NOP5,
|
|
|
|
GENERIC_NOP6,
|
|
|
|
GENERIC_NOP7,
|
|
|
|
GENERIC_NOP8,
|
|
|
|
GENERIC_NOP5_ATOMIC
|
|
|
|
};
|
|
|
|
static const unsigned char * const intel_nops[ASM_NOP_MAX+2] =
|
|
|
|
{
|
2006-03-23 18:59:32 +08:00
|
|
|
NULL,
|
|
|
|
intelnops,
|
|
|
|
intelnops + 1,
|
|
|
|
intelnops + 1 + 2,
|
|
|
|
intelnops + 1 + 2 + 3,
|
|
|
|
intelnops + 1 + 2 + 3 + 4,
|
|
|
|
intelnops + 1 + 2 + 3 + 4 + 5,
|
|
|
|
intelnops + 1 + 2 + 3 + 4 + 5 + 6,
|
|
|
|
intelnops + 1 + 2 + 3 + 4 + 5 + 6 + 7,
|
2011-04-19 06:19:51 +08:00
|
|
|
intelnops + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8,
|
2006-03-23 18:59:32 +08:00
|
|
|
};
|
2006-06-26 19:56:16 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef K8_NOP1
|
2011-04-19 06:19:51 +08:00
|
|
|
static const unsigned char k8nops[] =
|
|
|
|
{
|
|
|
|
K8_NOP1,
|
|
|
|
K8_NOP2,
|
|
|
|
K8_NOP3,
|
|
|
|
K8_NOP4,
|
|
|
|
K8_NOP5,
|
|
|
|
K8_NOP6,
|
|
|
|
K8_NOP7,
|
|
|
|
K8_NOP8,
|
|
|
|
K8_NOP5_ATOMIC
|
|
|
|
};
|
|
|
|
static const unsigned char * const k8_nops[ASM_NOP_MAX+2] =
|
|
|
|
{
|
2006-03-23 18:59:32 +08:00
|
|
|
NULL,
|
|
|
|
k8nops,
|
|
|
|
k8nops + 1,
|
|
|
|
k8nops + 1 + 2,
|
|
|
|
k8nops + 1 + 2 + 3,
|
|
|
|
k8nops + 1 + 2 + 3 + 4,
|
|
|
|
k8nops + 1 + 2 + 3 + 4 + 5,
|
|
|
|
k8nops + 1 + 2 + 3 + 4 + 5 + 6,
|
|
|
|
k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7,
|
2011-04-19 06:19:51 +08:00
|
|
|
k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8,
|
2006-03-23 18:59:32 +08:00
|
|
|
};
|
2006-06-26 19:56:16 +08:00
|
|
|
#endif
|
|
|
|
|
2009-08-19 15:40:48 +08:00
|
|
|
#if defined(K7_NOP1) && !defined(CONFIG_X86_64)
|
2011-04-19 06:19:51 +08:00
|
|
|
static const unsigned char k7nops[] =
|
|
|
|
{
|
|
|
|
K7_NOP1,
|
|
|
|
K7_NOP2,
|
|
|
|
K7_NOP3,
|
|
|
|
K7_NOP4,
|
|
|
|
K7_NOP5,
|
|
|
|
K7_NOP6,
|
|
|
|
K7_NOP7,
|
|
|
|
K7_NOP8,
|
|
|
|
K7_NOP5_ATOMIC
|
|
|
|
};
|
|
|
|
static const unsigned char * const k7_nops[ASM_NOP_MAX+2] =
|
|
|
|
{
|
2006-03-23 18:59:32 +08:00
|
|
|
NULL,
|
|
|
|
k7nops,
|
|
|
|
k7nops + 1,
|
|
|
|
k7nops + 1 + 2,
|
|
|
|
k7nops + 1 + 2 + 3,
|
|
|
|
k7nops + 1 + 2 + 3 + 4,
|
|
|
|
k7nops + 1 + 2 + 3 + 4 + 5,
|
|
|
|
k7nops + 1 + 2 + 3 + 4 + 5 + 6,
|
|
|
|
k7nops + 1 + 2 + 3 + 4 + 5 + 6 + 7,
|
2011-04-19 06:19:51 +08:00
|
|
|
k7nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8,
|
2006-03-23 18:59:32 +08:00
|
|
|
};
|
2006-06-26 19:56:16 +08:00
|
|
|
#endif
|
|
|
|
|
2007-10-18 00:04:41 +08:00
|
|
|
#ifdef P6_NOP1
|
2012-08-22 18:03:48 +08:00
|
|
|
static const unsigned char p6nops[] =
|
2011-04-19 06:19:51 +08:00
|
|
|
{
|
|
|
|
P6_NOP1,
|
|
|
|
P6_NOP2,
|
|
|
|
P6_NOP3,
|
|
|
|
P6_NOP4,
|
|
|
|
P6_NOP5,
|
|
|
|
P6_NOP6,
|
|
|
|
P6_NOP7,
|
|
|
|
P6_NOP8,
|
|
|
|
P6_NOP5_ATOMIC
|
|
|
|
};
|
|
|
|
static const unsigned char * const p6_nops[ASM_NOP_MAX+2] =
|
|
|
|
{
|
2007-10-18 00:04:41 +08:00
|
|
|
NULL,
|
|
|
|
p6nops,
|
|
|
|
p6nops + 1,
|
|
|
|
p6nops + 1 + 2,
|
|
|
|
p6nops + 1 + 2 + 3,
|
|
|
|
p6nops + 1 + 2 + 3 + 4,
|
|
|
|
p6nops + 1 + 2 + 3 + 4 + 5,
|
|
|
|
p6nops + 1 + 2 + 3 + 4 + 5 + 6,
|
|
|
|
p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7,
|
2011-04-19 06:19:51 +08:00
|
|
|
p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8,
|
2007-10-18 00:04:41 +08:00
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
2011-04-19 06:19:51 +08:00
|
|
|
/* Initialize these to a safe default */
|
2006-06-26 19:56:16 +08:00
|
|
|
#ifdef CONFIG_X86_64
|
2011-04-19 06:19:51 +08:00
|
|
|
const unsigned char * const *ideal_nops = p6_nops;
|
|
|
|
#else
|
|
|
|
const unsigned char * const *ideal_nops = intel_nops;
|
|
|
|
#endif
|
2006-06-26 19:56:16 +08:00
|
|
|
|
2011-04-19 06:19:51 +08:00
|
|
|
void __init arch_init_ideal_nops(void)
|
2006-06-26 19:56:16 +08:00
|
|
|
{
|
2011-04-19 06:19:51 +08:00
|
|
|
switch (boot_cpu_data.x86_vendor) {
|
|
|
|
case X86_VENDOR_INTEL:
|
2011-04-19 06:31:57 +08:00
|
|
|
/*
|
|
|
|
* Due to a decoder implementation quirk, some
|
|
|
|
* specific Intel CPUs actually perform better with
|
|
|
|
* the "k8_nops" than with the SDM-recommended NOPs.
|
|
|
|
*/
|
|
|
|
if (boot_cpu_data.x86 == 6 &&
|
|
|
|
boot_cpu_data.x86_model >= 0x0f &&
|
|
|
|
boot_cpu_data.x86_model != 0x1c &&
|
|
|
|
boot_cpu_data.x86_model != 0x26 &&
|
|
|
|
boot_cpu_data.x86_model != 0x27 &&
|
|
|
|
boot_cpu_data.x86_model < 0x30) {
|
|
|
|
ideal_nops = k8_nops;
|
|
|
|
} else if (boot_cpu_has(X86_FEATURE_NOPL)) {
|
2011-04-19 06:19:51 +08:00
|
|
|
ideal_nops = p6_nops;
|
|
|
|
} else {
|
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
ideal_nops = k8_nops;
|
|
|
|
#else
|
|
|
|
ideal_nops = intel_nops;
|
|
|
|
#endif
|
|
|
|
}
|
2012-07-25 23:28:19 +08:00
|
|
|
break;
|
2015-05-11 16:15:46 +08:00
|
|
|
|
2018-09-23 17:35:01 +08:00
|
|
|
case X86_VENDOR_HYGON:
|
|
|
|
ideal_nops = p6_nops;
|
|
|
|
return;
|
|
|
|
|
2015-05-11 16:15:46 +08:00
|
|
|
case X86_VENDOR_AMD:
|
|
|
|
if (boot_cpu_data.x86 > 0xf) {
|
|
|
|
ideal_nops = p6_nops;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* fall through */
|
|
|
|
|
2011-04-19 06:19:51 +08:00
|
|
|
default:
|
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
ideal_nops = k8_nops;
|
|
|
|
#else
|
|
|
|
if (boot_cpu_has(X86_FEATURE_K8))
|
|
|
|
ideal_nops = k8_nops;
|
|
|
|
else if (boot_cpu_has(X86_FEATURE_K7))
|
|
|
|
ideal_nops = k7_nops;
|
|
|
|
else
|
|
|
|
ideal_nops = intel_nops;
|
|
|
|
#endif
|
|
|
|
}
|
2006-03-23 18:59:32 +08:00
|
|
|
}
|
|
|
|
|
2007-08-11 04:31:03 +08:00
|
|
|
/* Use this to add nops to a buffer, then text_poke the whole buffer. */
|
2009-08-19 15:40:48 +08:00
|
|
|
static void __init_or_module add_nops(void *insns, unsigned int len)
|
2006-12-07 09:14:08 +08:00
|
|
|
{
|
|
|
|
while (len > 0) {
|
|
|
|
unsigned int noplen = len;
|
|
|
|
if (noplen > ASM_NOP_MAX)
|
|
|
|
noplen = ASM_NOP_MAX;
|
2011-04-19 06:19:51 +08:00
|
|
|
memcpy(insns, ideal_nops[noplen], noplen);
|
2006-12-07 09:14:08 +08:00
|
|
|
insns += noplen;
|
|
|
|
len -= noplen;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-06-26 19:56:16 +08:00
|
|
|
extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
|
2010-04-21 23:08:14 +08:00
|
|
|
extern s32 __smp_locks[], __smp_locks_end[];
|
2019-04-26 08:11:33 +08:00
|
|
|
void text_poke_early(void *addr, const void *opcode, size_t len);
|
2006-06-26 19:56:16 +08:00
|
|
|
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
/*
|
|
|
|
* Are we looking at a near JMP with a 1 or 4-byte displacement.
|
|
|
|
*/
|
|
|
|
static inline bool is_jmp(const u8 opcode)
|
|
|
|
{
|
|
|
|
return opcode == 0xeb || opcode == 0xe9;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init_or_module
|
2019-04-25 19:03:31 +08:00
|
|
|
recompute_jump(struct alt_instr *a, u8 *orig_insn, u8 *repl_insn, u8 *insn_buff)
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
{
|
|
|
|
u8 *next_rip, *tgt_rip;
|
|
|
|
s32 n_dspl, o_dspl;
|
|
|
|
int repl_len;
|
|
|
|
|
|
|
|
if (a->replacementlen != 5)
|
|
|
|
return;
|
|
|
|
|
2019-04-25 19:03:31 +08:00
|
|
|
o_dspl = *(s32 *)(insn_buff + 1);
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
|
|
|
|
/* next_rip of the replacement JMP */
|
|
|
|
next_rip = repl_insn + a->replacementlen;
|
|
|
|
/* target rip of the replacement JMP */
|
|
|
|
tgt_rip = next_rip + o_dspl;
|
|
|
|
n_dspl = tgt_rip - orig_insn;
|
|
|
|
|
2018-01-26 20:11:36 +08:00
|
|
|
DPRINTK("target RIP: %px, new_displ: 0x%x", tgt_rip, n_dspl);
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
|
|
|
|
if (tgt_rip - orig_insn >= 0) {
|
|
|
|
if (n_dspl - 2 <= 127)
|
|
|
|
goto two_byte_jmp;
|
|
|
|
else
|
|
|
|
goto five_byte_jmp;
|
|
|
|
/* negative offset */
|
|
|
|
} else {
|
|
|
|
if (((n_dspl - 2) & 0xff) == (n_dspl - 2))
|
|
|
|
goto two_byte_jmp;
|
|
|
|
else
|
|
|
|
goto five_byte_jmp;
|
|
|
|
}
|
|
|
|
|
|
|
|
two_byte_jmp:
|
|
|
|
n_dspl -= 2;
|
|
|
|
|
2019-04-25 19:03:31 +08:00
|
|
|
insn_buff[0] = 0xeb;
|
|
|
|
insn_buff[1] = (s8)n_dspl;
|
|
|
|
add_nops(insn_buff + 2, 3);
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
|
|
|
|
repl_len = 2;
|
|
|
|
goto done;
|
|
|
|
|
|
|
|
five_byte_jmp:
|
|
|
|
n_dspl -= 5;
|
|
|
|
|
2019-04-25 19:03:31 +08:00
|
|
|
insn_buff[0] = 0xe9;
|
|
|
|
*(s32 *)&insn_buff[1] = n_dspl;
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
|
|
|
|
repl_len = 5;
|
|
|
|
|
|
|
|
done:
|
|
|
|
|
|
|
|
DPRINTK("final displ: 0x%08x, JMP 0x%lx",
|
|
|
|
n_dspl, (unsigned long)orig_insn + n_dspl + repl_len);
|
|
|
|
}
|
|
|
|
|
2016-12-03 23:02:58 +08:00
|
|
|
/*
|
|
|
|
* "noinline" to cause control flow change and thus invalidate I$ and
|
|
|
|
* cause refetch after modification.
|
|
|
|
*/
|
|
|
|
static void __init_or_module noinline optimize_nops(struct alt_instr *a, u8 *instr)
|
2015-01-11 03:34:07 +08:00
|
|
|
{
|
x86/alternatives: Make optimize_nops() interrupt safe and synced
Richard reported the following crash:
[ 0.036000] BUG: unable to handle kernel paging request at 55501e06
[ 0.036000] IP: [<c0aae48b>] common_interrupt+0xb/0x38
[ 0.036000] Call Trace:
[ 0.036000] [<c0409c80>] ? add_nops+0x90/0xa0
[ 0.036000] [<c040a054>] apply_alternatives+0x274/0x630
Chuck decoded:
" 0: 8d 90 90 83 04 24 lea 0x24048390(%eax),%edx
6: 80 fc 0f cmp $0xf,%ah
9: a8 0f test $0xf,%al
>> b: a0 06 1e 50 55 mov 0x55501e06,%al
10: 57 push %edi
11: 56 push %esi
Interrupt 0x30 occurred while the alternatives code was replacing the
initial 0x90,0x90,0x90 NOPs (from the ASM_CLAC macro) with the
optimized version, 0x8d,0x76,0x00. Only the first byte has been
replaced so far, and it makes a mess out of the insn decoding."
optimize_nops() is buggy in two aspects:
- It's not disabling interrupts across the modification
- It's lacking a sync_core() call
Add both.
Fixes: 4fd4b6e5537c 'x86/alternatives: Use optimized NOPs for padding'
Reported-and-tested-by: "Richard W.M. Jones" <rjones@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard W.M. Jones <rjones@redhat.com>
Cc: Chuck Ebbert <cebbert.lkml@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1509031232340.15006@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-09-03 18:34:55 +08:00
|
|
|
unsigned long flags;
|
2018-01-10 19:28:16 +08:00
|
|
|
int i;
|
x86/alternatives: Make optimize_nops() interrupt safe and synced
Richard reported the following crash:
[ 0.036000] BUG: unable to handle kernel paging request at 55501e06
[ 0.036000] IP: [<c0aae48b>] common_interrupt+0xb/0x38
[ 0.036000] Call Trace:
[ 0.036000] [<c0409c80>] ? add_nops+0x90/0xa0
[ 0.036000] [<c040a054>] apply_alternatives+0x274/0x630
Chuck decoded:
" 0: 8d 90 90 83 04 24 lea 0x24048390(%eax),%edx
6: 80 fc 0f cmp $0xf,%ah
9: a8 0f test $0xf,%al
>> b: a0 06 1e 50 55 mov 0x55501e06,%al
10: 57 push %edi
11: 56 push %esi
Interrupt 0x30 occurred while the alternatives code was replacing the
initial 0x90,0x90,0x90 NOPs (from the ASM_CLAC macro) with the
optimized version, 0x8d,0x76,0x00. Only the first byte has been
replaced so far, and it makes a mess out of the insn decoding."
optimize_nops() is buggy in two aspects:
- It's not disabling interrupts across the modification
- It's lacking a sync_core() call
Add both.
Fixes: 4fd4b6e5537c 'x86/alternatives: Use optimized NOPs for padding'
Reported-and-tested-by: "Richard W.M. Jones" <rjones@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard W.M. Jones <rjones@redhat.com>
Cc: Chuck Ebbert <cebbert.lkml@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1509031232340.15006@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-09-03 18:34:55 +08:00
|
|
|
|
2018-01-10 19:28:16 +08:00
|
|
|
for (i = 0; i < a->padlen; i++) {
|
|
|
|
if (instr[i] != 0x90)
|
|
|
|
return;
|
|
|
|
}
|
2015-04-05 05:07:42 +08:00
|
|
|
|
x86/alternatives: Make optimize_nops() interrupt safe and synced
Richard reported the following crash:
[ 0.036000] BUG: unable to handle kernel paging request at 55501e06
[ 0.036000] IP: [<c0aae48b>] common_interrupt+0xb/0x38
[ 0.036000] Call Trace:
[ 0.036000] [<c0409c80>] ? add_nops+0x90/0xa0
[ 0.036000] [<c040a054>] apply_alternatives+0x274/0x630
Chuck decoded:
" 0: 8d 90 90 83 04 24 lea 0x24048390(%eax),%edx
6: 80 fc 0f cmp $0xf,%ah
9: a8 0f test $0xf,%al
>> b: a0 06 1e 50 55 mov 0x55501e06,%al
10: 57 push %edi
11: 56 push %esi
Interrupt 0x30 occurred while the alternatives code was replacing the
initial 0x90,0x90,0x90 NOPs (from the ASM_CLAC macro) with the
optimized version, 0x8d,0x76,0x00. Only the first byte has been
replaced so far, and it makes a mess out of the insn decoding."
optimize_nops() is buggy in two aspects:
- It's not disabling interrupts across the modification
- It's lacking a sync_core() call
Add both.
Fixes: 4fd4b6e5537c 'x86/alternatives: Use optimized NOPs for padding'
Reported-and-tested-by: "Richard W.M. Jones" <rjones@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard W.M. Jones <rjones@redhat.com>
Cc: Chuck Ebbert <cebbert.lkml@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1509031232340.15006@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-09-03 18:34:55 +08:00
|
|
|
local_irq_save(flags);
|
2015-01-11 03:34:07 +08:00
|
|
|
add_nops(instr + (a->instrlen - a->padlen), a->padlen);
|
x86/alternatives: Make optimize_nops() interrupt safe and synced
Richard reported the following crash:
[ 0.036000] BUG: unable to handle kernel paging request at 55501e06
[ 0.036000] IP: [<c0aae48b>] common_interrupt+0xb/0x38
[ 0.036000] Call Trace:
[ 0.036000] [<c0409c80>] ? add_nops+0x90/0xa0
[ 0.036000] [<c040a054>] apply_alternatives+0x274/0x630
Chuck decoded:
" 0: 8d 90 90 83 04 24 lea 0x24048390(%eax),%edx
6: 80 fc 0f cmp $0xf,%ah
9: a8 0f test $0xf,%al
>> b: a0 06 1e 50 55 mov 0x55501e06,%al
10: 57 push %edi
11: 56 push %esi
Interrupt 0x30 occurred while the alternatives code was replacing the
initial 0x90,0x90,0x90 NOPs (from the ASM_CLAC macro) with the
optimized version, 0x8d,0x76,0x00. Only the first byte has been
replaced so far, and it makes a mess out of the insn decoding."
optimize_nops() is buggy in two aspects:
- It's not disabling interrupts across the modification
- It's lacking a sync_core() call
Add both.
Fixes: 4fd4b6e5537c 'x86/alternatives: Use optimized NOPs for padding'
Reported-and-tested-by: "Richard W.M. Jones" <rjones@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard W.M. Jones <rjones@redhat.com>
Cc: Chuck Ebbert <cebbert.lkml@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1509031232340.15006@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-09-03 18:34:55 +08:00
|
|
|
local_irq_restore(flags);
|
2015-01-11 03:34:07 +08:00
|
|
|
|
2018-01-26 20:11:36 +08:00
|
|
|
DUMP_BYTES(instr, a->instrlen, "%px: [%d:%d) optimized NOPs: ",
|
2015-01-11 03:34:07 +08:00
|
|
|
instr, a->instrlen - a->padlen, a->padlen);
|
|
|
|
}
|
|
|
|
|
2014-12-31 03:27:09 +08:00
|
|
|
/*
|
|
|
|
* Replace instructions with better alternatives for this CPU type. This runs
|
|
|
|
* before SMP is initialized to avoid SMP problems with self modifying code.
|
|
|
|
* This implies that asymmetric systems where APs have less capabilities than
|
|
|
|
* the boot processor are not handled. Tough. Make sure you disable such
|
|
|
|
* features by hand.
|
2016-12-03 23:02:58 +08:00
|
|
|
*
|
|
|
|
* Marked "noinline" to cause control flow change and thus insn cache
|
|
|
|
* to refetch changed I$ lines.
|
2014-12-31 03:27:09 +08:00
|
|
|
*/
|
2016-12-03 23:02:58 +08:00
|
|
|
void __init_or_module noinline apply_alternatives(struct alt_instr *start,
|
|
|
|
struct alt_instr *end)
|
2006-03-23 18:59:32 +08:00
|
|
|
{
|
|
|
|
struct alt_instr *a;
|
2011-07-13 21:24:10 +08:00
|
|
|
u8 *instr, *replacement;
|
2019-04-25 19:03:31 +08:00
|
|
|
u8 insn_buff[MAX_PATCH_LEN];
|
2006-03-23 18:59:32 +08:00
|
|
|
|
2018-01-26 20:11:36 +08:00
|
|
|
DPRINTK("alt table %px, -> %px", start, end);
|
2011-05-18 06:29:12 +08:00
|
|
|
/*
|
|
|
|
* The scan order should be from start to end. A later scanned
|
2014-12-31 03:27:09 +08:00
|
|
|
* alternative code can overwrite previously scanned alternative code.
|
2011-05-18 06:29:12 +08:00
|
|
|
* Some kernel functions (e.g. memcpy, memset, etc) use this order to
|
|
|
|
* patch code.
|
|
|
|
*
|
|
|
|
* So be careful if you want to change the scan order to any other
|
|
|
|
* order.
|
|
|
|
*/
|
2006-03-23 18:59:32 +08:00
|
|
|
for (a = start; a < end; a++) {
|
2019-04-25 19:03:31 +08:00
|
|
|
int insn_buff_sz = 0;
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
|
2011-07-13 21:24:10 +08:00
|
|
|
instr = (u8 *)&a->instr_offset + a->instr_offset;
|
|
|
|
replacement = (u8 *)&a->repl_offset + a->repl_offset;
|
2019-04-25 19:03:31 +08:00
|
|
|
BUG_ON(a->instrlen > sizeof(insn_buff));
|
2013-03-20 22:07:23 +08:00
|
|
|
BUG_ON(a->cpuid >= (NCAPINTS + NBUGINTS) * 32);
|
2015-01-11 03:34:07 +08:00
|
|
|
if (!boot_cpu_has(a->cpuid)) {
|
|
|
|
if (a->padlen > 1)
|
|
|
|
optimize_nops(a, instr);
|
|
|
|
|
2006-03-23 18:59:32 +08:00
|
|
|
continue;
|
2015-01-11 03:34:07 +08:00
|
|
|
}
|
2011-07-13 21:24:10 +08:00
|
|
|
|
2018-12-10 19:30:30 +08:00
|
|
|
DPRINTK("feat: %d*32+%d, old: (%pS (%px) len: %d), repl: (%px, len: %d), pad: %d",
|
2014-12-31 03:27:09 +08:00
|
|
|
a->cpuid >> 5,
|
|
|
|
a->cpuid & 0x1f,
|
2018-12-10 19:30:30 +08:00
|
|
|
instr, instr, a->instrlen,
|
x86/alternatives: Fix ALTERNATIVE_2 padding generation properly
Quentin caught a corner case with the generation of instruction
padding in the ALTERNATIVE_2 macro: if len(orig_insn) <
len(alt1) < len(alt2), then not enough padding gets added and
that is not good(tm) as we could overwrite the beginning of the
next instruction.
Luckily, at the time of this writing, we don't have
ALTERNATIVE_2() invocations which have that problem and even if
we did, a simple fix would be to prepend the instructions with
enough prefixes so that that corner case doesn't happen.
However, best it would be if we fixed it properly. See below for
a simple, abstracted example of what we're doing.
So what we ended up doing is, we compute the
max(len(alt1), len(alt2)) - len(orig_insn)
and feed that value to the .skip gas directive. The max() cannot
have conditionals due to gas limitations, thus the fancy integer
math.
With this patch, all ALTERNATIVE_2 sites get padded correctly;
generating obscure test cases pass too:
#define alt_max_short(a, b) ((a) ^ (((a) ^ (b)) & -(-((a) < (b)))))
#define gen_skip(orig, alt1, alt2, marker) \
.skip -((alt_max_short(alt1, alt2) - (orig)) > 0) * \
(alt_max_short(alt1, alt2) - (orig)),marker
.pushsection .text, "ax"
.globl main
main:
gen_skip(1, 2, 4, 0x09)
gen_skip(4, 1, 2, 0x10)
...
.popsection
Thanks to Quentin for catching it and double-checking the fix!
Reported-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20150404133443.GE21152@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-04 21:34:43 +08:00
|
|
|
replacement, a->replacementlen, a->padlen);
|
2014-12-31 03:27:09 +08:00
|
|
|
|
2018-01-26 20:11:36 +08:00
|
|
|
DUMP_BYTES(instr, a->instrlen, "%px: old_insn: ", instr);
|
|
|
|
DUMP_BYTES(replacement, a->replacementlen, "%px: rpl_insn: ", replacement);
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
|
2019-04-25 19:03:31 +08:00
|
|
|
memcpy(insn_buff, replacement, a->replacementlen);
|
|
|
|
insn_buff_sz = a->replacementlen;
|
2011-07-13 21:24:10 +08:00
|
|
|
|
2017-05-24 21:55:00 +08:00
|
|
|
/*
|
|
|
|
* 0xe8 is a relative jump; fix the offset.
|
|
|
|
*
|
|
|
|
* Instruction length is checked before the opcode to avoid
|
|
|
|
* accessing uninitialized bytes for zero-length replacements.
|
|
|
|
*/
|
2019-04-25 19:03:31 +08:00
|
|
|
if (a->replacementlen == 5 && *insn_buff == 0xe8) {
|
|
|
|
*(s32 *)(insn_buff + 1) += replacement - instr;
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
DPRINTK("Fix CALL offset: 0x%x, CALL 0x%lx",
|
2019-04-25 19:03:31 +08:00
|
|
|
*(s32 *)(insn_buff + 1),
|
|
|
|
(unsigned long)instr + *(s32 *)(insn_buff + 1) + 5);
|
2014-12-31 03:27:09 +08:00
|
|
|
}
|
2011-07-13 21:24:10 +08:00
|
|
|
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
if (a->replacementlen && is_jmp(replacement[0]))
|
2019-04-25 19:03:31 +08:00
|
|
|
recompute_jump(a, instr, replacement, insn_buff);
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
|
|
|
|
if (a->instrlen > a->replacementlen) {
|
2019-04-25 19:03:31 +08:00
|
|
|
add_nops(insn_buff + a->replacementlen,
|
2014-12-27 17:41:52 +08:00
|
|
|
a->instrlen - a->replacementlen);
|
2019-04-25 19:03:31 +08:00
|
|
|
insn_buff_sz += a->instrlen - a->replacementlen;
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
}
|
2019-04-25 19:03:31 +08:00
|
|
|
DUMP_BYTES(insn_buff, insn_buff_sz, "%px: final_insn: ", instr);
|
2011-07-13 21:24:10 +08:00
|
|
|
|
2019-04-25 19:03:31 +08:00
|
|
|
text_poke_early(instr, insn_buff, insn_buff_sz);
|
2006-03-23 18:59:32 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-07-01 19:36:18 +08:00
|
|
|
#ifdef CONFIG_SMP
|
2010-04-21 23:08:14 +08:00
|
|
|
static void alternatives_smp_lock(const s32 *start, const s32 *end,
|
|
|
|
u8 *text, u8 *text_end)
|
2006-03-23 18:59:32 +08:00
|
|
|
{
|
2010-04-21 23:08:14 +08:00
|
|
|
const s32 *poff;
|
2006-03-23 18:59:32 +08:00
|
|
|
|
2010-04-21 23:08:14 +08:00
|
|
|
for (poff = start; poff < end; poff++) {
|
|
|
|
u8 *ptr = (u8 *)poff + *poff;
|
|
|
|
|
|
|
|
if (!*poff || ptr < text || ptr >= text_end)
|
2006-03-23 18:59:32 +08:00
|
|
|
continue;
|
x86: alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug
If a kernel thread is preempted in single-cpu mode right after the NOP (nop
about to be turned into a lock prefix), then we CPU hotplug a CPU, and then the
thread is scheduled back again, a SMP-unsafe atomic operation will be used on
shared SMP variables, leading to corruption. No corruption would happen in the
reverse case : going from SMP to UP is ok because we split a bit instruction
into tiny pieces, which does not present this condition.
Changing the 0x90 (single-byte nop) currently used into a 0x3E DS segment
override prefix should fix this issue. Since the default of the atomic
instructions is to use the DS segment anyway, it should not affect the
behavior.
The exception to this are references that use ESP/RSP and EBP/RBP as
the base register (they will use the SS segment), however, in Linux
(a) DS == SS at all times, and (b) we do not distinguish between
segment violations reported as #SS as opposed to #GP, so there is no
need to disassemble the instruction to figure out the suitable segment.
This patch assumes that the 0x3E prefix will leave atomic operations as-is (thus
assuming they normally touch data in the DS segment). Since there seem to be no
obvious ill-use of other segment override prefixes for atomic operations, it
should be safe. It can be verified with a quick
grep -r LOCK_PREFIX include/asm-x86/
grep -A 1 -r LOCK_PREFIX arch/x86/
Taken from
This source :
AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System
Instructions
States
"Instructions that Reference a Non-Stack Segment—If an instruction encoding
references any base register other than rBP or rSP, or if an instruction
contains an immediate offset, the default segment is the data segment (DS).
These instructions can use the segment-override prefix to select one of the
non-default segments, as shown in Table 1-5."
Therefore, forcing the DS segment on the atomic operations, which already use
the DS segment, should not change.
This source :
http://wiki.osdev.org/X86_Instruction_Encoding
States
"In 64-bit the CS, SS, DS and ES segment overrides are ignored."
Confirmed by "AMD 64-Bit Technology" A.7
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/x86-64_overview.pdf
"In 64-bit mode, the DS, ES, SS and CS segment-override prefixes have no effect.
These four prefixes are no longer treated as segment-override prefixes in the
context of multipleprefix rules. Instead, they are treated as null prefixes."
This patch applies to 2.6.27-rc2, but would also have to be applied to earlier
kernels (2.6.26, 2.6.25, ...).
Performance impact of the fix : tests done on "xaddq" and "xaddl" shows it
actually improves performances on Intel Xeon, AMD64, Pentium M. It does not
change the performance on Pentium II, Pentium 3 and Pentium 4.
Xeon E5405 2.0GHz :
NR_TESTS 10000000
test empty cycles : 162207948
test test 1-byte nop xadd cycles : 170755422
test test DS override prefix xadd cycles : 170000118 *
test test LOCK xadd cycles : 472012134
AMD64 2.0GHz :
NR_TESTS 10000000
test empty cycles : 146674549
test test 1-byte nop xadd cycles : 150273860
test test DS override prefix xadd cycles : 149982382 *
test test LOCK xadd cycles : 270000690
Pentium 4 3.0GHz
NR_TESTS 10000000
test empty cycles : 290001195
test test 1-byte nop xadd cycles : 310000560
test test DS override prefix xadd cycles : 310000575 *
test test LOCK xadd cycles : 1050103740
Pentium M 2.0GHz
NR_TESTS 10000000
test empty cycles : 180000523
test test 1-byte nop xadd cycles : 320000345
test test DS override prefix xadd cycles : 310000374 *
test test LOCK xadd cycles : 480000357
Pentium 3 550MHz
NR_TESTS 10000000
test empty cycles : 510000231
test test 1-byte nop xadd cycles : 620000128
test test DS override prefix xadd cycles : 620000110 *
test test LOCK xadd cycles : 800000088
Pentium II 350MHz
NR_TESTS 10000000
test empty cycles : 200833494
test test 1-byte nop xadd cycles : 340000130
test test DS override prefix xadd cycles : 340000126 *
test test LOCK xadd cycles : 530000078
Speed test modules can be found at
http://ltt.polymtl.ca/svn/trunk/tests/kernel/test-prefix-speed-32.c
http://ltt.polymtl.ca/svn/trunk/tests/kernel/test-prefix-speed.c
Macro-benchmarks
2.0GHz E5405 Core 2 dual Quad-Core Xeon
Summary
* replace smp lock prefixes with DS segment selector prefixes
no lock prefix (s) with lock prefix (s) Speedup
make -j1 kernel/ 33.94 +/- 0.07 34.91 +/- 0.27 2.8 %
hackbench 50 2.99 +/- 0.01 3.74 +/- 0.01 25.1 %
* replace smp lock prefixes with 0x90 nops
no lock prefix (s) with lock prefix (s) Speedup
make -j1 kernel/ 34.16 +/- 0.32 34.91 +/- 0.27 2.2 %
hackbench 50 3.00 +/- 0.01 3.74 +/- 0.01 24.7 %
Detail :
1 CPU, replace smp lock prefixes with DS segment selector prefixes
make -j1 kernel/
real 0m34.067s
user 0m30.630s
sys 0m2.980s
real 0m33.867s
user 0m30.582s
sys 0m3.024s
real 0m33.939s
user 0m30.738s
sys 0m2.876s
real 0m33.913s
user 0m30.806s
sys 0m2.808s
avg : 33.94s
std. dev. : 0.07s
hackbench 50
Time: 2.978
Time: 2.982
Time: 3.010
Time: 2.984
Time: 2.982
avg : 2.99
std. dev. : 0.01
1 CPU, noreplace-smp
make -j1 kernel/
real 0m35.326s
user 0m30.630s
sys 0m3.260s
real 0m34.325s
user 0m30.802s
sys 0m3.084s
real 0m35.568s
user 0m30.722s
sys 0m3.168s
real 0m34.435s
user 0m30.886s
sys 0m2.996s
avg.: 34.91s
std. dev. : 0.27s
hackbench 50
Time: 3.733
Time: 3.750
Time: 3.761
Time: 3.737
Time: 3.741
avg : 3.74
std. dev. : 0.01
1 CPU, replace smp lock prefixes with 0x90 nops
make -j1 kernel/
real 0m34.139s
user 0m30.782s
sys 0m2.820s
real 0m34.010s
user 0m30.630s
sys 0m2.976s
real 0m34.777s
user 0m30.658s
sys 0m2.916s
real 0m33.924s
user 0m30.634s
sys 0m2.924s
real 0m33.962s
user 0m30.774s
sys 0m2.800s
real 0m34.141s
user 0m30.770s
sys 0m2.828s
avg : 34.16
std. dev. : 0.32
hackbench 50
Time: 2.999
Time: 2.994
Time: 3.004
Time: 2.991
Time: 2.988
avg : 3.00
std. dev. : 0.01
I did more runs (20 runs of each) to compare the nop case to the DS
prefix case. Results in seconds. They actually does not seems to show a
significant difference.
NOP
34.155
33.955
34.012
35.299
35.679
34.141
33.995
35.016
34.254
33.957
33.957
34.008
35.013
34.494
33.893
34.295
34.314
34.854
33.991
34.132
DS
34.080
34.304
34.374
35.095
34.291
34.135
33.940
34.208
35.276
34.288
33.861
33.898
34.610
34.709
33.851
34.256
35.161
34.283
33.865
35.078
Used http://www.graphpad.com/quickcalcs/ttest1.cfm?Format=C to do the
T-test (yeah, I'm lazy) :
Group Group One (DS prefix) Group Two (nops)
Mean 34.37815 34.37070
SD 0.46108 0.51905
SEM 0.10310 0.11606
N 20 20
P value and statistical significance:
The two-tailed P value equals 0.9620
By conventional criteria, this difference is considered to be not statistically significant.
Confidence interval:
The mean of Group One minus Group Two equals 0.00745
95% confidence interval of this difference: From -0.30682 to 0.32172
Intermediate values used in calculations:
t = 0.0480
df = 38
standard error of difference = 0.155
So, unless these calculus are completely bogus, the difference between the nop
and the DS case seems not to be statistically significant.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: H. Peter Anvin <hpa@zytor.com>
CC: Linus Torvalds <torvalds@linux-foundation.org>
CC: Jeremy Fitzhardinge <jeremy@goop.org>
CC: Roland McGrath <roland@redhat.com>
CC: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>
CC: Steven Rostedt <srostedt@redhat.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Peter Zijlstra <peterz@infradead.org>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: David Miller <davem@davemloft.net>
CC: Ulrich Drepper <drepper@redhat.com>
CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Gregory Haskins <ghaskins@novell.com>
CC: Arnaldo Carvalho de Melo <acme@redhat.com>
CC: "Luis Claudio R. Goncalves" <lclaudio@uudg.org>
CC: Clark Williams <williams@redhat.com>
CC: Christoph Lameter <cl@linux-foundation.org>
CC: Andi Kleen <andi@firstfloor.org>
CC: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2008-08-15 04:58:15 +08:00
|
|
|
/* turn DS segment override prefix into lock prefix */
|
2010-04-30 07:53:17 +08:00
|
|
|
if (*ptr == 0x3e)
|
|
|
|
text_poke(ptr, ((unsigned char []){0xf0}), 1);
|
2012-09-19 00:36:14 +08:00
|
|
|
}
|
2006-03-23 18:59:32 +08:00
|
|
|
}
|
|
|
|
|
2010-04-21 23:08:14 +08:00
|
|
|
static void alternatives_smp_unlock(const s32 *start, const s32 *end,
|
|
|
|
u8 *text, u8 *text_end)
|
2006-03-23 18:59:32 +08:00
|
|
|
{
|
2010-04-21 23:08:14 +08:00
|
|
|
const s32 *poff;
|
2006-03-23 18:59:32 +08:00
|
|
|
|
2010-04-21 23:08:14 +08:00
|
|
|
for (poff = start; poff < end; poff++) {
|
|
|
|
u8 *ptr = (u8 *)poff + *poff;
|
|
|
|
|
|
|
|
if (!*poff || ptr < text || ptr >= text_end)
|
2006-03-23 18:59:32 +08:00
|
|
|
continue;
|
x86: alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug
If a kernel thread is preempted in single-cpu mode right after the NOP (nop
about to be turned into a lock prefix), then we CPU hotplug a CPU, and then the
thread is scheduled back again, a SMP-unsafe atomic operation will be used on
shared SMP variables, leading to corruption. No corruption would happen in the
reverse case : going from SMP to UP is ok because we split a bit instruction
into tiny pieces, which does not present this condition.
Changing the 0x90 (single-byte nop) currently used into a 0x3E DS segment
override prefix should fix this issue. Since the default of the atomic
instructions is to use the DS segment anyway, it should not affect the
behavior.
The exception to this are references that use ESP/RSP and EBP/RBP as
the base register (they will use the SS segment), however, in Linux
(a) DS == SS at all times, and (b) we do not distinguish between
segment violations reported as #SS as opposed to #GP, so there is no
need to disassemble the instruction to figure out the suitable segment.
This patch assumes that the 0x3E prefix will leave atomic operations as-is (thus
assuming they normally touch data in the DS segment). Since there seem to be no
obvious ill-use of other segment override prefixes for atomic operations, it
should be safe. It can be verified with a quick
grep -r LOCK_PREFIX include/asm-x86/
grep -A 1 -r LOCK_PREFIX arch/x86/
Taken from
This source :
AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System
Instructions
States
"Instructions that Reference a Non-Stack Segment—If an instruction encoding
references any base register other than rBP or rSP, or if an instruction
contains an immediate offset, the default segment is the data segment (DS).
These instructions can use the segment-override prefix to select one of the
non-default segments, as shown in Table 1-5."
Therefore, forcing the DS segment on the atomic operations, which already use
the DS segment, should not change.
This source :
http://wiki.osdev.org/X86_Instruction_Encoding
States
"In 64-bit the CS, SS, DS and ES segment overrides are ignored."
Confirmed by "AMD 64-Bit Technology" A.7
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/x86-64_overview.pdf
"In 64-bit mode, the DS, ES, SS and CS segment-override prefixes have no effect.
These four prefixes are no longer treated as segment-override prefixes in the
context of multipleprefix rules. Instead, they are treated as null prefixes."
This patch applies to 2.6.27-rc2, but would also have to be applied to earlier
kernels (2.6.26, 2.6.25, ...).
Performance impact of the fix : tests done on "xaddq" and "xaddl" shows it
actually improves performances on Intel Xeon, AMD64, Pentium M. It does not
change the performance on Pentium II, Pentium 3 and Pentium 4.
Xeon E5405 2.0GHz :
NR_TESTS 10000000
test empty cycles : 162207948
test test 1-byte nop xadd cycles : 170755422
test test DS override prefix xadd cycles : 170000118 *
test test LOCK xadd cycles : 472012134
AMD64 2.0GHz :
NR_TESTS 10000000
test empty cycles : 146674549
test test 1-byte nop xadd cycles : 150273860
test test DS override prefix xadd cycles : 149982382 *
test test LOCK xadd cycles : 270000690
Pentium 4 3.0GHz
NR_TESTS 10000000
test empty cycles : 290001195
test test 1-byte nop xadd cycles : 310000560
test test DS override prefix xadd cycles : 310000575 *
test test LOCK xadd cycles : 1050103740
Pentium M 2.0GHz
NR_TESTS 10000000
test empty cycles : 180000523
test test 1-byte nop xadd cycles : 320000345
test test DS override prefix xadd cycles : 310000374 *
test test LOCK xadd cycles : 480000357
Pentium 3 550MHz
NR_TESTS 10000000
test empty cycles : 510000231
test test 1-byte nop xadd cycles : 620000128
test test DS override prefix xadd cycles : 620000110 *
test test LOCK xadd cycles : 800000088
Pentium II 350MHz
NR_TESTS 10000000
test empty cycles : 200833494
test test 1-byte nop xadd cycles : 340000130
test test DS override prefix xadd cycles : 340000126 *
test test LOCK xadd cycles : 530000078
Speed test modules can be found at
http://ltt.polymtl.ca/svn/trunk/tests/kernel/test-prefix-speed-32.c
http://ltt.polymtl.ca/svn/trunk/tests/kernel/test-prefix-speed.c
Macro-benchmarks
2.0GHz E5405 Core 2 dual Quad-Core Xeon
Summary
* replace smp lock prefixes with DS segment selector prefixes
no lock prefix (s) with lock prefix (s) Speedup
make -j1 kernel/ 33.94 +/- 0.07 34.91 +/- 0.27 2.8 %
hackbench 50 2.99 +/- 0.01 3.74 +/- 0.01 25.1 %
* replace smp lock prefixes with 0x90 nops
no lock prefix (s) with lock prefix (s) Speedup
make -j1 kernel/ 34.16 +/- 0.32 34.91 +/- 0.27 2.2 %
hackbench 50 3.00 +/- 0.01 3.74 +/- 0.01 24.7 %
Detail :
1 CPU, replace smp lock prefixes with DS segment selector prefixes
make -j1 kernel/
real 0m34.067s
user 0m30.630s
sys 0m2.980s
real 0m33.867s
user 0m30.582s
sys 0m3.024s
real 0m33.939s
user 0m30.738s
sys 0m2.876s
real 0m33.913s
user 0m30.806s
sys 0m2.808s
avg : 33.94s
std. dev. : 0.07s
hackbench 50
Time: 2.978
Time: 2.982
Time: 3.010
Time: 2.984
Time: 2.982
avg : 2.99
std. dev. : 0.01
1 CPU, noreplace-smp
make -j1 kernel/
real 0m35.326s
user 0m30.630s
sys 0m3.260s
real 0m34.325s
user 0m30.802s
sys 0m3.084s
real 0m35.568s
user 0m30.722s
sys 0m3.168s
real 0m34.435s
user 0m30.886s
sys 0m2.996s
avg.: 34.91s
std. dev. : 0.27s
hackbench 50
Time: 3.733
Time: 3.750
Time: 3.761
Time: 3.737
Time: 3.741
avg : 3.74
std. dev. : 0.01
1 CPU, replace smp lock prefixes with 0x90 nops
make -j1 kernel/
real 0m34.139s
user 0m30.782s
sys 0m2.820s
real 0m34.010s
user 0m30.630s
sys 0m2.976s
real 0m34.777s
user 0m30.658s
sys 0m2.916s
real 0m33.924s
user 0m30.634s
sys 0m2.924s
real 0m33.962s
user 0m30.774s
sys 0m2.800s
real 0m34.141s
user 0m30.770s
sys 0m2.828s
avg : 34.16
std. dev. : 0.32
hackbench 50
Time: 2.999
Time: 2.994
Time: 3.004
Time: 2.991
Time: 2.988
avg : 3.00
std. dev. : 0.01
I did more runs (20 runs of each) to compare the nop case to the DS
prefix case. Results in seconds. They actually does not seems to show a
significant difference.
NOP
34.155
33.955
34.012
35.299
35.679
34.141
33.995
35.016
34.254
33.957
33.957
34.008
35.013
34.494
33.893
34.295
34.314
34.854
33.991
34.132
DS
34.080
34.304
34.374
35.095
34.291
34.135
33.940
34.208
35.276
34.288
33.861
33.898
34.610
34.709
33.851
34.256
35.161
34.283
33.865
35.078
Used http://www.graphpad.com/quickcalcs/ttest1.cfm?Format=C to do the
T-test (yeah, I'm lazy) :
Group Group One (DS prefix) Group Two (nops)
Mean 34.37815 34.37070
SD 0.46108 0.51905
SEM 0.10310 0.11606
N 20 20
P value and statistical significance:
The two-tailed P value equals 0.9620
By conventional criteria, this difference is considered to be not statistically significant.
Confidence interval:
The mean of Group One minus Group Two equals 0.00745
95% confidence interval of this difference: From -0.30682 to 0.32172
Intermediate values used in calculations:
t = 0.0480
df = 38
standard error of difference = 0.155
So, unless these calculus are completely bogus, the difference between the nop
and the DS case seems not to be statistically significant.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: H. Peter Anvin <hpa@zytor.com>
CC: Linus Torvalds <torvalds@linux-foundation.org>
CC: Jeremy Fitzhardinge <jeremy@goop.org>
CC: Roland McGrath <roland@redhat.com>
CC: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>
CC: Steven Rostedt <srostedt@redhat.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Peter Zijlstra <peterz@infradead.org>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: David Miller <davem@davemloft.net>
CC: Ulrich Drepper <drepper@redhat.com>
CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Gregory Haskins <ghaskins@novell.com>
CC: Arnaldo Carvalho de Melo <acme@redhat.com>
CC: "Luis Claudio R. Goncalves" <lclaudio@uudg.org>
CC: Clark Williams <williams@redhat.com>
CC: Christoph Lameter <cl@linux-foundation.org>
CC: Andi Kleen <andi@firstfloor.org>
CC: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2008-08-15 04:58:15 +08:00
|
|
|
/* turn lock prefix into DS segment override prefix */
|
2010-04-30 07:53:17 +08:00
|
|
|
if (*ptr == 0xf0)
|
|
|
|
text_poke(ptr, ((unsigned char []){0x3E}), 1);
|
2012-09-19 00:36:14 +08:00
|
|
|
}
|
2006-03-23 18:59:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
struct smp_alt_module {
|
|
|
|
/* what is this ??? */
|
|
|
|
struct module *mod;
|
|
|
|
char *name;
|
|
|
|
|
|
|
|
/* ptrs to lock prefixes */
|
2010-04-21 23:08:14 +08:00
|
|
|
const s32 *locks;
|
|
|
|
const s32 *locks_end;
|
2006-03-23 18:59:32 +08:00
|
|
|
|
|
|
|
/* .text segment, needed to avoid patching init code ;) */
|
|
|
|
u8 *text;
|
|
|
|
u8 *text_end;
|
|
|
|
|
|
|
|
struct list_head next;
|
|
|
|
};
|
|
|
|
static LIST_HEAD(smp_alt_modules);
|
2017-11-02 09:18:21 +08:00
|
|
|
static bool uniproc_patched = false; /* protected by text_mutex */
|
2006-03-23 18:59:32 +08:00
|
|
|
|
2009-08-19 15:40:48 +08:00
|
|
|
void __init_or_module alternatives_smp_module_add(struct module *mod,
|
|
|
|
char *name,
|
|
|
|
void *locks, void *locks_end,
|
|
|
|
void *text, void *text_end)
|
2006-03-23 18:59:32 +08:00
|
|
|
{
|
|
|
|
struct smp_alt_module *smp;
|
|
|
|
|
2017-11-02 09:18:21 +08:00
|
|
|
mutex_lock(&text_mutex);
|
2012-08-06 15:59:49 +08:00
|
|
|
if (!uniproc_patched)
|
|
|
|
goto unlock;
|
2007-05-03 01:27:13 +08:00
|
|
|
|
2012-08-06 15:59:49 +08:00
|
|
|
if (num_possible_cpus() == 1)
|
|
|
|
/* Don't bother remembering, we'll never have to undo it. */
|
|
|
|
goto smp_unlock;
|
2006-03-23 18:59:32 +08:00
|
|
|
|
|
|
|
smp = kzalloc(sizeof(*smp), GFP_KERNEL);
|
|
|
|
if (NULL == smp)
|
2012-08-06 15:59:49 +08:00
|
|
|
/* we'll run the (safe but slow) SMP code then ... */
|
|
|
|
goto unlock;
|
2006-03-23 18:59:32 +08:00
|
|
|
|
|
|
|
smp->mod = mod;
|
|
|
|
smp->name = name;
|
|
|
|
smp->locks = locks;
|
|
|
|
smp->locks_end = locks_end;
|
|
|
|
smp->text = text;
|
|
|
|
smp->text_end = text_end;
|
2014-12-31 03:27:09 +08:00
|
|
|
DPRINTK("locks %p -> %p, text %p -> %p, name %s\n",
|
|
|
|
smp->locks, smp->locks_end,
|
2006-03-23 18:59:32 +08:00
|
|
|
smp->text, smp->text_end, smp->name);
|
|
|
|
|
|
|
|
list_add_tail(&smp->next, &smp_alt_modules);
|
2012-08-06 15:59:49 +08:00
|
|
|
smp_unlock:
|
|
|
|
alternatives_smp_unlock(locks, locks_end, text, text_end);
|
|
|
|
unlock:
|
2017-11-02 09:18:21 +08:00
|
|
|
mutex_unlock(&text_mutex);
|
2006-03-23 18:59:32 +08:00
|
|
|
}
|
|
|
|
|
2009-08-19 15:40:48 +08:00
|
|
|
void __init_or_module alternatives_smp_module_del(struct module *mod)
|
2006-03-23 18:59:32 +08:00
|
|
|
{
|
|
|
|
struct smp_alt_module *item;
|
|
|
|
|
2017-11-02 09:18:21 +08:00
|
|
|
mutex_lock(&text_mutex);
|
2006-03-23 18:59:32 +08:00
|
|
|
list_for_each_entry(item, &smp_alt_modules, next) {
|
|
|
|
if (mod != item->mod)
|
|
|
|
continue;
|
|
|
|
list_del(&item->next);
|
|
|
|
kfree(item);
|
2012-08-06 15:59:49 +08:00
|
|
|
break;
|
2006-03-23 18:59:32 +08:00
|
|
|
}
|
2017-11-02 09:18:21 +08:00
|
|
|
mutex_unlock(&text_mutex);
|
2006-03-23 18:59:32 +08:00
|
|
|
}
|
|
|
|
|
2012-08-06 15:59:49 +08:00
|
|
|
void alternatives_enable_smp(void)
|
2006-03-23 18:59:32 +08:00
|
|
|
{
|
|
|
|
struct smp_alt_module *mod;
|
|
|
|
|
2012-08-06 15:59:49 +08:00
|
|
|
/* Why bother if there are no other CPUs? */
|
|
|
|
BUG_ON(num_possible_cpus() == 1);
|
2006-03-23 18:59:32 +08:00
|
|
|
|
2017-11-02 09:18:21 +08:00
|
|
|
mutex_lock(&text_mutex);
|
2008-01-30 20:33:17 +08:00
|
|
|
|
2012-08-06 15:59:49 +08:00
|
|
|
if (uniproc_patched) {
|
2012-05-22 10:50:07 +08:00
|
|
|
pr_info("switching to SMP code\n");
|
2012-08-06 15:59:49 +08:00
|
|
|
BUG_ON(num_online_cpus() != 1);
|
2008-01-30 20:30:55 +08:00
|
|
|
clear_cpu_cap(&boot_cpu_data, X86_FEATURE_UP);
|
|
|
|
clear_cpu_cap(&cpu_data(0), X86_FEATURE_UP);
|
2006-03-23 18:59:32 +08:00
|
|
|
list_for_each_entry(mod, &smp_alt_modules, next)
|
|
|
|
alternatives_smp_lock(mod->locks, mod->locks_end,
|
|
|
|
mod->text, mod->text_end);
|
2012-08-06 15:59:49 +08:00
|
|
|
uniproc_patched = false;
|
2006-03-23 18:59:32 +08:00
|
|
|
}
|
2017-11-02 09:18:21 +08:00
|
|
|
mutex_unlock(&text_mutex);
|
2006-03-23 18:59:32 +08:00
|
|
|
}
|
|
|
|
|
2017-11-02 09:18:21 +08:00
|
|
|
/*
|
|
|
|
* Return 1 if the address range is reserved for SMP-alternatives.
|
|
|
|
* Must hold text_mutex.
|
|
|
|
*/
|
2010-02-03 05:49:11 +08:00
|
|
|
int alternatives_text_reserved(void *start, void *end)
|
|
|
|
{
|
|
|
|
struct smp_alt_module *mod;
|
2010-04-21 23:08:14 +08:00
|
|
|
const s32 *poff;
|
2010-02-06 01:16:47 +08:00
|
|
|
u8 *text_start = start;
|
|
|
|
u8 *text_end = end;
|
2010-02-03 05:49:11 +08:00
|
|
|
|
2017-11-02 09:18:21 +08:00
|
|
|
lockdep_assert_held(&text_mutex);
|
|
|
|
|
2010-02-03 05:49:11 +08:00
|
|
|
list_for_each_entry(mod, &smp_alt_modules, next) {
|
2010-02-06 01:16:47 +08:00
|
|
|
if (mod->text > text_end || mod->text_end < text_start)
|
2010-02-03 05:49:11 +08:00
|
|
|
continue;
|
2010-04-21 23:08:14 +08:00
|
|
|
for (poff = mod->locks; poff < mod->locks_end; poff++) {
|
|
|
|
const u8 *ptr = (const u8 *)poff + *poff;
|
|
|
|
|
|
|
|
if (text_start <= ptr && text_end > ptr)
|
2010-02-03 05:49:11 +08:00
|
|
|
return 1;
|
2010-04-21 23:08:14 +08:00
|
|
|
}
|
2010-02-03 05:49:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
x86/alternatives: Make JMPs more robust
Up until now we had to pay attention to relative JMPs in alternatives
about how their relative offset gets computed so that the jump target
is still correct. Or, as it is the case for near CALLs (opcode e8), we
still have to go and readjust the offset at patching time.
What is more, the static_cpu_has_safe() facility had to forcefully
generate 5-byte JMPs since we couldn't rely on the compiler to generate
properly sized ones so we had to force the longest ones. Worse than
that, sometimes it would generate a replacement JMP which is longer than
the original one, thus overwriting the beginning of the next instruction
at patching time.
So, in order to alleviate all that and make using JMPs more
straight-forward we go and pad the original instruction in an
alternative block with NOPs at build time, should the replacement(s) be
longer. This way, alternatives users shouldn't pay special attention
so that original and replacement instruction sizes are fine but the
assembler would simply add padding where needed and not do anything
otherwise.
As a second aspect, we go and recompute JMPs at patching time so that we
can try to make 5-byte JMPs into two-byte ones if possible. If not, we
still have to recompute the offsets as the replacement JMP gets put far
away in the .altinstr_replacement section leading to a wrong offset if
copied verbatim.
For example, on a locally generated kernel image
old insn VA: 0xffffffff810014bd, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff810014bd: eb 21 jmp ffffffff810014e0
repl insn: size: 5
ffffffff81d0b23c: e9 b1 62 2f ff jmpq ffffffff810014f2
gets corrected to a 2-byte JMP:
apply_alternatives: feat: 3*32+21, old: (ffffffff810014bd, len: 2), repl: (ffffffff81d0b23c, len: 5)
alt_insn: e9 b1 62 2f ff
recompute_jumps: next_rip: ffffffff81d0b241, tgt_rip: ffffffff810014f2, new_displ: 0x00000033, ret len: 2
converted to: eb 33 90 90 90
and a 5-byte JMP:
old insn VA: 0xffffffff81001516, CPU feat: X86_FEATURE_ALWAYS, size: 2
__switch_to:
ffffffff81001516: eb 30 jmp ffffffff81001548
repl insn: size: 5
ffffffff81d0b241: e9 10 63 2f ff jmpq ffffffff81001556
gets shortened into a two-byte one:
apply_alternatives: feat: 3*32+21, old: (ffffffff81001516, len: 2), repl: (ffffffff81d0b241, len: 5)
alt_insn: e9 10 63 2f ff
recompute_jumps: next_rip: ffffffff81d0b246, tgt_rip: ffffffff81001556, new_displ: 0x0000003e, ret len: 2
converted to: eb 3e 90 90 90
... and so on.
This leads to a net win of around
40ish replacements * 3 bytes savings =~ 120 bytes of I$
on an AMD guest which means some savings of precious instruction cache
bandwidth. The padding to the shorter 2-byte JMPs are single-byte NOPs
which on smart microarchitectures means discarding NOPs at decode time
and thus freeing up execution bandwidth.
Signed-off-by: Borislav Petkov <bp@suse.de>
2015-01-05 20:48:41 +08:00
|
|
|
#endif /* CONFIG_SMP */
|
2006-07-01 19:36:18 +08:00
|
|
|
|
2006-12-07 09:14:08 +08:00
|
|
|
#ifdef CONFIG_PARAVIRT
|
2009-08-19 15:40:48 +08:00
|
|
|
void __init_or_module apply_paravirt(struct paravirt_patch_site *start,
|
|
|
|
struct paravirt_patch_site *end)
|
2006-12-07 09:14:08 +08:00
|
|
|
{
|
2007-05-03 01:27:14 +08:00
|
|
|
struct paravirt_patch_site *p;
|
2019-04-25 19:03:31 +08:00
|
|
|
char insn_buff[MAX_PATCH_LEN];
|
2006-12-07 09:14:08 +08:00
|
|
|
|
|
|
|
for (p = start; p < end; p++) {
|
|
|
|
unsigned int used;
|
|
|
|
|
2007-08-11 04:31:03 +08:00
|
|
|
BUG_ON(p->len > MAX_PATCH_LEN);
|
2007-08-19 05:31:41 +08:00
|
|
|
/* prep the buffer with the original instructions */
|
2019-04-25 19:03:31 +08:00
|
|
|
memcpy(insn_buff, p->instr, p->len);
|
2019-04-25 19:17:01 +08:00
|
|
|
used = pv_ops.init.patch(p->type, insn_buff, (unsigned long)p->instr, p->len);
|
2007-05-03 01:27:13 +08:00
|
|
|
|
2007-05-03 01:27:14 +08:00
|
|
|
BUG_ON(used > p->len);
|
|
|
|
|
2006-12-07 09:14:08 +08:00
|
|
|
/* Pad the rest with nops */
|
2019-04-25 19:03:31 +08:00
|
|
|
add_nops(insn_buff + used, p->len - used);
|
|
|
|
text_poke_early(p->instr, insn_buff, p->len);
|
2006-12-07 09:14:08 +08:00
|
|
|
}
|
|
|
|
}
|
2007-05-03 01:27:14 +08:00
|
|
|
extern struct paravirt_patch_site __start_parainstructions[],
|
2006-12-07 09:14:08 +08:00
|
|
|
__stop_parainstructions[];
|
|
|
|
#endif /* CONFIG_PARAVIRT */
|
|
|
|
|
2019-05-03 18:22:47 +08:00
|
|
|
/*
|
|
|
|
* Self-test for the INT3 based CALL emulation code.
|
|
|
|
*
|
|
|
|
* This exercises int3_emulate_call() to make sure INT3 pt_regs are set up
|
|
|
|
* properly and that there is a stack gap between the INT3 frame and the
|
|
|
|
* previous context. Without this gap doing a virtual PUSH on the interrupted
|
|
|
|
* stack would corrupt the INT3 IRET frame.
|
|
|
|
*
|
|
|
|
* See entry_{32,64}.S for more details.
|
|
|
|
*/
|
2019-07-09 04:55:30 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We define the int3_magic() function in assembly to control the calling
|
|
|
|
* convention such that we can 'call' it from assembly.
|
|
|
|
*/
|
|
|
|
|
|
|
|
extern void int3_magic(unsigned int *ptr); /* defined in asm */
|
|
|
|
|
|
|
|
asm (
|
|
|
|
" .pushsection .init.text, \"ax\", @progbits\n"
|
|
|
|
" .type int3_magic, @function\n"
|
|
|
|
"int3_magic:\n"
|
|
|
|
" movl $1, (%" _ASM_ARG1 ")\n"
|
|
|
|
" ret\n"
|
|
|
|
" .size int3_magic, .-int3_magic\n"
|
|
|
|
" .popsection\n"
|
|
|
|
);
|
2019-05-03 18:22:47 +08:00
|
|
|
|
|
|
|
extern __initdata unsigned long int3_selftest_ip; /* defined in asm below */
|
|
|
|
|
|
|
|
static int __init
|
|
|
|
int3_exception_notify(struct notifier_block *self, unsigned long val, void *data)
|
|
|
|
{
|
|
|
|
struct die_args *args = data;
|
|
|
|
struct pt_regs *regs = args->regs;
|
|
|
|
|
|
|
|
if (!regs || user_mode(regs))
|
|
|
|
return NOTIFY_DONE;
|
|
|
|
|
|
|
|
if (val != DIE_INT3)
|
|
|
|
return NOTIFY_DONE;
|
|
|
|
|
|
|
|
if (regs->ip - INT3_INSN_SIZE != int3_selftest_ip)
|
|
|
|
return NOTIFY_DONE;
|
|
|
|
|
|
|
|
int3_emulate_call(regs, (unsigned long)&int3_magic);
|
|
|
|
return NOTIFY_STOP;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init int3_selftest(void)
|
|
|
|
{
|
|
|
|
static __initdata struct notifier_block int3_exception_nb = {
|
|
|
|
.notifier_call = int3_exception_notify,
|
|
|
|
.priority = INT_MAX-1, /* last */
|
|
|
|
};
|
|
|
|
unsigned int val = 0;
|
|
|
|
|
|
|
|
BUG_ON(register_die_notifier(&int3_exception_nb));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Basically: int3_magic(&val); but really complicated :-)
|
|
|
|
*
|
|
|
|
* Stick the address of the INT3 instruction into int3_selftest_ip,
|
|
|
|
* then trigger the INT3, padded with NOPs to match a CALL instruction
|
|
|
|
* length.
|
|
|
|
*/
|
|
|
|
asm volatile ("1: int3; nop; nop; nop; nop\n\t"
|
|
|
|
".pushsection .init.data,\"aw\"\n\t"
|
|
|
|
".align " __ASM_SEL(4, 8) "\n\t"
|
|
|
|
".type int3_selftest_ip, @object\n\t"
|
|
|
|
".size int3_selftest_ip, " __ASM_SEL(4, 8) "\n\t"
|
|
|
|
"int3_selftest_ip:\n\t"
|
|
|
|
__ASM_SEL(.long, .quad) " 1b\n\t"
|
|
|
|
".popsection\n\t"
|
2019-07-09 04:55:30 +08:00
|
|
|
: ASM_CALL_CONSTRAINT
|
|
|
|
: __ASM_SEL_RAW(a, D) (&val)
|
|
|
|
: "memory");
|
2019-05-03 18:22:47 +08:00
|
|
|
|
|
|
|
BUG_ON(val != 1);
|
|
|
|
|
|
|
|
unregister_die_notifier(&int3_exception_nb);
|
|
|
|
}
|
|
|
|
|
2006-03-23 18:59:32 +08:00
|
|
|
void __init alternative_instructions(void)
|
|
|
|
{
|
2019-05-03 18:22:47 +08:00
|
|
|
int3_selftest();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The patching is not fully atomic, so try to avoid local
|
|
|
|
* interruptions that might execute the to be patched code.
|
|
|
|
* Other CPUs are not running.
|
|
|
|
*/
|
2007-07-22 17:12:32 +08:00
|
|
|
stop_nmi();
|
2009-02-12 20:39:27 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't stop machine check exceptions while patching.
|
|
|
|
* MCEs only happen when something got corrupted and in this
|
|
|
|
* case we must do something about the corruption.
|
2019-09-02 20:02:59 +08:00
|
|
|
* Ignoring it is worse than an unlikely patching race.
|
2009-02-12 20:39:27 +08:00
|
|
|
* Also machine checks tend to be broadcast and if one CPU
|
|
|
|
* goes into machine check the others follow quickly, so we don't
|
|
|
|
* expect a machine check to cause undue problems during to code
|
|
|
|
* patching.
|
|
|
|
*/
|
2007-07-22 17:12:32 +08:00
|
|
|
|
2024-06-11 20:26:44 +08:00
|
|
|
#if defined(CONFIG_NUMA_AWARE_SPINLOCKS)
|
|
|
|
cna_configure_spin_lock_slowpath();
|
|
|
|
#endif
|
|
|
|
|
2006-03-23 18:59:32 +08:00
|
|
|
apply_alternatives(__alt_instructions, __alt_instructions_end);
|
|
|
|
|
2006-07-01 19:36:18 +08:00
|
|
|
#ifdef CONFIG_SMP
|
2012-08-06 15:59:49 +08:00
|
|
|
/* Patch to UP if other cpus not imminent. */
|
|
|
|
if (!noreplace_smp && (num_present_cpus() == 1 || setup_max_cpus <= 1)) {
|
|
|
|
uniproc_patched = true;
|
2006-03-23 18:59:32 +08:00
|
|
|
alternatives_smp_module_add(NULL, "core kernel",
|
|
|
|
__smp_locks, __smp_locks_end,
|
|
|
|
_text, _etext);
|
|
|
|
}
|
2007-07-22 17:12:32 +08:00
|
|
|
|
2019-05-03 18:22:47 +08:00
|
|
|
if (!uniproc_patched || num_possible_cpus() == 1) {
|
2007-10-18 00:04:34 +08:00
|
|
|
free_init_pages("SMP alternatives",
|
|
|
|
(unsigned long)__smp_locks,
|
|
|
|
(unsigned long)__smp_locks_end);
|
2019-05-03 18:22:47 +08:00
|
|
|
}
|
2012-08-06 15:59:49 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
apply_paravirt(__parainstructions, __parainstructions_end);
|
2007-10-18 00:04:34 +08:00
|
|
|
|
2007-07-22 17:12:32 +08:00
|
|
|
restart_nmi();
|
2015-04-30 15:09:26 +08:00
|
|
|
alternatives_patched = 1;
|
2006-03-23 18:59:32 +08:00
|
|
|
}
|
2007-07-22 17:12:31 +08:00
|
|
|
|
2008-03-06 21:48:49 +08:00
|
|
|
/**
|
|
|
|
* text_poke_early - Update instructions on a live kernel at boot time
|
|
|
|
* @addr: address to modify
|
|
|
|
* @opcode: source of the copy
|
|
|
|
* @len: length to copy
|
|
|
|
*
|
2007-07-22 17:12:31 +08:00
|
|
|
* When you use this code to patch more than one byte of an instruction
|
|
|
|
* you need to make sure that other CPUs cannot execute this code in parallel.
|
2008-03-06 21:48:49 +08:00
|
|
|
* Also no thread must be currently preempted in the middle of these
|
2019-09-02 20:02:59 +08:00
|
|
|
* instructions. And on the local CPU you need to be protected against NMI or
|
|
|
|
* MCE handlers seeing an inconsistent instruction while you patch.
|
2007-07-22 17:12:31 +08:00
|
|
|
*/
|
2019-04-26 08:11:33 +08:00
|
|
|
void __init_or_module text_poke_early(void *addr, const void *opcode,
|
|
|
|
size_t len)
|
2007-07-22 17:12:31 +08:00
|
|
|
{
|
2008-03-06 21:48:49 +08:00
|
|
|
unsigned long flags;
|
2019-04-26 08:11:31 +08:00
|
|
|
|
|
|
|
if (boot_cpu_has(X86_FEATURE_NX) &&
|
|
|
|
is_module_text_address((unsigned long)addr)) {
|
|
|
|
/*
|
|
|
|
* Modules text is marked initially as non-executable, so the
|
|
|
|
* code cannot be running and speculative code-fetches are
|
|
|
|
* prevented. Just change the code.
|
|
|
|
*/
|
|
|
|
memcpy(addr, opcode, len);
|
|
|
|
} else {
|
|
|
|
local_irq_save(flags);
|
|
|
|
memcpy(addr, opcode, len);
|
|
|
|
local_irq_restore(flags);
|
|
|
|
sync_core();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Could also do a CLFLUSH here to speed up CPU recovery; but
|
|
|
|
* that causes hangs on some VIA CPUs.
|
|
|
|
*/
|
|
|
|
}
|
2008-03-06 21:48:49 +08:00
|
|
|
}
|
|
|
|
|
2019-04-27 07:22:46 +08:00
|
|
|
__ro_after_init struct mm_struct *poking_mm;
|
|
|
|
__ro_after_init unsigned long poking_addr;
|
|
|
|
|
2019-04-26 08:11:21 +08:00
|
|
|
static void *__text_poke(void *addr, const void *opcode, size_t len)
|
2008-03-06 21:48:49 +08:00
|
|
|
{
|
2019-04-26 08:11:27 +08:00
|
|
|
bool cross_page_boundary = offset_in_page(addr) + len > PAGE_SIZE;
|
|
|
|
struct page *pages[2] = {NULL};
|
|
|
|
temp_mm_state_t prev;
|
2009-03-06 23:37:54 +08:00
|
|
|
unsigned long flags;
|
2019-04-26 08:11:27 +08:00
|
|
|
pte_t pte, *ptep;
|
|
|
|
spinlock_t *ptl;
|
|
|
|
pgprot_t pgprot;
|
2008-03-06 21:48:49 +08:00
|
|
|
|
2018-07-20 04:55:27 +08:00
|
|
|
/*
|
2019-04-26 08:11:27 +08:00
|
|
|
* While boot memory allocator is running we cannot use struct pages as
|
|
|
|
* they are not yet initialized. There is no way to recover.
|
2018-07-20 04:55:27 +08:00
|
|
|
*/
|
|
|
|
BUG_ON(!after_bootmem);
|
|
|
|
|
2008-04-24 23:03:33 +08:00
|
|
|
if (!core_kernel_text((unsigned long)addr)) {
|
|
|
|
pages[0] = vmalloc_to_page(addr);
|
2019-04-26 08:11:27 +08:00
|
|
|
if (cross_page_boundary)
|
|
|
|
pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
|
x86: fix test_poke for vmalloced pages
* Ingo Molnar (mingo@elte.hu) wrote:
>
> * Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
>
> > The shadow vmap for DEBUG_RODATA kernel text modification uses
> > virt_to_page to get the pages from the pointer address.
> >
> > However, I think vmalloc_to_page would be required in case the page is
> > used for modules.
> >
> > Since only the core kernel text is marked read-only, use
> > kernel_text_address() to make sure we only shadow map the core kernel
> > text, not modules.
>
> actually, i think we should mark module text readonly too.
>
Yes, but in the meantime, the x86 tree would need this patch to make
kprobes work correctly on modules.
I suspect that without this fix, with the enhanced hotplug and kprobes
patch, kprobes will use text_poke to insert breakpoints in modules
(vmalloced pages used), which will map the wrong pages and corrupt
random kernel locations instead of updating the correct page.
Work that would write protect the module pages should clearly be done,
but it can come in a later time. We have to make sure we interact
correctly with the page allocation debugging, as an example.
Here is the patch against x86.git 2.6.25-rc5 :
The shadow vmap for DEBUG_RODATA kernel text modification uses virt_to_page to
get the pages from the pointer address.
However, I think vmalloc_to_page would be required in case the page is used for
modules.
Since only the core kernel text is marked read-only, use kernel_text_address()
to make sure we only shadow map the core kernel text, not modules.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: akpm@linux-foundation.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-12 23:54:16 +08:00
|
|
|
} else {
|
2008-04-24 23:03:33 +08:00
|
|
|
pages[0] = virt_to_page(addr);
|
2008-04-25 23:07:03 +08:00
|
|
|
WARN_ON(!PageReserved(pages[0]));
|
2019-04-26 08:11:27 +08:00
|
|
|
if (cross_page_boundary)
|
|
|
|
pages[1] = virt_to_page(addr + PAGE_SIZE);
|
2008-03-06 21:48:49 +08:00
|
|
|
}
|
2019-04-26 08:11:27 +08:00
|
|
|
/*
|
|
|
|
* If something went wrong, crash and burn since recovery paths are not
|
|
|
|
* implemented.
|
|
|
|
*/
|
|
|
|
BUG_ON(!pages[0] || (cross_page_boundary && !pages[1]));
|
|
|
|
|
2009-03-10 00:40:40 +08:00
|
|
|
local_irq_save(flags);
|
2019-04-26 08:11:27 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Map the page without the global bit, as TLB flushing is done with
|
|
|
|
* flush_tlb_mm_range(), which is intended for non-global PTEs.
|
|
|
|
*/
|
|
|
|
pgprot = __pgprot(pgprot_val(PAGE_KERNEL) & ~_PAGE_GLOBAL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The lock is not really needed, but this allows to avoid open-coding.
|
|
|
|
*/
|
|
|
|
ptep = get_locked_pte(poking_mm, poking_addr, &ptl);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This must not fail; preallocated in poking_init().
|
|
|
|
*/
|
|
|
|
VM_BUG_ON(!ptep);
|
|
|
|
|
|
|
|
pte = mk_pte(pages[0], pgprot);
|
|
|
|
set_pte_at(poking_mm, poking_addr, ptep, pte);
|
|
|
|
|
|
|
|
if (cross_page_boundary) {
|
|
|
|
pte = mk_pte(pages[1], pgprot);
|
|
|
|
set_pte_at(poking_mm, poking_addr + PAGE_SIZE, ptep + 1, pte);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Loading the temporary mm behaves as a compiler barrier, which
|
|
|
|
* guarantees that the PTE will be set at the time memcpy() is done.
|
|
|
|
*/
|
|
|
|
prev = use_temporary_mm(poking_mm);
|
|
|
|
|
|
|
|
kasan_disable_current();
|
|
|
|
memcpy((u8 *)poking_addr + offset_in_page(addr), opcode, len);
|
|
|
|
kasan_enable_current();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure that the PTE is only cleared after the instructions of memcpy
|
|
|
|
* were issued by using a compiler barrier.
|
|
|
|
*/
|
|
|
|
barrier();
|
|
|
|
|
|
|
|
pte_clear(poking_mm, poking_addr, ptep);
|
|
|
|
if (cross_page_boundary)
|
|
|
|
pte_clear(poking_mm, poking_addr + PAGE_SIZE, ptep + 1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Loading the previous page-table hierarchy requires a serializing
|
|
|
|
* instruction that already allows the core to see the updated version.
|
|
|
|
* Xen-PV is assumed to serialize execution in a similar manner.
|
|
|
|
*/
|
|
|
|
unuse_temporary_mm(prev);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Flushing the TLB might involve IPIs, which would require enabled
|
|
|
|
* IRQs, but not if the mm is not used, as it is in this point.
|
|
|
|
*/
|
|
|
|
flush_tlb_mm_range(poking_mm, poking_addr, poking_addr +
|
|
|
|
(cross_page_boundary ? 2 : 1) * PAGE_SIZE,
|
|
|
|
PAGE_SHIFT, false);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the text does not match what we just wrote then something is
|
|
|
|
* fundamentally screwy; there's nothing we can really do about that.
|
|
|
|
*/
|
|
|
|
BUG_ON(memcmp(addr, opcode, len));
|
|
|
|
|
|
|
|
pte_unmap_unlock(ptep, ptl);
|
2009-03-10 00:40:40 +08:00
|
|
|
local_irq_restore(flags);
|
2008-03-06 21:48:49 +08:00
|
|
|
return addr;
|
2007-07-22 17:12:31 +08:00
|
|
|
}
|
2010-02-25 21:34:38 +08:00
|
|
|
|
2019-04-26 08:11:21 +08:00
|
|
|
/**
|
|
|
|
* text_poke - Update instructions on a live kernel
|
|
|
|
* @addr: address to modify
|
|
|
|
* @opcode: source of the copy
|
|
|
|
* @len: length to copy
|
|
|
|
*
|
|
|
|
* Only atomic text poke/set should be allowed when not doing early patching.
|
|
|
|
* It means the size must be writable atomically and the address must be aligned
|
|
|
|
* in a way that permits an atomic write. It also makes sure we fit on a single
|
|
|
|
* page.
|
2019-04-26 08:11:41 +08:00
|
|
|
*
|
|
|
|
* Note that the caller must ensure that if the modified code is part of a
|
|
|
|
* module, the module would not be removed during poking. This can be achieved
|
|
|
|
* by registering a module notifier, and ordering module removal and patching
|
|
|
|
* trough a mutex.
|
2019-04-26 08:11:21 +08:00
|
|
|
*/
|
|
|
|
void *text_poke(void *addr, const void *opcode, size_t len)
|
|
|
|
{
|
|
|
|
lockdep_assert_held(&text_mutex);
|
|
|
|
|
|
|
|
return __text_poke(addr, opcode, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* text_poke_kgdb - Update instructions on a live kernel by kgdb
|
|
|
|
* @addr: address to modify
|
|
|
|
* @opcode: source of the copy
|
|
|
|
* @len: length to copy
|
|
|
|
*
|
|
|
|
* Only atomic text poke/set should be allowed when not doing early patching.
|
|
|
|
* It means the size must be writable atomically and the address must be aligned
|
|
|
|
* in a way that permits an atomic write. It also makes sure we fit on a single
|
|
|
|
* page.
|
|
|
|
*
|
|
|
|
* Context: should only be used by kgdb, which ensures no other core is running,
|
|
|
|
* despite the fact it does not hold the text_mutex.
|
|
|
|
*/
|
|
|
|
void *text_poke_kgdb(void *addr, const void *opcode, size_t len)
|
|
|
|
{
|
|
|
|
return __text_poke(addr, opcode, len);
|
|
|
|
}
|
|
|
|
|
2013-07-12 17:21:48 +08:00
|
|
|
static void do_sync_core(void *info)
|
|
|
|
{
|
|
|
|
sync_core();
|
|
|
|
}
|
|
|
|
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
static struct bp_patching_desc {
|
|
|
|
struct text_poke_loc *vec;
|
|
|
|
int nr_entries;
|
|
|
|
} bp_patching;
|
|
|
|
|
|
|
|
static int patch_cmp(const void *key, const void *elt)
|
|
|
|
{
|
|
|
|
struct text_poke_loc *tp = (struct text_poke_loc *) elt;
|
|
|
|
|
|
|
|
if (key < tp->addr)
|
|
|
|
return -1;
|
|
|
|
if (key > tp->addr)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
NOKPROBE_SYMBOL(patch_cmp);
|
2013-07-12 17:21:48 +08:00
|
|
|
|
2013-07-23 16:09:28 +08:00
|
|
|
int poke_int3_handler(struct pt_regs *regs)
|
2013-07-12 17:21:48 +08:00
|
|
|
{
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
struct text_poke_loc *tp;
|
|
|
|
unsigned char int3 = 0xcc;
|
|
|
|
void *ip;
|
|
|
|
|
2017-07-31 18:21:54 +08:00
|
|
|
/*
|
|
|
|
* Having observed our INT3 instruction, we now must observe
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
* bp_patching.nr_entries.
|
2017-07-31 18:21:54 +08:00
|
|
|
*
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
* nr_entries != 0 INT3
|
2017-07-31 18:21:54 +08:00
|
|
|
* WMB RMB
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
* write INT3 if (nr_entries)
|
2017-07-31 18:21:54 +08:00
|
|
|
*
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
* Idem for other elements in bp_patching.
|
2017-07-31 18:21:54 +08:00
|
|
|
*/
|
2013-07-12 17:21:48 +08:00
|
|
|
smp_rmb();
|
|
|
|
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
if (likely(!bp_patching.nr_entries))
|
2013-07-23 16:09:28 +08:00
|
|
|
return 0;
|
2013-07-12 17:21:48 +08:00
|
|
|
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
if (user_mode(regs))
|
2013-07-23 16:09:28 +08:00
|
|
|
return 0;
|
2013-07-12 17:21:48 +08:00
|
|
|
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
/*
|
|
|
|
* Discount the sizeof(int3). See text_poke_bp_batch().
|
|
|
|
*/
|
|
|
|
ip = (void *) regs->ip - sizeof(int3);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip the binary search if there is a single member in the vector.
|
|
|
|
*/
|
|
|
|
if (unlikely(bp_patching.nr_entries > 1)) {
|
|
|
|
tp = bsearch(ip, bp_patching.vec, bp_patching.nr_entries,
|
|
|
|
sizeof(struct text_poke_loc),
|
|
|
|
patch_cmp);
|
|
|
|
if (!tp)
|
|
|
|
return 0;
|
|
|
|
} else {
|
|
|
|
tp = bp_patching.vec;
|
|
|
|
if (tp->addr != ip)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* set up the specified breakpoint detour */
|
|
|
|
regs->ip = (unsigned long) tp->detour;
|
2013-07-23 16:09:28 +08:00
|
|
|
|
|
|
|
return 1;
|
2013-07-12 17:21:48 +08:00
|
|
|
}
|
2019-02-13 00:12:15 +08:00
|
|
|
NOKPROBE_SYMBOL(poke_int3_handler);
|
2013-07-23 16:09:28 +08:00
|
|
|
|
2013-07-12 17:21:48 +08:00
|
|
|
/**
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
* text_poke_bp_batch() -- update instructions on live kernel on SMP
|
|
|
|
* @tp: vector of instructions to patch
|
|
|
|
* @nr_entries: number of entries in the vector
|
2013-07-12 17:21:48 +08:00
|
|
|
*
|
|
|
|
* Modify multi-byte instruction by using int3 breakpoint on SMP.
|
2013-07-18 19:47:53 +08:00
|
|
|
* We completely avoid stop_machine() here, and achieve the
|
|
|
|
* synchronization using int3 breakpoint.
|
2013-07-12 17:21:48 +08:00
|
|
|
*
|
|
|
|
* The way it is done:
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
* - For each entry in the vector:
|
|
|
|
* - add a int3 trap to the address that will be patched
|
2013-07-12 17:21:48 +08:00
|
|
|
* - sync cores
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
* - For each entry in the vector:
|
|
|
|
* - update all but the first byte of the patched range
|
2013-07-12 17:21:48 +08:00
|
|
|
* - sync cores
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
* - For each entry in the vector:
|
|
|
|
* - replace the first byte (int3) by the first byte of
|
|
|
|
* replacing opcode
|
2013-07-12 17:21:48 +08:00
|
|
|
* - sync cores
|
|
|
|
*/
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
void text_poke_bp_batch(struct text_poke_loc *tp, unsigned int nr_entries)
|
2013-07-12 17:21:48 +08:00
|
|
|
{
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
int patched_all_but_first = 0;
|
2013-07-12 17:21:48 +08:00
|
|
|
unsigned char int3 = 0xcc;
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
unsigned int i;
|
2018-08-28 14:55:14 +08:00
|
|
|
|
|
|
|
lockdep_assert_held(&text_mutex);
|
|
|
|
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
bp_patching.vec = tp;
|
|
|
|
bp_patching.nr_entries = nr_entries;
|
|
|
|
|
2013-07-12 17:21:48 +08:00
|
|
|
/*
|
2017-07-31 18:21:54 +08:00
|
|
|
* Corresponding read barrier in int3 notifier for making sure the
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
* nr_entries and handler are correctly ordered wrt. patching.
|
2013-07-12 17:21:48 +08:00
|
|
|
*/
|
|
|
|
smp_wmb();
|
|
|
|
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
/*
|
|
|
|
* First step: add a int3 trap to the address that will be patched.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < nr_entries; i++)
|
|
|
|
text_poke(tp[i].addr, &int3, sizeof(int3));
|
2013-07-12 17:21:48 +08:00
|
|
|
|
|
|
|
on_each_cpu(do_sync_core, NULL, 1);
|
|
|
|
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
/*
|
|
|
|
* Second step: update all but the first byte of the patched range.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < nr_entries; i++) {
|
|
|
|
if (tp[i].len - sizeof(int3) > 0) {
|
|
|
|
text_poke((char *)tp[i].addr + sizeof(int3),
|
|
|
|
(const char *)tp[i].opcode + sizeof(int3),
|
|
|
|
tp[i].len - sizeof(int3));
|
|
|
|
patched_all_but_first++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (patched_all_but_first) {
|
2013-07-12 17:21:48 +08:00
|
|
|
/*
|
|
|
|
* According to Intel, this core syncing is very likely
|
|
|
|
* not necessary and we'd be safe even without it. But
|
|
|
|
* better safe than sorry (plus there's not only Intel).
|
|
|
|
*/
|
|
|
|
on_each_cpu(do_sync_core, NULL, 1);
|
|
|
|
}
|
|
|
|
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
/*
|
|
|
|
* Third step: replace the first byte (int3) by the first byte of
|
|
|
|
* replacing opcode.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < nr_entries; i++)
|
|
|
|
text_poke(tp[i].addr, tp[i].opcode, sizeof(int3));
|
2013-07-12 17:21:48 +08:00
|
|
|
|
|
|
|
on_each_cpu(do_sync_core, NULL, 1);
|
2017-07-31 18:21:54 +08:00
|
|
|
/*
|
|
|
|
* sync_core() implies an smp_mb() and orders this store against
|
|
|
|
* the writing of the new instruction.
|
|
|
|
*/
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
bp_patching.vec = NULL;
|
|
|
|
bp_patching.nr_entries = 0;
|
2013-07-12 17:21:48 +08:00
|
|
|
}
|
|
|
|
|
x86/alternative: Batch of patch operations
Currently, the patch of an address is done in three steps:
-- Pseudo-code #1 - Current implementation ---
1) add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #1 ---
When a static key has more than one entry, these steps are called once for
each entry. The number of IPIs then is linear with regard to the number 'n' of
entries of a key: O(n*3), which is O(n).
This algorithm works fine for the update of a single key. But we think
it is possible to optimize the case in which a static key has more than
one entry. For instance, the sched_schedstats jump label has 56 entries
in my (updated) fedora kernel, resulting in 168 IPIs for each CPU in
which the thread that is enabling the key is _not_ running.
With this patch, rather than receiving a single patch to be processed, a vector
of patches is passed, enabling the rewrite of the pseudo-code #1 in this
way:
-- Pseudo-code #2 - This patch ---
1) for each patch in the vector:
add an int3 trap to the address that will be patched
sync cores (send IPI to all other CPUs)
2) for each patch in the vector:
update all but the first byte of the patched range
sync cores (send IPI to all other CPUs)
3) for each patch in the vector:
replace the first byte (int3) by the first byte of replacing opcode
sync cores (send IPI to all other CPUs)
-- Pseudo-code #2 - This patch ---
Doing the update in this way, the number of IPI becomes O(3) with regard
to the number of keys, which is O(1).
The batch mode is done with the function text_poke_bp_batch(), that receives
two arguments: a vector of "struct text_to_poke", and the number of entries
in the vector.
The vector must be sorted by the addr field of the text_to_poke structure,
enabling the binary search of a handler in the poke_int3_handler function
(a fast path).
Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris von Recklinghausen <crecklin@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Scott Wood <swood@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/ca506ed52584c80f64de23f6f55ca288e5d079de.1560325897.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-06-12 17:57:29 +08:00
|
|
|
/**
|
|
|
|
* text_poke_bp() -- update instructions on live kernel on SMP
|
|
|
|
* @addr: address to patch
|
|
|
|
* @opcode: opcode of new instruction
|
|
|
|
* @len: length to copy
|
|
|
|
* @handler: address to jump to when the temporary breakpoint is hit
|
|
|
|
*
|
|
|
|
* Update a single instruction with the vector in the stack, avoiding
|
|
|
|
* dynamically allocated memory. This function should be used when it is
|
|
|
|
* not possible to allocate memory.
|
|
|
|
*/
|
|
|
|
void text_poke_bp(void *addr, const void *opcode, size_t len, void *handler)
|
|
|
|
{
|
|
|
|
struct text_poke_loc tp = {
|
|
|
|
.detour = handler,
|
|
|
|
.addr = addr,
|
|
|
|
.len = len,
|
|
|
|
};
|
|
|
|
|
|
|
|
if (len > POKE_MAX_OPCODE_SIZE) {
|
|
|
|
WARN_ONCE(1, "len is larger than %d\n", POKE_MAX_OPCODE_SIZE);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
memcpy((void *)tp.opcode, opcode, len);
|
|
|
|
|
|
|
|
text_poke_bp_batch(&tp, 1);
|
|
|
|
}
|