aboutsummaryrefslogtreecommitdiffstats
path: root/arch/powerpc/kernel/prom_init_check.sh (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-10-29powerpc/prom_init: Undo relocation before entering secure modeThiago Jung Bauermann1-1/+2
The ultravisor will do an integrity check of the kernel image but we relocated it so the check will fail. Restore the original image by relocating it back to the kernel virtual base address. This works because during build vmlinux is linked with an expected virtual runtime address of KERNELBASE. Fixes: 6a9c930bd775 ("powerpc/prom_init: Add the ESM call to prom_init") Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Tested-by: Michael Anderson <andmike@linux.ibm.com> [mpe: Add IS_ENABLED() to fix the CONFIG_RELOCATABLE=n build] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190911163433.12822-1-bauerman@linux.ibm.com
2019-09-04kbuild: add $(BASH) to run scripts with bash-extensionMasahiro Yamada1-1/+1
CONFIG_SHELL falls back to sh when bash is not installed on the system, but nobody is testing such a case since bash is usually installed. So, shell scripts invoked by CONFIG_SHELL are only tested with bash. It makes it difficult to test whether the hashbang #!/bin/sh is real. For example, #!/bin/sh in arch/powerpc/kernel/prom_init_check.sh is false. (I fixed it up) Besides, some shell scripts invoked by CONFIG_SHELL use bash-extension and #!/bin/bash is specified as the hashbang, while CONFIG_SHELL may not always be set to bash. Probably, the right thing to do is to introduce BASH, which is bash by default, and always set CONFIG_SHELL to sh. Replace $(CONFIG_SHELL) with $(BASH) for bash scripts. If somebody tries to add bash-extension to a #!/bin/sh script, it will be caught in testing because /bin/sh is a symlink to dash on some major distributions. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-15Merge tag 'powerpc-5.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds1-1/+1
Pull powerpc fixes from Michael Ellerman: "One fix for a regression introduced by our 32-bit KASAN support, which broke booting on machines with "bootx" early debugging enabled. A fix for a bug which broke kexec on 32-bit, introduced by changes to the 32-bit STRICT_KERNEL_RWX support in v5.1. Finally two fixes going to stable for our THP split/collapse handling, discovered by Nick. The first fixes random crashes and/or corruption in guests under sufficient load. Thanks to: Nicholas Piggin, Christophe Leroy, Aaro Koskinen, Mathieu Malaterre" * tag 'powerpc-5.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/32s: fix booting with CONFIG_PPC_EARLY_DEBUG_BOOTX powerpc/64s: __find_linux_pte() synchronization vs pmdp_invalidate() powerpc/64s: Fix THP PMD collapse serialisation powerpc: Fix kexec failure on book3s/32
2019-06-07powerpc/32s: fix booting with CONFIG_PPC_EARLY_DEBUG_BOOTXChristophe Leroy1-1/+1
When booting through OF, setup_disp_bat() does nothing because disp_BAT are not set. By change, it used to work because BOOTX buffer is mapped 1:1 at address 0x81000000 by the bootloader, and btext_setup_display() sets virt addr same as phys addr. But since commit 215b823707ce ("powerpc/32s: set up an early static hash table for KASAN."), a temporary page table overrides the bootloader mapping. This 0x81000000 is also problematic with the newly implemented Kernel Userspace Access Protection (KUAP) because it is within user address space. This patch fixes those issues by properly setting disp_BAT through a call to btext_prepare_BAT(), allowing setup_disp_bat() to properly setup BAT3 for early bootx screen buffer access. Reported-by: Mathieu Malaterre <malat@debian.org> Fixes: 215b823707ce ("powerpc/32s: set up an early static hash table for KASAN.") Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Tested-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152Thomas Gleixner1-4/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-03powerpc/prom_init: don't use string functions from lib/Christophe Leroy1-1/+1
When KASAN is active, the string functions in lib/ are doing the KASAN checks. This is too early for prom_init. This patch implements dedicated string functions for prom_init, which will be compiled in with KASAN disabled. Size of prom_init before the patch: text data bss dec hex filename 12060 488 6960 19508 4c34 arch/powerpc/kernel/prom_init.o Size of prom_init after the patch: text data bss dec hex filename 12460 488 6960 19908 4dc4 arch/powerpc/kernel/prom_init.o This increases the size of prom_init a bit, but as prom_init is in __init section, it is freed after boot anyway. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-05-03powerpc: prepare string/mem functions for KASANChristophe Leroy1-1/+9
CONFIG_KASAN implements wrappers for memcpy() memmove() and memset() Those wrappers are doing the verification then call respectively __memcpy() __memmove() and __memset(). The arches are therefore expected to rename their optimised functions that way. For files on which KASAN is inhibited, #defines are used to allow them to directly call optimised versions of the functions without going through the KASAN wrappers. See commit 393f203f5fd5 ("x86_64: kasan: add interceptors for memset/memmove/memcpy functions") for details. Other string / mem functions do not (yet) have kasan wrappers, we therefore have to fallback to the generic versions when KASAN is active, otherwise KASAN checks will be skipped. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> [mpe: Fixups to keep selftests working] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-10-19powerpc: Check prom_init for disallowed sectionsBenjamin Herrenschmidt1-0/+16
prom_init.c must not modify the kernel image outside of the .bss.prominit section. Thus make sure that prom_init.o doesn't have anything in any of these: .data .bss .init.data Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-04-04powerpc/mm/radix: Update command line parsing for disable_radixAneesh Kumar K.V1-1/+1
kernel parameter disable_radix takes different options disable_radix=yes|no|1|0 or just disable_radix. prom_init parsing is not supporting these options. Fixes: 1fd6c0220710 ("powerpc/mm: Add a CONFIG option to choose if radix is used by default") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2014-09-25powerpc: Simplify symbol check in prom_init_check.shAndreas Schwab1-16/+6
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2014-06-25powerpc/powernv: Remove OPAL v1 takeoverMichael Ellerman1-3/+1
In commit 27f4488872d9 "Add OPAL takeover from PowerVM" we added support for "takeover" on OPAL v1 machines. This was a mode of operation where we would boot under pHyp, and query for the presence of OPAL. If detected we would then do a special sequence to take over the machine, and the kernel would end up running in hypervisor mode. OPAL v1 was never a supported product, and was never shipped outside IBM. As far as we know no one is still using it. Newer versions of OPAL do not use the takeover mechanism. Although the query for OPAL should be harmless on machines with newer OPAL, we have seen a machine where it causes a crash in Open Firmware. The code in early_init_devtree() to copy boot_command_line into cmd_line was added in commit 817c21ad9a1f "Get kernel command line accross OPAL takeover", and AFAIK is only used by takeover, so should also be removed. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-04-23powerpc: Ignore .TOC. relocationsAnton Blanchard1-1/+1
The linker fixes up .TOC. relocations, so prom_init_check.sh should ignore them. Signed-off-by: Anton Blanchard <anton@samba.org>
2013-08-14powerpc/pmac: Early debug output on screen on 64-bit macsBenjamin Herrenschmidt1-1/+2
We have a bunch of CONFIG_PPC_EARLY_DEBUG_* options that are intended for bringup/debug only. They hard wire a machine specific udbg backend very early on (before we even probe the platform), and use whatever tricks are available on each machine/cpu to be able to get some kind of output out there early on. So far, on powermac with no serial ports, we have CONFIG_PPC_EARLY_DEBUG_BOOTX to use the low-level btext engine on the screen, but it doesn't do much, at least on 64-bit. It only really gets enabled after the platform has been probed and the MMU enabled. This adds a way to enable it much earlier. From prom_init.c (while still running with Open Firmware), we grab the screen details and set things up using the physical address of the frame buffer. Then btext itself uses the "rm_ci" feature of the 970 processor (Real Mode Cache Inhibited) to access it while in real mode. We need to do a little bit of reorg of the btext code to inline things better, in order to limit how much we touch memory while in this mode as the consequences might be ... interesting. This successfully allowed me to debug problems early on with the G5 (related to gold being broken vs. ppc64 kernels). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-01-10powerpc: Relocate prom_init.c on 64bitAnton Blanchard1-1/+1
The ppc64 kernel can get loaded at any address which means our very early init code in prom_init.c must be relocatable. We do this with a pretty nasty RELOC() macro that we wrap accesses of variables with. It is very fragile and sometimes we forget to add a RELOC() to an uncommon path or sometimes a compiler change breaks it. 32bit has a much more elegant solution where we build prom_init.c with -mrelocatable and then process the relocations manually. Unfortunately we can't do the equivalent on 64bit and we would have to build the entire kernel relocatable (-pie), resulting in a large increase in kernel footprint (megabytes of relocation data). The relocation data will be marked __initdata but it still creates more pressure on our already tight memory layout at boot. Alan Modra pointed out that the 64bit ABI is relocatable even if we don't build with -pie, we just need to relocate the TOC. This patch implements that idea and relocates the TOC entries of prom_init.c. An added bonus is there are very few relocations to process which helps keep boot times on simulators down. gcc does not put 64bit integer constants into the TOC but to be safe we may want a build time script which passes through the prom_init.c TOC entries to make sure everything looks reasonable. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-09-20powerpc/powernv: Get kernel command line accross OPAL takeoverBenjamin Herrenschmidt1-1/+2
We stash it in boot_command_line which isn't in BSS and so won't be overwritten. We then use that as a default cmd_line before we walk the device-tree. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-09-20powerpc/powernv: Add OPAL takeover from PowerVMBenjamin Herrenschmidt1-1/+2
On machines supporting the OPAL firmware version 1, the system is initially booted under pHyp. We then use a special hypercall to verify if OPAL is available and if it is, we then trigger a "takeover" which disables pHyp and loads the OPAL runtime firmware, giving control to the kernel in hypervisor mode. This patch add the necessary code to detect that the OPAL takeover capability is present when running under PowerVM (aka pHyp) and perform said takeover to get hypervisor control of the processor. To perform the takeover, we must first use RTAS (within Open Firmware runtime environment) to start all processors & threads, in order to give control to OPAL on all of them. We then call the takeover hypercall on everybody, OPAL will re-enter the kernel main entry point passing it a flat device-tree. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-07-08powerpc: Fix compile errors in prom_init_check for gcc 4.5Stephen Rothwell1-0/+6
Just whitelist these extra compiler generated symbols. Fixes these errors: Error: External symbol '_restgpr0_14' referenced from prom_init.c Error: External symbol '_restgpr0_20' referenced from prom_init.c Error: External symbol '_restgpr0_22' referenced from prom_init.c Error: External symbol '_restgpr0_24' referenced from prom_init.c Error: External symbol '_restgpr0_25' referenced from prom_init.c Error: External symbol '_restgpr0_26' referenced from prom_init.c Error: External symbol '_restgpr0_27' referenced from prom_init.c Error: External symbol '_restgpr0_28' referenced from prom_init.c Error: External symbol '_restgpr0_29' referenced from prom_init.c Error: External symbol '_restgpr0_31' referenced from prom_init.c Error: External symbol '_savegpr0_14' referenced from prom_init.c Error: External symbol '_savegpr0_20' referenced from prom_init.c Error: External symbol '_savegpr0_22' referenced from prom_init.c Error: External symbol '_savegpr0_24' referenced from prom_init.c Error: External symbol '_savegpr0_25' referenced from prom_init.c Error: External symbol '_savegpr0_26' referenced from prom_init.c Error: External symbol '_savegpr0_27' referenced from prom_init.c Error: External symbol '_savegpr0_28' referenced from prom_init.c Error: External symbol '_savegpr0_29' referenced from prom_init.c Error: External symbol '_savegpr0_31' referenced from prom_init.c Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-03-11powerpc: Print linux_banner in prom_initMichael Ellerman1-1/+1
So at least you can see what kernel you're booting if you die before the kernel prints it mid-way through start_kernel(). Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-10-21powerpc: Fix build issue with CONFIG_RELOCATABLE=yKumar Gala1-1/+1
There are two issues when we enable CONFIG_RELOCATABLE. The first is due to the fact that phys_addr_t is now defined in linux/types.h. The second is due to the fact that the DMA code changes expose memstart_addr to prom_init.c Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-06-16[POWERPC] Fix -Os kernel builds with newer gcc versionsKumar Gala1-0/+14
GCC 4.4.x looks to be adding support for generating out-of-line register saves/restores based on: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html This breaks the kernel if we enable CONFIG_CC_OPTIMIZE_FOR_SIZE. To fix this we add the use the save/restore code from gcc and simplified it down for our needs (integer only). Additionally, we have to link this code into each module. The other solution was to add EXPORT_SYMBOL() which meant going through the trampoline which seemed nonsensical for these out-of-line routines. Finally, we add some checks to prom_init_check.sh to ignore the out-of-line save/restore functions. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-23[POWERPC] Add kernstart_addr to list of allowed symbols in prom_initMichael Ellerman1-1/+1
Since commit "85xx: Add support for relocatable kernel (and booting at non-zero)" (37dd2badcfcec35f5e21a0926968d77a404f03c3), PHYSICAL_START is #defined as kernstart_addr if RELOCATABLE and FLATMEM is enabled. PHYSICAL_START is used in prom_init.c and so kernstart_addr needs to be added to the list of allowed symbols that prom_init.c can access. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-24[POWERPC] Discourage people from fiddling with kernel data from prom_initMichael Ellerman1-0/+58
As BenH said the other day, it is an "accident" that prom_init.o is linked with the rest of the kernel. The truth is a little more subtle, prom_init isn't truly bootloader, it does access kernel data in a few places. What we can do is discourage people from adding new code that accesses data outside of prom_init. And hence this patch; from the script: # This script checks prom_init.o to see what external symbols it # is using, if it finds symbols not in the whitelist it returns # an error. The point of this is to discourage people from # intentionally or accidentally adding new code to prom_init.c # which has side effects on other parts of the kernel. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>