linux.git/arch/riscv/kernel/vmlinux.lds.S, branch v5.9

riscv: Fixup bootup failure with HARDENED_USERCOPY

2020-10-07T01:34:00+00:00

6184358da000 ("riscv: Fixup static_obj() fail") attempted to elide a lockdep
failure by rearranging our kernel image to place all initdata within [_stext,
_end], thus triggering lockdep to treat these as static objects.  These objects
are released and eventually reallocated, causing check_kernel_text_object() to
trigger a BUG().

This backs out the change to make [_stext, _end] all-encompassing, instead just
moving initdata.  This results in initdata being outside of [__init_begin,
__init_end], which means initdata can't be freed.

Link: https://lore.kernel.org/linux-riscv/1593266228-61125-1-git-send-email-guoren@kernel.org/T/#t
Signed-off-by: Guo Ren 
Reported-by: Aurelien Jarno 
Tested-by: Aurelien Jarno 
[Palmer: Clean up commit text]
Signed-off-by: Palmer Dabbelt

riscv: Fixup static_obj() fail

2020-07-30T18:37:21+00:00

When enable LOCKDEP, static_obj() will cause error. Because some
__initdata static variables is before _stext:

static int static_obj(const void *obj)
{
        unsigned long start = (unsigned long) &_stext,
                      end   = (unsigned long) &_end,
                      addr  = (unsigned long) obj;

        /*
         * static variable?
         */
        if ((addr >= start) && (addr < end))
                return 1;

[    0.067192] INFO: trying to register non-static key.
[    0.067325] the code is fine but needs lockdep annotation.
[    0.067449] turning off the locking correctness validator.
[    0.067718] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc7-dirty #44
[    0.067945] Call Trace:
[    0.068369] [] walk_stackframe+0x0/0xa4
[    0.068506] [] show_stack+0x2a/0x34
[    0.068631] [] dump_stack+0x94/0xca
[    0.068757] [] register_lock_class+0x5b8/0x5bc
[    0.068969] [] __lock_acquire+0x6c/0x1d5c
[    0.069101] [] lock_acquire+0xae/0x312
[    0.069228] [] _raw_spin_lock_irqsave+0x40/0x5a
[    0.069357] [] complete+0x1e/0x50
[    0.069479] [] rest_init+0x1b0/0x28a
[    0.069660] [] 0xffffffe0000016a2
[    0.069779] [] 0xffffffe000001b84
[    0.069953] [] 0xffffffe000001092

static __initdata DECLARE_COMPLETION(kthreadd_done);

noinline void __ref rest_init(void)
{
	...
	complete(&kthreadd_done);

Signed-off-by: Guo Ren 
Signed-off-by: Palmer Dabbelt

riscv: Allow device trees to be built into the kernel

2020-05-18T18:38:05+00:00

Some systems don't provide a useful device tree to the kernel on boot.
Chasing around bootloaders for these systems is a headache, so instead
le't's just keep a device tree table in the kernel, keyed by the SOC's
unique identifier, that contains the relevant DTB.

This is only implemented for M mode right now. While we could implement
this via the SBI calls that allow access to these identifiers, we don't
have any systems that need this right now.

Signed-off-by: Palmer Dabbelt

riscv: Add SOC early init support

2020-04-03T17:46:43+00:00

Add a mechanism for early SoC initialization for platforms that need
additional hardware initialization not possible through the regular
device tree and drivers mechanism. With this, a SoC specific
initialization function can be called very early, before DTB parsing
is done by parse_dtb() in Linux RISC-V kernel setup code.

This can be very useful for early hardware initialization for No-MMU
kernels booted directly in M-mode because it is quite likely that no
other booting stage exist prior to the No-MMU kernel.

Example use of a SoC early initialization is as follows:

static void vendor_abc_early_init(const void *fdt)
{
	/*
	 * some early init code here that can use simple matches
	 * against the flat device tree file.
	 */
}
SOC_EARLY_INIT_DECLARE("vendor,abc", abc_early_init);

This early initialization function is executed only if the flat device
tree for the board has a 'compatible = "vendor,abc"' entry;

Signed-off-by: Damien Le Moal 
Signed-off-by: Anup Patel 
Signed-off-by: Palmer Dabbelt

RISC-V: Move relocate and few other functions out of __init

2020-03-31T18:25:50+00:00

The secondary hart booting and relocation code are under .init section.
As a result, it will be freed once kernel booting is done. However,
ordered booting protocol and CPU hotplug always requires these functions
to be present to bringup harts after initial kernel boot.

Move the required functions to a different section and make sure that
they are in memory within first 2MB offset as trampoline page directory
only maps first 2MB.

Signed-off-by: Atish Patra 
Reviewed-by: Anup Patel 
Signed-off-by: Palmer Dabbelt

riscv: add alignment for text, rodata and data sections

2020-03-26T16:24:42+00:00

The kernel mapping will tried to optimize its mapping by using bigger
size. In rv64, it tries to use PMD_SIZE, and tryies to use PGDIR_SIZE in
rv32. To ensure that the start address of these sections could fit the
mapping entry size, make them align to the biggest alignment.

Define a macro SECTION_ALIGN because the HPAGE_SIZE or PMD_SIZE, etc.,
are invisible in linker script.

This patch is prepared for STRICT_KERNEL_RWX support.

Signed-off-by: Zong Li 
Signed-off-by: Palmer Dabbelt

riscv: move exception table immediately after RO_DATA

2020-03-26T16:24:39+00:00

Move EXCEPTION_TABLE immediately after RO_DATA. Make it easy to set the
attribution of the sections which should be read-only at a time.
Add _data to specify the start of data section with write permission.
This patch is prepared for STRICT_KERNEL_RWX support.

Signed-off-by: Zong Li 
Signed-off-by: Palmer Dabbelt

RISC-V: Stop putting .sbss in .sdata

2020-03-03T18:28:12+00:00

I don't know why we were doing this, as it's been there since the beginning.
After d841f729e655 ("riscv: force hart_lottery to put in .sdata section") my
guess would be that it made the kernel boot and we forgot to fix it more
cleanly.

The default .bss segment already contains the .sbss section, so we don't need
to do anything additional to ensure the symbols in .sbss continue to work.

Tested-by: Zong Li 
Signed-off-by: Palmer Dabbelt

riscv: Add KASAN support

2020-01-22T21:09:58+00:00

This patch ports the feature Kernel Address SANitizer (KASAN).

Note: The start address of shadow memory is at the beginning of kernel
space, which is 2^64 - (2^39 / 2) in SV39. The size of the kernel space is
2^38 bytes so the size of shadow memory should be 2^38 / 8. Thus, the
shadow memory would not overlap with the fixmap area.

There are currently two limitations in this port,

1. RV64 only: KASAN need large address space for extra shadow memory
region.

2. KASAN can't debug the modules since the modules are allocated in VMALLOC
area. We mapped the shadow memory, which corresponding to VMALLOC area, to
the kasan_early_shadow_page because we don't have enough physical space for
all the shadow memory corresponding to VMALLOC area.

Signed-off-by: Nick Hu 
Reported-by: Greentime Hu 
Signed-off-by: Palmer Dabbelt

vmlinux.lds.h: Replace RW_DATA_SECTION with RW_DATA

2019-11-04T14:57:41+00:00

Rename RW_DATA_SECTION to RW_DATA. (Calling this a "section" is a lie,
since it's multiple sections and section flags cannot be applied to
the macro.)

Signed-off-by: Kees Cook 
Signed-off-by: Borislav Petkov 
Acked-by: Heiko Carstens  # s390
Acked-by: Geert Uytterhoeven  # m68k
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Dave Hansen 
Cc: linux-alpha@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-c6x-dev@linux-c6x.org
Cc: linux-ia64@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Michael Ellerman 
Cc: Michal Simek 
Cc: Rick Edgecombe 
Cc: Segher Boessenkool 
Cc: Will Deacon 
Cc: x86-ml 
Cc: Yoshinori Sato 
Link: https://lkml.kernel.org/r/20191029211351.13243-14-keescook@chromium.org