An error occurred fetching the project authors.
  1. 11 Jul, 2023 1 commit
  2. 25 Jun, 2023 1 commit
  3. 22 Jun, 2023 1 commit
    • Masahiro Yamada's avatar
      kbuild: generate KSYMTAB entries by modpost · ddb5cdba
      Masahiro Yamada authored
      Commit 7b453719 ("kbuild: link symbol CRCs at final link, removing
      CONFIG_MODULE_REL_CRCS") made modpost output CRCs in the same way
      whether the EXPORT_SYMBOL() is placed in *.c or *.S.
      
      For further cleanups, this commit applies a similar approach to the
      entire data structure of EXPORT_SYMBOL().
      
      The EXPORT_SYMBOL() compilation is split into two stages.
      
      When a source file is compiled, EXPORT_SYMBOL() will be converted into
      a dummy symbol in the .export_symbol section.
      
      For example,
      
          EXPORT_SYMBOL(foo);
          EXPORT_SYMBOL_NS_GPL(bar, BAR_NAMESPACE);
      
      will be encoded into the following assembly code:
      
          .section ".export_symbol","a"
          __export_symbol_foo:
                  .asciz ""                      /* license */
                  .asciz ""                      /* name space */
                  .balign 8
                  .quad foo                      /* symbol reference */
          .previous
      
          .section ".export_symbol","a"
          __export_symbol_bar:
                  .asciz "GPL"                   /* license */
                  .asciz "BAR_NAMESPACE"         /* name space */
                  .balign 8
                  .quad bar                      /* symbol reference */
          .previous
      
      They are mere markers to tell modpost the name, license, and namespace
      of the symbols. They will be dropped from the final vmlinux and modules
      because the *(.export_symbol) will go into /DISCARD/ in the linker script.
      
      Then, modpost extracts all the information about EXPORT_SYMBOL() from the
      .export_symbol section, and generates the final C code:
      
          KSYMTAB_FUNC(foo, "", "");
          KSYMTAB_FUNC(bar, "_gpl", "BAR_NAMESPACE");
      
      KSYMTAB_FUNC() (or KSYMTAB_DATA() if it is data) is expanded to struct
      kernel_symbol that will be linked to the vmlinux or a module.
      
      With this change, EXPORT_SYMBOL() works in the same way for *.c and *.S
      files, providing the following benefits.
      
      [1] Deprecate EXPORT_DATA_SYMBOL()
      
      In the old days, EXPORT_SYMBOL() was only available in C files. To export
      a symbol in *.S, EXPORT_SYMBOL() was placed in a separate *.c file.
      arch/arm/kernel/armksyms.c is one example written in the classic manner.
      
      Commit 22823ab4 ("EXPORT_SYMBOL() for asm") removed this limitation.
      Since then, EXPORT_SYMBOL() can be placed close to the symbol definition
      in *.S files. It was a nice improvement.
      
      However, as that commit mentioned, you need to use EXPORT_DATA_SYMBOL()
      for data objects on some architectures.
      
      In the new approach, modpost checks symbol's type (STT_FUNC or not),
      and outputs KSYMTAB_FUNC() or KSYMTAB_DATA() accordingly.
      
      There are only two users of EXPORT_DATA_SYMBOL:
      
        EXPORT_DATA_SYMBOL_GPL(empty_zero_page)    (arch/ia64/kernel/head.S)
        EXPORT_DATA_SYMBOL(ia64_ivt)               (arch/ia64/kernel/ivt.S)
      
      They are transformed as follows and output into .vmlinux.export.c
      
        KSYMTAB_DATA(empty_zero_page, "_gpl", "");
        KSYMTAB_DATA(ia64_ivt, "", "");
      
      The other EXPORT_SYMBOL users in ia64 assembly are output as
      KSYMTAB_FUNC().
      
      EXPORT_DATA_SYMBOL() is now deprecated.
      
      [2] merge <linux/export.h> and <asm-generic/export.h>
      
      There are two similar header implementations:
      
        include/linux/export.h        for .c files
        include/asm-generic/export.h  for .S files
      
      Ideally, the functionality should be consistent between them, but they
      tend to diverge.
      
      Commit 8651ec01 ("module: add support for symbol namespaces.") did
      not support the namespace for *.S files.
      
      This commit shifts the essential implementation part to C, which supports
      EXPORT_SYMBOL_NS() for *.S files.
      
      <asm/export.h> and <asm-generic/export.h> will remain as a wrapper of
      <linux/export.h> for a while.
      
      They will be removed after #include <asm/export.h> directives are all
      replaced with #include <linux/export.h>.
      
      [3] Implement CONFIG_TRIM_UNUSED_KSYMS in one-pass algorithm (by a later commit)
      
      When CONFIG_TRIM_UNUSED_KSYMS is enabled, Kbuild recursively traverses
      the directory tree to determine which EXPORT_SYMBOL to trim. If an
      EXPORT_SYMBOL turns out to be unused by anyone, Kbuild begins the
      second traverse, where some source files are recompiled with their
      EXPORT_SYMBOL() tuned into a no-op.
      
      We can do this better now; modpost can selectively emit KSYMTAB entries
      that are really used by modules.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      ddb5cdba
  4. 16 Jun, 2023 1 commit
  5. 16 May, 2023 1 commit
    • Josh Poimboeuf's avatar
      vmlinux.lds.h: Discard .note.gnu.property section · f7ba52f3
      Josh Poimboeuf authored
      When tooling reads ELF notes, it assumes each note entry is aligned to
      the value listed in the .note section header's sh_addralign field.
      
      The kernel-created ELF notes in the .note.Linux and .note.Xen sections
      are aligned to 4 bytes.  This causes the toolchain to set those
      sections' sh_addralign values to 4.
      
      On the other hand, the GCC-created .note.gnu.property section has an
      sh_addralign value of 8 for some reason, despite being based on struct
      Elf32_Nhdr which only needs 4-byte alignment.
      
      When the mismatched input sections get linked together into the vmlinux
      .notes output section, the higher alignment "wins", resulting in an
      sh_addralign of 8, which confuses tooling.  For example:
      
        $ readelf -n .tmp_vmlinux.btf
        ...
        readelf: .tmp_vmlinux.btf: Warning: note with invalid namesz and/or descsz found at offset 0x170
        readelf: .tmp_vmlinux.btf: Warning:  type: 0x4, namesize: 0x006e6558, descsize: 0x00008801, alignment: 8
      
      In this case readelf thinks there's alignment padding where there is
      none, so it starts reading an ELF note in the middle.
      
      With newer toolchains (e.g., latest Fedora Rawhide), a similar mismatch
      triggers a build failure when combined with CONFIG_X86_KERNEL_IBT:
      
        btf_encoder__encode: btf__dedup failed!
        Failed to encode BTF
        libbpf: failed to find '.BTF' ELF section in vmlinux
        FAILED: load BTF from vmlinux: No data available
        make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255
      
      This latter error was caused by pahole crashing when it encountered the
      corrupt .notes section.  This crash has been fixed in dwarves version
      1.25.  As Tianyi Liu describes:
      
        "Pahole reads .notes to look for LINUX_ELFNOTE_BUILD_LTO. When LTO is
         enabled, pahole needs to call cus__merge_and_process_cu to merge
         compile units, at which point there should only be one unspecified
         type (used to represent some compilation information) in the global
         context.
      
         However, when the kernel is compiled without LTO, if pahole calls
         cus__merge_and_process_cu due to alignment issues with notes,
         multiple unspecified types may appear after merging the cus, and
         older versions of pahole only support up to one. This is why pahole
         1.24 crashes, while newer versions support multiple. However, the
         latest version of pahole still does not solve the problem of
         incorrect LTO recognition, so compiling the kernel may be slower
         than normal."
      
      Even with the newer pahole, the note section misaligment issue still
      exists and pahole is misinterpreting the LTO note.  Fix it by discarding
      the .note.gnu.property section.  While GNU properties are important for
      user space (and VDSO), they don't seem to have any use for vmlinux.
      
      (In fact, they're already getting (inadvertently) stripped from vmlinux
      when CONFIG_DEBUG_INFO_BTF is enabled.  The BTF data is extracted from
      vmlinux.o with "objcopy --only-section=.BTF" into .btf.vmlinux.bin.o.
      That file doesn't have .note.gnu.property, so when it gets modified and
      linked back into the main object, the linker automatically strips it
      (see "How GNU properties are merged" in the ld man page).)
      Reported-by: default avatarDaniel Xu <dxu@dxuuu.xyz>
      Link: https://lkml.kernel.org/bpf/57830c30-cd77-40cf-9cd1-3bb608aa602e@app.fastmail.comDebugged-by: default avatarTianyi Liu <i.pear@outlook.com>
      Suggested-by: default avatarJoan Bruguera Micó <joanbrugueram@gmail.com>
      Link: https://lore.kernel.org/r/20230418214925.ay3jpf2zhw75kgmd@trebleSigned-off-by: default avatarJosh Poimboeuf <jpoimboe@kernel.org>
      f7ba52f3
  6. 13 Jan, 2023 1 commit
  7. 30 Dec, 2022 1 commit
  8. 17 Nov, 2022 2 commits
    • Jim Cromie's avatar
      vmlinux.lds.h: add HEADERED_SECTION_* macros · 1d926e25
      Jim Cromie authored
      These macros elaborate on BOUNDED_SECTION_(PRE|POST)_LABEL macros,
      prepending an optional KEEP(.gnu.linkonce##_sec_) reservation, and a
      linker-symbol to address it.
      
      This allows a developer to define a header struct (which must fit with
      the section's base struct-type), and could contain:
      
      1- fields whose value is common to the entire set of data-records.
         This allows the header & data structs to specialize, complement
         each other, and shrink.
      
      2- an uplink pointer to an organizing struct
         which refs other related/sub data-tables
         header record is addressable via the extern'd header linker-symbol
      
      Once the linker-symbols created by the macro are ref'd extern in code,
      that code can compute a record's index (ptr - start) in the "primary"
      table, then use it to index into the related/sub tables.  Adding a
      primary.map_* field foreach sub-table would then allow deduplication
      and remapping of that sub-table.
      
      This is aimed at dyndbg's struct _ddebug __dyndbg[] section, whose 3
      columns: function, file, module are 50%, 90%, 100% redundant.  The
      module column is fully recoverable after dynamic_debug_init() saves it
      to each ddebug_table.module as the builtin __dyndbg[] table is parsed.
      
      Given that those 3 columns use 24/56 of a _ddebug record, a dyndbg=y
      kernel with ~5k callsites could reduce kernel memory substantially.
      Returning that memory to the kernel buddy-allocator? is then possible.
      Signed-off-by: default avatarJim Cromie <jim.cromie@gmail.com>
      Link: https://lore.kernel.org/r/20221117171633.923628-3-jim.cromie@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d926e25
    • Jim Cromie's avatar
      vmlinux.lds.h: fix BOUNDED_SECTION_(PRE|POST)_LABEL macros · 435d6b65
      Jim Cromie authored
      Commit 2f465b92 ("vmlinux.lds.h: place optional header space in BOUNDED_SECTION")
      
      added BOUNDED_SECTION_(PRE|POST)_LABEL macros, encapsulating the basic
      boilerplate to KEEP/pack records into a section, and to mark the begin
      and end of the section with linker-symbols.
      
      But it tried to do extra, adding KEEP(*(.gnu.linkonce.##_sec_)) to
      optionally reserve a header record in front of the data.  It wrongly
      placed the KEEP after the linker-symbol starting the section,
      so if a header was added, it would wind up in the data.
      
      Moving the KEEP to the "correct" place proved brittle, and too clever
      by half.  The obvious safe fix is to remove the KEEP and restore the
      plain old boilerplate.  The header can be added later, with separate
      macros.
      
      Also, the macro var-names: _s_, _e_ are nearly invisible, change them
      to more obvious names: _BEGIN_, _END_
      
      Fixes: 2f465b92 ("vmlinux.lds.h: place optional header space in BOUNDED_SECTION")
      Signed-off-by: default avatarJim Cromie <jim.cromie@gmail.com>
      Link: https://lore.kernel.org/r/20221117171633.923628-2-jim.cromie@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      435d6b65
  9. 10 Nov, 2022 2 commits
    • Jim Cromie's avatar
      vmlinux.lds.h: place optional header space in BOUNDED_SECTION · 2f465b92
      Jim Cromie authored
      Extend recently added BOUNDED_SECTION(_name) macro by adding a
      KEEP(*(.gnu.linkonce.##_name)) before the KEEP(*(_name)).
      
      This does nothing by itself, vmlinux is the same before and after this
      patch.  But if a developer adds a .gnu.linkonce.foo record, that
      record is placed in the front of the section, where it can be used as
      a header for the table.
      
      The intent is to create an up-link to another organizing struct, from
      where related tables can be referenced.  And since every item in a
      table has a known offset from its header, that same offset can be used
      to fetch records from the related tables.
      
      By itself, this doesnt gain much, unless maybe the pattern of access
      is to scan 1 or 2 fields in each fat record, but with 2 16 bit .map*
      fields added, we could de-duplicate 2 related tables.
      
      The use case here is struct _ddebug, which has 3 pointers (function,
      file, module) with substantial repetition; respectively 53%, 90%, and
      the module column is fully recoverable after dynamic_debug_init()
      splits the table into a linked list of "module" chunks.
      
      On a DYNAMIC_DEBUG=y kernel with 5k pr_debugs, the memory savings
      should be ~100 KiB.
      Signed-off-by: default avatarJim Cromie <jim.cromie@gmail.com>
      Link: https://lore.kernel.org/r/20221022225637.1406715-3-jim.cromie@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f465b92
    • Jim Cromie's avatar
      vmlinux.lds.h: add BOUNDED_SECTION* macros · 9b351be2
      Jim Cromie authored
      vmlinux.lds.h has ~45 occurrences of this general pattern:
      
        __start_foo = .;
        KEEP(*(foo))
        __stop_foo = .;
      
      Reduce this pattern to a (group of 4) macros, and use them to reduce
      linecount.  This was inspired by the codetag patchset.
      
      no functional change.
      
      CC: Suren Baghdasaryan <surenb@google.com>
      CC: Kent Overstreet <kent.overstreet@linux.dev>
      Signed-off-by: default avatarJim Cromie <jim.cromie@gmail.com>
      Link: https://lore.kernel.org/r/20221022225637.1406715-2-jim.cromie@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b351be2
  10. 09 Nov, 2022 1 commit
  11. 08 Nov, 2022 1 commit
  12. 20 Oct, 2022 1 commit
  13. 17 Oct, 2022 1 commit
  14. 26 Sep, 2022 1 commit
  15. 23 Sep, 2022 1 commit
  16. 16 Sep, 2022 1 commit
  17. 07 Sep, 2022 1 commit
    • Jim Cromie's avatar
      kernel/module: add __dyndbg_classes section · 66f4006b
      Jim Cromie authored
      Add __dyndbg_classes section, using __dyndbg as a model. Use it:
      
      vmlinux.lds.h:
      
      KEEP the new section, which also silences orphan section warning on
      loadable modules.  Add (__start_/__stop_)__dyndbg_classes linker
      symbols for the c externs (below).
      
      kernel/module/main.c:
      - fill new fields in find_module_sections(), using section_objs()
      - extend callchain prototypes
        to pass classes, length
        load_module(): pass new info to dynamic_debug_setup()
        dynamic_debug_setup(): new params, pass through to ddebug_add_module()
      
      dynamic_debug.c:
      - add externs to the linker symbols.
      
      ddebug_add_module():
      - It currently builds a debug_table, and *will* find and attach classes.
      
      dynamic_debug_init():
      - add class fields to the _ddebug_info cursor var: di.
      Signed-off-by: default avatarJim Cromie <jim.cromie@gmail.com>
      Link: https://lore.kernel.org/r/20220904214134.408619-16-jim.cromie@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      66f4006b
  18. 19 May, 2022 1 commit
  19. 15 Mar, 2022 1 commit
  20. 04 Feb, 2022 1 commit
  21. 27 Oct, 2021 1 commit
  22. 22 Oct, 2021 1 commit
  23. 20 Oct, 2021 1 commit
  24. 13 Sep, 2021 1 commit
  25. 11 Aug, 2021 1 commit
  26. 19 Jul, 2021 1 commit
    • Chris Down's avatar
      printk: Userspace format indexing support · 33701557
      Chris Down authored
      We have a number of systems industry-wide that have a subset of their
      functionality that works as follows:
      
      1. Receive a message from local kmsg, serial console, or netconsole;
      2. Apply a set of rules to classify the message;
      3. Do something based on this classification (like scheduling a
         remediation for the machine), rinse, and repeat.
      
      As a couple of examples of places we have this implemented just inside
      Facebook, although this isn't a Facebook-specific problem, we have this
      inside our netconsole processing (for alarm classification), and as part
      of our machine health checking. We use these messages to determine
      fairly important metrics around production health, and it's important
      that we get them right.
      
      While for some kinds of issues we have counters, tracepoints, or metrics
      with a stable interface which can reliably indicate the issue, in order
      to react to production issues quickly we need to work with the interface
      which most kernel developers naturally use when developing: printk.
      
      Most production issues come from unexpected phenomena, and as such
      usually the code in question doesn't have easily usable tracepoints or
      other counters available for the specific problem being mitigated. We
      have a number of lines of monitoring defence against problems in
      production (host metrics, process metrics, service metrics, etc), and
      where it's not feasible to reliably monitor at another level, this kind
      of pragmatic netconsole monitoring is essential.
      
      As one would expect, monitoring using printk is rather brittle for a
      number of reasons -- most notably that the message might disappear
      entirely in a new version of the kernel, or that the message may change
      in some way that the regex or other classification methods start to
      silently fail.
      
      One factor that makes this even harder is that, under normal operation,
      many of these messages are never expected to be hit. For example, there
      may be a rare hardware bug which one wants to detect if it was to ever
      happen again, but its recurrence is not likely or anticipated. This
      precludes using something like checking whether the printk in question
      was printed somewhere fleetwide recently to determine whether the
      message in question is still present or not, since we don't anticipate
      that it should be printed anywhere, but still need to monitor for its
      future presence in the long-term.
      
      This class of issue has happened on a number of occasions, causing
      unhealthy machines with hardware issues to remain in production for
      longer than ideal. As a recent example, some monitoring around
      blk_update_request fell out of date and caused semi-broken machines to
      remain in production for longer than would be desirable.
      
      Searching through the codebase to find the message is also extremely
      fragile, because many of the messages are further constructed beyond
      their callsite (eg. btrfs_printk and other module-specific wrappers,
      each with their own functionality). Even if they aren't, guessing the
      format and formulation of the underlying message based on the aesthetics
      of the message emitted is not a recipe for success at scale, and our
      previous issues with fleetwide machine health checking demonstrate as
      much.
      
      This provides a solution to the issue of silently changed or deleted
      printks: we record pointers to all printk format strings known at
      compile time into a new .printk_index section, both in vmlinux and
      modules. At runtime, this can then be iterated by looking at
      <debugfs>/printk/index/<module>, which emits the following format, both
      readable by humans and able to be parsed by machines:
      
          $ head -1 vmlinux; shuf -n 5 vmlinux
          # <level[,flags]> filename:line function "format"
          <5> block/blk-settings.c:661 disk_stack_limits "%s: Warning: Device %s is misaligned\n"
          <4> kernel/trace/trace.c:8296 trace_create_file "Could not create tracefs '%s' entry\n"
          <6> arch/x86/kernel/hpet.c:144 _hpet_print_config "hpet: %s(%d):\n"
          <6> init/do_mounts.c:605 prepare_namespace "Waiting for root device %s...\n"
          <6> drivers/acpi/osl.c:1410 acpi_no_auto_serialize_setup "ACPI: auto-serialization disabled\n"
      
      This mitigates the majority of cases where we have a highly-specific
      printk which we want to match on, as we can now enumerate and check
      whether the format changed or the printk callsite disappeared entirely
      in userspace. This allows us to catch changes to printks we monitor
      earlier and decide what to do about it before it becomes problematic.
      
      There is no additional runtime cost for printk callers or printk itself,
      and the assembly generated is exactly the same.
      Signed-off-by: default avatarChris Down <chris@chrisdown.name>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: John Ogness <john.ogness@linutronix.de>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Kees Cook <keescook@chromium.org>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Tested-by: default avatarPetr Mladek <pmladek@suse.com>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Acked-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Acked-by: Jessica Yu <jeyu@kernel.org> # for module.{c,h}
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Link: https://lore.kernel.org/r/e42070983637ac5e384f17fbdbe86d19c7b212a5.1623775748.git.chris@chrisdown.name
      33701557
  27. 02 Jun, 2021 1 commit
    • Nathan Chancellor's avatar
      vmlinux.lds.h: Avoid orphan section with !SMP · d4c63999
      Nathan Chancellor authored
      With x86_64_defconfig and the following configs, there is an orphan
      section warning:
      
      CONFIG_SMP=n
      CONFIG_AMD_MEM_ENCRYPT=y
      CONFIG_HYPERVISOR_GUEST=y
      CONFIG_KVM=y
      CONFIG_PARAVIRT=y
      
      ld: warning: orphan section `.data..decrypted' from `arch/x86/kernel/cpu/vmware.o' being placed in section `.data..decrypted'
      ld: warning: orphan section `.data..decrypted' from `arch/x86/kernel/kvm.o' being placed in section `.data..decrypted'
      
      These sections are created with DEFINE_PER_CPU_DECRYPTED, which
      ultimately turns into __PCPU_ATTRS, which in turn has a section
      attribute with a value of PER_CPU_BASE_SECTION + the section name. When
      CONFIG_SMP is not set, the base section is .data and that is not
      currently handled in any linker script.
      
      Add .data..decrypted to PERCPU_DECRYPTED_SECTION, which is included in
      PERCPU_INPUT -> PERCPU_SECTION, which is include in the x86 linker
      script when either CONFIG_X86_64 or CONFIG_SMP is unset, taking care of
      the warning.
      
      Fixes: ac26963a ("percpu: Introduce DEFINE_PER_CPU_DECRYPTED")
      Link: https://github.com/ClangBuiltLinux/linux/issues/1360Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Tested-by: Nick Desaulniers <ndesaulniers@google.com> # build
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20210506001410.1026691-1-nathan@kernel.org
      d4c63999
  28. 08 Apr, 2021 1 commit
    • Sami Tolvanen's avatar
      add support for Clang CFI · cf68fffb
      Sami Tolvanen authored
      This change adds support for Clang’s forward-edge Control Flow
      Integrity (CFI) checking. With CONFIG_CFI_CLANG, the compiler
      injects a runtime check before each indirect function call to ensure
      the target is a valid function with the correct static type. This
      restricts possible call targets and makes it more difficult for
      an attacker to exploit bugs that allow the modification of stored
      function pointers. For more details, see:
      
        https://clang.llvm.org/docs/ControlFlowIntegrity.html
      
      Clang requires CONFIG_LTO_CLANG to be enabled with CFI to gain
      visibility to possible call targets. Kernel modules are supported
      with Clang’s cross-DSO CFI mode, which allows checking between
      independently compiled components.
      
      With CFI enabled, the compiler injects a __cfi_check() function into
      the kernel and each module for validating local call targets. For
      cross-module calls that cannot be validated locally, the compiler
      calls the global __cfi_slowpath_diag() function, which determines
      the target module and calls the correct __cfi_check() function. This
      patch includes a slowpath implementation that uses __module_address()
      to resolve call targets, and with CONFIG_CFI_CLANG_SHADOW enabled, a
      shadow map that speeds up module look-ups by ~3x.
      
      Clang implements indirect call checking using jump tables and
      offers two methods of generating them. With canonical jump tables,
      the compiler renames each address-taken function to <function>.cfi
      and points the original symbol to a jump table entry, which passes
      __cfi_check() validation. This isn’t compatible with stand-alone
      assembly code, which the compiler doesn’t instrument, and would
      result in indirect calls to assembly code to fail. Therefore, we
      default to using non-canonical jump tables instead, where the compiler
      generates a local jump table entry <function>.cfi_jt for each
      address-taken function, and replaces all references to the function
      with the address of the jump table entry.
      
      Note that because non-canonical jump table addresses are local
      to each component, they break cross-module function address
      equality. Specifically, the address of a global function will be
      different in each module, as it's replaced with the address of a local
      jump table entry. If this address is passed to a different module,
      it won’t match the address of the same function taken there. This
      may break code that relies on comparing addresses passed from other
      components.
      
      CFI checking can be disabled in a function with the __nocfi attribute.
      Additionally, CFI can be disabled for an entire compilation unit by
      filtering out CC_FLAGS_CFI.
      
      By default, CFI failures result in a kernel panic to stop a potential
      exploit. CONFIG_CFI_PERMISSIVE enables a permissive mode, where the
      kernel prints out a rate-limited warning instead, and allows execution
      to continue. This option is helpful for locating type mismatches, but
      should only be enabled during development.
      Signed-off-by: default avatarSami Tolvanen <samitolvanen@google.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarNathan Chancellor <nathan@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20210408182843.1754385-2-samitolvanen@google.com
      cf68fffb
  29. 25 Feb, 2021 1 commit
  30. 23 Feb, 2021 1 commit
    • Alexander Lobakin's avatar
      vmlinux.lds.h: catch even more instrumentation symbols into .data · 49387f62
      Alexander Lobakin authored
      LKP caught another bunch of orphaned instrumentation symbols [0]:
      
      mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from
      `init/main.o' being placed in section `.data.$LPBX1'
      mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from
      `init/main.o' being placed in section `.data.$LPBX0'
      mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from
      `init/do_mounts.o' being placed in section `.data.$LPBX1'
      mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from
      `init/do_mounts.o' being placed in section `.data.$LPBX0'
      mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from
      `init/do_mounts_initrd.o' being placed in section `.data.$LPBX1'
      mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from
      `init/do_mounts_initrd.o' being placed in section `.data.$LPBX0'
      mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from
      `init/initramfs.o' being placed in section `.data.$LPBX1'
      mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from
      `init/initramfs.o' being placed in section `.data.$LPBX0'
      mipsel-linux-ld: warning: orphan section `.data.$LPBX1' from
      `init/calibrate.o' being placed in section `.data.$LPBX1'
      mipsel-linux-ld: warning: orphan section `.data.$LPBX0' from
      `init/calibrate.o' being placed in section `.data.$LPBX0'
      
      [...]
      
      Soften the wildcard to .data.$L* to grab these ones into .data too.
      
      [0] https://lore.kernel.org/lkml/202102231519.lWPLPveV-lkp@intel.comReported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarAlexander Lobakin <alobakin@pm.me>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      49387f62
  31. 17 Feb, 2021 1 commit
  32. 16 Feb, 2021 2 commits
  33. 10 Feb, 2021 1 commit
  34. 08 Feb, 2021 2 commits
  35. 15 Jan, 2021 2 commits