09 Feb, 2016

1 commit

  • Also, keep the churn at minimum by adjusting the include "perf_event.h"
    when each file gets moved.

    Signed-off-by: Borislav Petkov
    Cc: Arnaldo Carvalho de Melo
    Cc: Jiri Olsa
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: Thomas Gleixner
    Cc: Vince Weaver
    Link: http://lkml.kernel.org/r/1454947748-28629-2-git-send-email-bp@alien8.de
    Signed-off-by: Ingo Molnar

    Borislav Petkov
     

04 Jun, 2015

2 commits


30 Aug, 2014

1 commit

  • Currently new system call kexec_file_load() and all the associated code
    compiles if CONFIG_KEXEC=y. But new syscall also compiles purgatory
    code which currently uses gcc option -mcmodel=large. This option seems
    to be available only gcc 4.4 onwards.

    Hiding new functionality behind a new config option will not break
    existing users of old gcc. Those who wish to enable new functionality
    will require new gcc. Having said that, I am trying to figure out how
    can I move away from using -mcmodel=large but that can take a while.

    I think there are other advantages of introducing this new config
    option. As this option will be enabled only on x86_64, other arches
    don't have to compile generic kexec code which will never be used. This
    new code selects CRYPTO=y and CRYPTO_SHA256=y. And all other arches had
    to do this for CONFIG_KEXEC. Now with introduction of new config
    option, we can remove crypto dependency from other arches.

    Now CONFIG_KEXEC_FILE is available only on x86_64. So whereever I had
    CONFIG_X86_64 defined, I got rid of that.

    For CONFIG_KEXEC_FILE, instead of doing select CRYPTO=y, I changed it to
    "depends on CRYPTO=y". This should be safer as "select" is not
    recursive.

    Signed-off-by: Vivek Goyal
    Cc: Eric Biederman
    Cc: H. Peter Anvin
    Tested-by: Shaun Ruffell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vivek Goyal
     

09 Aug, 2014

1 commit

  • Create a stand alone relocatable object purgatory which runs between two
    kernels. This name, concept and some code has been taken from
    kexec-tools. Idea is that this code runs after a crash and it runs in
    minimal environment. So keep it separate from rest of the kernel and in
    long term we will have to practically do no maintenance of this code.

    This code also has the logic to do verify sha256 hashes of various
    segments which have been loaded into memory. So first we verify that the
    kernel we are jumping to is fine and has not been corrupted and make
    progress only if checsums are verified.

    This code also takes care of copying some memory contents to backup region.

    [sfr@canb.auug.org.au: run host built programs from objtree]
    Signed-off-by: Vivek Goyal
    Cc: Borislav Petkov
    Cc: Michael Kerrisk
    Cc: Yinghai Lu
    Cc: Eric Biederman
    Cc: H. Peter Anvin
    Cc: Matthew Garrett
    Cc: Greg Kroah-Hartman
    Cc: Dave Young
    Cc: WANG Chao
    Cc: Baoquan He
    Cc: Andy Lutomirski
    Signed-off-by: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vivek Goyal
     

09 May, 2012

1 commit

  • Create realmode.bin and realmode.relocs files. Piggy
    pack them into relocatable object that will be included
    into .init.data section of the main kernel image.

    The first file includes binary image of the real-mode code.
    The latter file includes all relocations. The layout of the
    binary image is specified in realmode.lds.S. The makefile
    generates pa_ prefixed symbols for each exported global.
    These are used in 32-bit code and in realmode header to
    define symbols that need to be relocated.

    Signed-off-by: Jarkko Sakkinen
    Link: http://lkml.kernel.org/r/1336501366-28617-3-git-send-email-jarkko.sakkinen@intel.com
    Originally-by: H. Peter Anvin
    Signed-off-by: H. Peter Anvin

    Jarkko Sakkinen
     

28 Apr, 2011

1 commit

  • In order to speedup packet filtering, here is an implementation of a
    JIT compiler for x86_64

    It is disabled by default, and must be enabled by the admin.

    echo 1 >/proc/sys/net/core/bpf_jit_enable

    It uses module_alloc() and module_free() to get memory in the 2GB text
    kernel range since we call helpers functions from the generated code.

    EAX : BPF A accumulator
    EBX : BPF X accumulator
    RDI : pointer to skb (first argument given to JIT function)
    RBP : frame pointer (even if CONFIG_FRAME_POINTER=n)
    r9d : skb->len - skb->data_len (headlen)
    r8 : skb->data

    To get a trace of generated code, use :

    echo 2 >/proc/sys/net/core/bpf_jit_enable

    Example of generated code :

    # tcpdump -p -n -s 0 -i eth1 host 192.168.20.0/24

    flen=18 proglen=147 pass=3 image=ffffffffa00b5000
    JIT code: ffffffffa00b5000: 55 48 89 e5 48 83 ec 60 48 89 5d f8 44 8b 4f 60
    JIT code: ffffffffa00b5010: 44 2b 4f 64 4c 8b 87 b8 00 00 00 be 0c 00 00 00
    JIT code: ffffffffa00b5020: e8 24 7b f7 e0 3d 00 08 00 00 75 28 be 1a 00 00
    JIT code: ffffffffa00b5030: 00 e8 fe 7a f7 e0 24 00 3d 00 14 a8 c0 74 49 be
    JIT code: ffffffffa00b5040: 1e 00 00 00 e8 eb 7a f7 e0 24 00 3d 00 14 a8 c0
    JIT code: ffffffffa00b5050: 74 36 eb 3b 3d 06 08 00 00 74 07 3d 35 80 00 00
    JIT code: ffffffffa00b5060: 75 2d be 1c 00 00 00 e8 c8 7a f7 e0 24 00 3d 00
    JIT code: ffffffffa00b5070: 14 a8 c0 74 13 be 26 00 00 00 e8 b5 7a f7 e0 24
    JIT code: ffffffffa00b5080: 00 3d 00 14 a8 c0 75 07 b8 ff ff 00 00 eb 02 31
    JIT code: ffffffffa00b5090: c0 c9 c3

    BPF program is 144 bytes long, so native program is almost same size ;)

    (000) ldh [12]
    (001) jeq #0x800 jt 2 jf 8
    (002) ld [26]
    (003) and #0xffffff00
    (004) jeq #0xc0a81400 jt 16 jf 5
    (005) ld [30]
    (006) and #0xffffff00
    (007) jeq #0xc0a81400 jt 16 jf 17
    (008) jeq #0x806 jt 10 jf 9
    (009) jeq #0x8035 jt 10 jf 17
    (010) ld [28]
    (011) and #0xffffff00
    (012) jeq #0xc0a81400 jt 16 jf 13
    (013) ld [38]
    (014) and #0xffffff00
    (015) jeq #0xc0a81400 jt 16 jf 17
    (016) ret #65535
    (017) ret #0

    Signed-off-by: Eric Dumazet
    Cc: Arnaldo Carvalho de Melo
    Cc: Ben Hutchings
    Cc: Hagen Paul Pfeifer
    Signed-off-by: David S. Miller

    Eric Dumazet
     

27 Oct, 2010

1 commit

  • x86 has finally arrived in the embedded nightmare and will rapidly
    grow SoC platform support in various flavours. So we need a place for
    the platform support files. That also allows us to clean up the
    dumpground which arch/x86/kernel has become over time.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

17 Apr, 2009

1 commit