Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 02 10月, 2020 1 次提交
    • J
      objtool: Permit __kasan_check_{read,write} under UACCESS · b0b8e56b
      由 Jann Horn 提交于 
      Building linux-next with JUMP_LABEL=n and KASAN=y, I got this objtool
warning:

arch/x86/lib/copy_mc.o: warning: objtool: copy_mc_to_user()+0x22: call to
__kasan_check_read() with UACCESS enabled

What happens here is that copy_mc_to_user() branches on a static key in a
UACCESS region:

        __uaccess_begin();
        if (static_branch_unlikely(&copy_mc_fragile_key))
                ret = copy_mc_fragile(to, from, len);
        ret = copy_mc_generic(to, from, len);
        __uaccess_end();

and the !CONFIG_JUMP_LABEL version of static_branch_unlikely() uses
static_key_enabled(), which uses static_key_count(), which uses
atomic_read(), which calls instrument_atomic_read(), which uses
kasan_check_read(), which is __kasan_check_read().

Let's permit these KASAN helpers in UACCESS regions - static keys should
probably work under UACCESS, I think.

PeterZ adds:

  It's not a matter of permitting, it's a matter of being safe and
  correct. In this case it is, because it's a thin wrapper around
  check_memory_region() which was already marked safe.

  check_memory_region() is correct because the only thing it ends up
  calling is kasa_report() and that is also marked safe because that is
  annotated with user_access_save/restore() before it does anything else.

  On top of that, all of KASAN is noinstr, so nothing in here will end up
  in tracing and/or call schedule() before the user_access_save().
Signed-off-by: NJann Horn <jannh@google.com>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      b0b8e56b
  3. 21 9月, 2020 2 次提交
  5. 19 9月, 2020 2 次提交
  7. 10 9月, 2020 4 次提交
  9. 02 9月, 2020 2 次提交
  11. 01 9月, 2020 2 次提交
  13. 25 6月, 2020 1 次提交
  15. 18 6月, 2020 2 次提交
  17. 15 6月, 2020 1 次提交
  19. 01 6月, 2020 1 次提交
    • M
      objtool: Rename rela to reloc · f1974222
      由 Matt Helsley 提交于 
      Before supporting additional relocation types rename the relevant
types and functions from "rela" to "reloc". This work be done with
the following regex:

  sed -e 's/struct rela/struct reloc/g' \
      -e 's/\([_\*]\)rela\(s\{0,1\}\)/\1reloc\2/g' \
      -e 's/tmprela\(s\{0,1\}\)/tmpreloc\1/g' \
      -e 's/relasec/relocsec/g' \
      -e 's/rela_list/reloc_list/g' \
      -e 's/rela_hash/reloc_hash/g' \
      -e 's/add_rela/add_reloc/g' \
      -e 's/rela->/reloc->/g' \
      -e '/rela[,\.]/{ s/\([^\.>]\)rela\([\.,]\)/\1reloc\2/g ; }' \
      -e 's/rela =/reloc =/g' \
      -e 's/relas =/relocs =/g' \
      -e 's/relas\[/relocs[/g' \
      -e 's/relaname =/relocname =/g' \
      -e 's/= rela\;/= reloc\;/g' \
      -e 's/= relas\;/= relocs\;/g' \
      -e 's/= relaname\;/= relocname\;/g' \
      -e 's/, rela)/, reloc)/g' \
      -e 's/\([ @]\)rela\([ "]\)/\1reloc\2/g' \
      -e 's/ rela$/ reloc/g' \
      -e 's/, relaname/, relocname/g' \
      -e 's/sec->rela/sec->reloc/g' \
      -e 's/(\(!\{0,1\}\)rela/(\1reloc/g' \
      -i \
      arch.h \
      arch/x86/decode.c  \
      check.c \
      check.h \
      elf.c \
      elf.h \
      orc_gen.c \
      special.c

Notable exceptions which complicate the regex include gelf_*
library calls and standard/expected section names which still use
"rela" because they encode the type of relocation expected. Also, keep
"rela" in the struct because it encodes a specific type of relocation
we currently expect.

It will eventually turn into a member of an anonymous union when a
susequent patch adds implicit addend, or "rel", relocation support.
Signed-off-by: NMatt Helsley <mhelsley@vmware.com>
Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      f1974222
  21. 20 5月, 2020 2 次提交
    • M
      objtool: Enable compilation of objtool for all architectures · 0decf1f8
      由 Matt Helsley 提交于 
      Objtool currently only compiles for x86 architectures. This is
fine as it presently does not support tooling for other
architectures. However, we would like to be able to convert other
kernel tools to run as objtool sub commands because they too
process ELF object files. This will allow us to convert tools
such as recordmcount to use objtool's ELF code.

Since much of recordmcount's ELF code is copy-paste code to/from
a variety of other kernel tools (look at modpost for example) this
means that if we can convert recordmcount we can convert more.

We define weak definitions for subcommand entry functions and other weak
definitions for shared functions critical to building existing
subcommands. These return 127 when the command is missing which signify
tools that do not exist on all architectures.  In this case the "check"
and "orc" tools do not exist on all architectures so we only add them
for x86. Future changes adding support for "check", to arm64 for
example, can then modify the SUBCMD_CHECK variable when building for
arm64.

Objtool is not currently wired in to KConfig to be built for other
architectures because it's not needed for those architectures and
there are no commands it supports other than those for x86. As more
command support is enabled on various architectures the necessary
KConfig changes can be made (e.g. adding "STACK_VALIDATION") to
trigger building objtool.

[ jpoimboe: remove aliases, add __weak macro, add error messages ]

Cc: Julien Thierry <jthierry@redhat.com>
Signed-off-by: NMatt Helsley <mhelsley@vmware.com>
Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      0decf1f8
    • J
      objtool: Add check_kcov_mode() to the uaccess safelist · ae033f08
      由 Josh Poimboeuf 提交于 
      check_kcov_mode() is called by write_comp_data() and
__sanitizer_cov_trace_pc(), which are already on the uaccess safe list.
It's notrace and doesn't call out to anything else, so add it to the
list too.

This fixes the following warnings:

  kernel/kcov.o: warning: objtool: __sanitizer_cov_trace_pc()+0x15: call to check_kcov_mode() with UACCESS enabled
  kernel/kcov.o: warning: objtool: write_comp_data()+0x1b: call to check_kcov_mode() with UACCESS enabled
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      ae033f08
  23. 15 5月, 2020 2 次提交
  25. 07 5月, 2020 2 次提交
  27. 01 5月, 2020 9 次提交
  29. 25 4月, 2020 1 次提交
  31. 23 4月, 2020 1 次提交
  33. 22 4月, 2020 5 次提交