Re: [PATCH v2 00/15] x86, alternatives: Instruction padding and more robust JMPs

[Andy Lutomirski]

On Tue, Feb 24, 2015 at 3:14 AM, Borislav Petkov <bp@xxxxxxxxx> wrote:
> From: Borislav Petkov <bp@xxxxxxx>
>
>   [ Changelog is in version-increasing number so that one can follow the
>     evolution of the patch set in a more natural way (i.e., latest version
>     comes at the end. ]
>
> v0:
>
> this is something which hpa and I talked about recently: the ability for
> the alternatives code to add padding to the original instruction in case
> the replacement is longer and also to be able to simply write "jmp" and
> not care about which JMP exactly the compiler generates and whether the
> relative offsets are correct.
>
> So this is a stab at it, it seems to boot in kvm here but it needs more
> staring to make sure we're actually generating the proper code at all
> times.
>
> Thus the RFC tag, comments/suggestions are welcome.
>
> v1:
>
> This is the first version which passes testing on AMD/Intel, 32/64-bit
> boxes I have here. For more info what it does, you can boot with
> "debug-alternative" to see some verbose information about what gets
> changed into what.
>
> Patches 1 and 2 are cleanups.
>
> Patch 3 is adding the padding at build time and patch 4 simplifies using
> JMPs in alternatives without having to do crazy math with labels, as a
> user of the alternatives facilities.
>
> Patch 5 optimizes the single-byte NOPs we're adding at build time to
> longer NOPs which should go easier through the frontend.
>
> Patches 6-12 then convert most of the alternative callsites to the
> generic macros and kill the homegrown fun.
>
> v2:
>
> This version reworks the NOP padding by adding a field to struct
> alt_instr which holds the padding length and thus makes the padding
> more robust than what we did before, instead of us trying to figure out
> which byte is a NOP and which byte is something else (part of a relative
> offset or immediate...).
>
> Thanks to Andy Lutomirsky for pointing that out.

:)

I'll read the NOP stuff in a minute.  In the mean time, the series
seems to work correctly for the vdso, and the vdso has fewer pointless
nops.

--Andy

>
> As always, constructive comments/suggestions are welcome.
>
> Borislav Petkov (15):
>   x86/lib/copy_user_64.S: Remove FIX_ALIGNMENT define
>   x86/alternatives: Cleanup DPRINTK macro
>   x86/alternatives: Add instruction padding
>   x86/alternatives: Make JMPs more robust
>   x86/alternatives: Use optimized NOPs for padding
>   x86/lib/copy_page_64.S: Use generic ALTERNATIVE macro
>   x86/lib/copy_user_64.S: Convert to ALTERNATIVE_2
>   x86/smap: Use ALTERNATIVE macro
>   x86/entry_32: Convert X86_INVD_BUG to ALTERNATIVE macro
>   x86/lib/clear_page_64.S: Convert to ALTERNATIVE_2 macro
>   x86/asm: Use alternative_2() in rdtsc_barrier()
>   x86/asm: Cleanup prefetch primitives
>   x86/lib/memset_64.S: Convert to ALTERNATIVE_2 macro
>   x86/lib/memmove_64.S: Convert memmove() to ALTERNATIVE macro
>   x86/lib/memcpy_64.S: Convert memcpy to ALTERNATIVE_2 macro
>
>  arch/x86/include/asm/alternative-asm.h |  43 ++++++++-
>  arch/x86/include/asm/alternative.h     |  65 ++++++++------
>  arch/x86/include/asm/apic.h            |   2 +-
>  arch/x86/include/asm/barrier.h         |   6 +-
>  arch/x86/include/asm/cpufeature.h      |  30 ++++---
>  arch/x86/include/asm/processor.h       |  16 ++--
>  arch/x86/include/asm/smap.h            |  30 ++-----
>  arch/x86/kernel/alternative.c          | 158 ++++++++++++++++++++++++++++-----
>  arch/x86/kernel/cpu/amd.c              |   5 ++
>  arch/x86/kernel/entry_32.S             |  12 +--
>  arch/x86/lib/clear_page_64.S           |  66 ++++++--------
>  arch/x86/lib/copy_page_64.S            |  37 +++-----
>  arch/x86/lib/copy_user_64.S            |  46 +++-------
>  arch/x86/lib/memcpy_64.S               |  68 +++++---------
>  arch/x86/lib/memmove_64.S              |  19 +---
>  arch/x86/lib/memset_64.S               |  61 +++++--------
>  arch/x86/um/asm/barrier.h              |   4 +-
>  17 files changed, 360 insertions(+), 308 deletions(-)
>
> --
> 2.2.0.33.gc18b867
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/