maillist inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5J75G
CVE: NA

Reference: https://lore.kernel.org/rust-for-linux/CANiq72nDcJLSB3pLhkdqGdLitfmqqCUVVfkY5EjP9AcwVv9B4A@mail.gmail.com/T/#t

--------------------------------

Rust symbols can become quite long due to namespacing introduced
by modules, types, traits, generics, etc. For instance,
the following code:

    pub mod my_module {
        pub struct MyType;
        pub struct MyGenericType<T>(T);

        pub trait MyTrait {
            fn my_method() -> u32;
        }

        impl MyTrait for MyGenericType<MyType> {
            fn my_method() -> u32 {
                42
            }
        }
    }

generates a symbol of length 96 when using the upcoming v0 mangling scheme:

    _RNvXNtCshGpAVYOtgW1_7example9my_moduleINtB2_13MyGenericTypeNtB2_6MyTypeENtB2_7MyTrait9my_method

At the moment, Rust symbols may reach up to 300 in length.
Setting 512 as the maximum seems like a reasonable choice to
keep some headroom.
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NPetr Mladek <pmladek@suse.com>
Co-developed-by: NAlex Gaynor <alex.gaynor@gmail.com>
Signed-off-by: NAlex Gaynor <alex.gaynor@gmail.com>
Co-developed-by: NWedson Almeida Filho <wedsonaf@google.com>
Signed-off-by: NWedson Almeida Filho <wedsonaf@google.com>
Co-developed-by: NGary Guo <gary@garyguo.net>
Signed-off-by: NGary Guo <gary@garyguo.net>
Co-developed-by: NBoqun Feng <boqun.feng@gmail.com>
Signed-off-by: NBoqun Feng <boqun.feng@gmail.com>
Signed-off-by: NMiguel Ojeda <ojeda@kernel.org>
Signed-off-by: NWeilong Chen <chenweilong@huawei.com>

maillist inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5J75G
CVE: NA

Reference: https://lore.kernel.org/rust-for-linux/CANiq72nDcJLSB3pLhkdqGdLitfmqqCUVVfkY5EjP9AcwVv9B4A@mail.gmail.com/T/#t

--------------------------------

Rust symbols can become quite long due to namespacing introduced
by modules, types, traits, generics, etc.

Increasing to 255 is not enough in some cases, and therefore
we need to introduce longer lengths to the symbol table.

In order to avoid increasing all lengths to 2 bytes (since most
of them are small, including many Rust ones), we use ULEB128 to
keep smaller symbols in 1 byte, with the rest in 2 bytes.
Reviewed-by: NKees Cook <keescook@chromium.org>
Co-developed-by: NAlex Gaynor <alex.gaynor@gmail.com>
Signed-off-by: NAlex Gaynor <alex.gaynor@gmail.com>
Co-developed-by: NWedson Almeida Filho <wedsonaf@google.com>
Signed-off-by: NWedson Almeida Filho <wedsonaf@google.com>
Co-developed-by: NGary Guo <gary@garyguo.net>
Signed-off-by: NGary Guo <gary@garyguo.net>
Co-developed-by: NBoqun Feng <boqun.feng@gmail.com>
Signed-off-by: NBoqun Feng <boqun.feng@gmail.com>
Co-developed-by: NMatthew Wilcox <willy@infradead.org>
Signed-off-by: NMatthew Wilcox <willy@infradead.org>
Signed-off-by: NMiguel Ojeda <ojeda@kernel.org>
Signed-off-by: NWeilong Chen <chenweilong@huawei.com>

maillist inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5J75G
CVE: NA

Reference: https://lore.kernel.org/rust-for-linux/CANiq72nDcJLSB3pLhkdqGdLitfmqqCUVVfkY5EjP9AcwVv9B4A@mail.gmail.com/T/#t

--------------------------------

This makes it easier to update the size later on.

Furthermore, a static assert is added to ensure both are updated
when that happens. The relationship used is one that keeps the new
size (512+1) close to the original buffer size (500).
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NBoqun Feng <boqun.feng@gmail.com>
Co-developed-by: NMiguel Ojeda <ojeda@kernel.org>
Signed-off-by: NMiguel Ojeda <ojeda@kernel.org>
Signed-off-by: NWeilong Chen <chenweilong@huawei.com>

stable inclusion
from stable-5.10.17
commit 3dc2ba46500124ac350f9cd1a378e799f8f7fc88
bugzilla: 48169

--------------------------------

[ Upstream commit efe6e306 ]

ARM randconfig builds with lld sometimes show a build failure
from kallsyms:

  Inconsistent kallsyms data
  Try make KALLSYMS_EXTRA_PASS=1 as a workaround

The problem is the veneers/thunks getting added by the linker extend
the symbol table, which in turn leads to more veneers being needed,
so it may take a few extra iterations to converge.

This bug has been fixed multiple times before, but comes back every time
a new symbol name is used. lld uses a different set of identifiers from
ld.bfd, so the additional ones need to be added as well.

I looked through the sources and found that arm64 and mips define similar
prefixes, so I'm adding those as well, aside from the ones I observed. I'm
not sure about powerpc64, which seems to already be handled through a
section match, but if it comes back, the "__long_branch_" and "__plt_"
prefixes would have to get added as well.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>

PowerPC allmodconfig often fails to build as follows:

    LD      .tmp_vmlinux.kallsyms1
    KSYM    .tmp_vmlinux.kallsyms1.o
    LD      .tmp_vmlinux.kallsyms2
    KSYM    .tmp_vmlinux.kallsyms2.o
    LD      .tmp_vmlinux.kallsyms3
    KSYM    .tmp_vmlinux.kallsyms3.o
    LD      vmlinux
    SORTTAB vmlinux
    SYSMAP  System.map
  Inconsistent kallsyms data
  Try make KALLSYMS_EXTRA_PASS=1 as a workaround
  make[2]: *** [../Makefile:1162: vmlinux] Error 1

Setting KALLSYMS_EXTRA_PASS=1 does not help.

This is caused by the compiler inserting stubs such as *.long_branch.*
and *.plt_branch.*

  $ powerpc-linux-nm -n .tmp_vmlinux.kallsyms2
   [ snip ]
  c00000000210c010 t 00000075.plt_branch.da9:19
  c00000000210c020 t 00000075.plt_branch.1677:5
  c00000000210c030 t 00000075.long_branch.memmove
  c00000000210c034 t 00000075.plt_branch.9e0:5
  c00000000210c044 t 00000075.plt_branch.free_initrd_mem
    ...

Actually, the problem mentioned in scripts/link-vmlinux.sh comments;
"In theory it's possible this results in even more stubs, but unlikely"
is happening here, and ends up with another kallsyms step required.

scripts/kallsyms.c already ignores various compiler stubs. Let's do
similar to make kallsysms for PowerPC always succeed in 2 steps.
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Tested-by: NGuenter Roeck <linux@roeck-us.net>

Add new folders arch/arm64/kvm/hyp/{vhe,nvhe} and Makefiles for building code
that runs in EL2 under VHE/nVHE KVM, repsectivelly. Add an include folder for
hyp-specific header files which will include code common to VHE/nVHE.

Build nVHE code with -D__KVM_NVHE_HYPERVISOR__, VHE code with
-D__KVM_VHE_HYPERVISOR__.

Under nVHE compile each source file into a `.hyp.tmp.o` object first, then
prefix all its symbols with "__kvm_nvhe_" using `objcopy` and produce
a `.hyp.o`. Suffixes were chosen so that it would be possible for VHE and nVHE
to share some source files, but compiled with different CFLAGS.

The nVHE ELF symbol prefix is added to kallsyms.c as ignored. EL2-only symbols
will never appear in EL1 stack traces.

Due to symbol prefixing, add a section in image-vars.h for aliases of symbols
that are defined in nVHE EL2 and accessed by kernel in EL1 or vice versa.
Signed-off-by: NDavid Brazdil <dbrazdil@google.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200625131420.71444-4-dbrazdil@google.com

Due to a bug-report that was compiler-dependent, I updated one of my
machines to gcc-10.  That shows a lot of new warnings.  Happily they
seem to be mostly the valid kind, but it's going to cause a round of
churn for getting rid of them..

This is the really low-hanging fruit of removing a couple of zero-sized
arrays in some core code.  We have had a round of these patches before,
and we'll have many more coming, and there is nothing special about
these except that they were particularly trivial, and triggered more
warnings than most.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There is the code in the read_symbol function in 'scripts/kallsyms.c':

	if (is_ignored_symbol(name, type))
		return NULL;

	/* Ignore most absolute/undefined (?) symbols. */
	if (strcmp(name, "_text") == 0)
		_text = addr;

But the is_ignored_symbol function returns true for name="_text" and
type='A'. So the next condition is not executed and the _text variable
is always zero.

It makes the wrong kallsyms_relative_base symbol as a result of the code
(CONFIG_KALLSYMS_BASE_RELATIVE is defined):

	if (base_relative) {
		output_label("kallsyms_relative_base");
		output_address(relative_base);
		printf("\n");
	}

Because the output_address function uses the _text variable.

So the kallsyms_lookup function and all related functions in the kernel
do not work properly. For example, the stack trace in oops:

 Call Trace:
 [aa095e58] [809feab8] kobj_ns_ops_tbl+0x7ff09ac8/0x7ff1c1c4 (unreliable)
 [aa095e98] [80002b64] kobj_ns_ops_tbl+0x7f50db74/0x80000010
 [aa095ef8] [809c3d24] kobj_ns_ops_tbl+0x7feced34/0x7ff1c1c4
 [aa095f28] [80002ed0] kobj_ns_ops_tbl+0x7f50dee0/0x80000010
 [aa095f38] [8000f238] kobj_ns_ops_tbl+0x7f51a248/0x80000010

The right stack trace:

 Call Trace:
 [aa095e58] [809feab8] module_vdu_video_init+0x2fc/0x3bc (unreliable)
 [aa095e98] [80002b64] do_one_initcall+0x40/0x1f0
 [aa095ef8] [809c3d24] kernel_init_freeable+0x164/0x1d8
 [aa095f28] [80002ed0] kernel_init+0x14/0x124
 [aa095f38] [8000f238] ret_from_kernel_thread+0x14/0x1c

[masahiroy@kernel.org:

This issue happens on binutils <= 2.22
The following commit fixed it:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d2667025dd30611514810c28bee9709e4623012a

The symbol type of _text is 'T' on binutils >= 2.23
The minimal supported binutils version for the kernel build is 2.21
]
Signed-off-by: NMikhail Petrov <Mikhail.Petrov@mir.dev>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

memcpy() writes one more byte than allocated.

Fixes: 8d605269 ("scripts/kallsyms: change table to store (strcut sym_entry *)")
Reported-by: Nyouling257 <youling257@gmail.com>
Reported-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Tested-by: NPavel Machek <pavel@ucw.cz>

The symbol table is extended every 10000 addition by using realloc(),
where data copy might occur to the new buffer.

To decrease the amount of possible data copy, let's change the table
to store the pointer.

The symbol type + symbol name part is appended at the end of
(struct sym_entry), and allocated together with the struct body.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

I will use 'sym' for the point to struce sym_entry in the next commit.
Rename 'sym', 'stype' to 'name', 'type', which are more intuitive.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Since commit 5e5c4fa7 ("scripts/kallsyms: shrink table before
sorting it"), kallsyms_relative_base can be larger than _text, which
causes overflow when building the 32-bit kernel.

https://lkml.org/lkml/2019/12/7/156

This is because _text is, unless --all-symbols is specified, now
trimmed from the symbol table before record_relative_base() is called.

Handle the offset signedness also for kallsyms_relative_base. Introduce
a new helper, output_address(), to reduce the code duplication.

Fixes: 5e5c4fa7 ("scripts/kallsyms: shrink table before sorting it")
Reported-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

These are set to zero without the explicit initializers.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Put the relevant code close together.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

There is no more reason to check the return value of
check_symbol_range().
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Collect the ignored patterns to is_ignored_symbol().
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Refactoring for shortening the code.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Unless the address range matters, symbols can be ignored earlier,
which avoids unneeded memory allocation.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Add 'const' where a function does not write to the pointer dereferenes.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The callers of this function expect (unsigned char *). I do not see
a good reason to make this function return (void *).
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

You can do equivalent things with strspn(). I do not see noticeable
performance difference.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

sym_entry::sym is (unsigned char *) instead of (char *) because
kallsyms exploits the MSB for compression, and the characters are
used as the index of token_profit array.

However, it requires casting (unsigned char *) to (char *) in some
places since standard library functions such as strcmp(), strlen()
expect (char *).

Introduce a new helper, sym_name(), which advances the given pointer
by 1 and casts it to (char *).
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

l <= strlen(sym_name) is unnecessary for prefix matching.
strncmp() will do.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Since commit 6f00df24 ("[PATCH] Strip local symbols from kallsyms"),
all symbols starting '$' are ignored.

is_arm_mapping_symbol() particularly ignores $a, $t, etc. but it is
redundant.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Currently, record_relative_base() iterates over the entire table to
find the minimum address, but it is not efficient because we sort
the table anyway.

After sort_symbol(), the table is sorted by address. (kallsyms parses
the 'nm -n' output, so the data is already sorted by address, but this
commit does not rely on it.)

Move record_relative_base() after sort_symbols(), and take the first
non-absolute symbol value.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Currently, build_initial_tok_table() trims unused symbols, but it is
called after sort_symbols().

It is not efficient to sort the huge table that contains unused entries.
Shrink the table before sorting it.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

build_initial_tok_table() overwrites unused sym_entry to shrink the
table size. Before the entry is overwritten, table[i].sym must be freed
since it is malloc'ed data.

This fixes the 'definitely lost' report from valgrind. I ran valgrind
against x86_64_defconfig of v5.4-rc8 kernel, and here is the summary:

[Before the fix]

  LEAK SUMMARY:
     definitely lost: 53,184 bytes in 2,874 blocks

[After the fix]

  LEAK SUMMARY:
     definitely lost: 0 bytes in 0 blocks
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

This is not defined in the standard headers. #ifndef is unneeded.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

gcc asan instrumentation emits the following sequence to store frame pc
when the kernel is built with CONFIG_RELOCATABLE:
debug/vsprintf.s:
        .section        .data.rel.ro.local,"aw"
        .align  8
.LC3:
        .quad   .LASANPC4826@GOTOFF
.text
        .align  8
        .type   number, @function
number:
.LASANPC4826:

and in case reloc is issued for LASANPC label it also gets into .symtab
with the same address as actual function symbol:
$ nm -n vmlinux | grep 0000000001397150
0000000001397150 t .LASANPC4826
0000000001397150 t number

In the end kernel backtraces are almost unreadable:
[  143.748476] Call Trace:
[  143.748484] ([<000000002da3e62c>] .LASANPC2671+0x114/0x190)
[  143.748492]  [<000000002eca1a58>] .LASANPC2612+0x110/0x160
[  143.748502]  [<000000002de9d830>] print_address_description+0x80/0x3b0
[  143.748511]  [<000000002de9dd64>] __kasan_report+0x15c/0x1c8
[  143.748521]  [<000000002ecb56d4>] strrchr+0x34/0x60
[  143.748534]  [<000003ff800a9a40>] kasan_strings+0xb0/0x148 [test_kasan]
[  143.748547]  [<000003ff800a9bba>] kmalloc_tests_init+0xe2/0x528 [test_kasan]
[  143.748555]  [<000000002da2117c>] .LASANPC4069+0x354/0x748
[  143.748563]  [<000000002dbfbb16>] do_init_module+0x136/0x3b0
[  143.748571]  [<000000002dbff3f4>] .LASANPC3191+0x2164/0x25d0
[  143.748580]  [<000000002dbffc4c>] .LASANPC3196+0x184/0x1b8
[  143.748587]  [<000000002ecdf2ec>] system_call+0xd8/0x2d8

Since LASANPC labels are not even unique and get into .symtab only due
to relocs filter them out in kallsyms.
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

<asm/bitsperlong.h> is enough to include the definition of
BITS_PER_LONG.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Global variables in the .bss section are zeroed out before the program
starts to run.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Fix the following sparse warnings:

scripts/kallsyms.c:65:5: warning: symbol 'token_profit' was not declared. Should it be static?
scripts/kallsyms.c:68:15: warning: symbol 'best_table' was not declared. Should it be static?
scripts/kallsyms.c:69:15: warning: symbol 'best_table_len' was not declared. Should it be static?

Also, remove 'inline' from is_arm_mapping_symbol(). The compiler
will inline it anyway when it is appropriate to do so.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

When checking for symbols with excessively long names,
account for null terminating character.

Fixes: f3462aa9 ("Kbuild: Handle longer symbols in kallsyms.c")
Signed-off-by: NEugene Loh <eugene.loh@oracle.com>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

As mentioned in the info pages of gas, the '.align' pseudo op's
interpretation of the alignment value is architecture specific.
It might either be a byte value or taken to the power of two.

On ARM it's actually the latter which leads to unnecessary large
alignments of 16 bytes for 32 bit builds or 256 bytes for 64 bit
builds.

Fix this by switching to '.balign' instead which is consistent
across all architectures.
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

These symbols were added by commit 028f0426 ("kallsyms: support
kernel symbols in Blackfin on-chip memory") for Blackfin.

The Blackfin support was removed by commit 4ba66a97 ("arch: remove
blackfin port").
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Both kallsyms_num_syms and kallsyms_markers[] don't really need to use
unsigned long as their (base) types; unsigned int fully suffices.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

scripts/kallsyms.c: function write_src:
"printf", the #1 format specifier "d" need arg type "int",
but the according arg "table_cnt" has type "unsigned int"

scripts/recordmcount.c: function do_file:
"fprintf", the #1 format specifier "d" need arg type "int",
but the according arg "(*w2)(ehdr->e_machine)" has type "unsigned int"

scripts/recordmcount.h: function find_secsym_ndx:
"fprintf", the #1 format specifier "d" need arg type "int",
but the according arg "txtndx" has type "unsigned int"
Signed-off-by: Nnixiaoming <nixiaoming@huawei.com>
Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX was selected by BLACKFIN, METAG.
They were removed by commit 4ba66a97 ("arch: remove blackfin port"),
commit bb6fb6df ("metag: Remove arch/metag/"), respectively.

No more architecture enables CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX,
hence the --symbol-prefix option is unnecessary.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>

On arm64, the EFI stub and the kernel proper are essentially the same
binary, although the EFI stub executes at a different virtual address
as the kernel. For this reason, the EFI stub is restricted in the
symbols it can link to, which is ensured by prefixing all EFI stub
symbols with __efistub_ (and emitting __efistub_ prefixed aliases for
routines that may be shared between the core kernel and the stub)

These symbols are leaking into kallsyms, polluting the namespace, so
let's filter them explicitly.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>