xavi/android_kernel_m2note/arch/arm/boot/compressed, branch o-8.1

Revert "GCC: Fix up for gcc 5+"

2018-11-30T13:59:28+00:00

This reverts commit ff505baaf412985af758d5820cd620ed9f1a7e05.

GCC: Fix up for gcc 5+

2018-11-29T17:33:27+00:00

Signed-off-by: mydongistiny Signed-off-by: Mister Oyster

Apply CFLAGS, -Os to decompress.o to improve decompress performance during boot-up process

2017-08-30T23:37:57+00:00

Signed-off-by: flar2

ARM: 8618/1: decompressor: reset ttbcr fields to use TTBR0 on ARMv7

2017-04-11T08:57:49+00:00

commit 117e5e9c4cfcb7628f08de074fbfefec1bb678b7 upstream. If the bootloader uses the long descriptor format and jumps to kernel decompressor code, TTBCR may not be in a right state. Before enabling the MMU, it is required to clear the TTBCR.PD0 field to use TTBR0 for translation table walks. The commit dbece45894d3a ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") does the reset of TTBCR.N, but doesn't consider all the bits for the size of TTBCR.N. Clear TTBCR.PD0 field and reset all the three bits of TTBCR.N to indicate the use of TTBR0 and the correct base address width. Fixes: dbece45894d3 ("ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores") Acked-by: Robin Murphy Signed-off-by: Srinivas Ramana Signed-off-by: Russell King Signed-off-by: Willy Tarreau

stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG

2016-11-11T01:14:22+00:00

This changes the stack protector config option into a choice of "None", "Regular", and "Strong": CONFIG_CC_STACKPROTECTOR_NONE CONFIG_CC_STACKPROTECTOR_REGULAR CONFIG_CC_STACKPROTECTOR_STRONG "Regular" means the old CONFIG_CC_STACKPROTECTOR=y option. "Strong" is a new mode introduced by this patch. With "Strong" the kernel is built with -fstack-protector-strong (available in gcc 4.9 and later). This option increases the coverage of the stack protector without the heavy performance hit of -fstack-protector-all. For reference, the stack protector options available in gcc are: -fstack-protector-all: Adds the stack-canary saving prefix and stack-canary checking suffix to _all_ function entry and exit. Results in substantial use of stack space for saving the canary for deep stack users (e.g. historically xfs), and measurable (though shockingly still low) performance hit due to all the saving/checking. Really not suitable for sane systems, and was entirely removed as an option from the kernel many years ago. -fstack-protector: Adds the canary save/check to functions that define an 8 (--param=ssp-buffer-size=N, N=8 by default) or more byte local char array. Traditionally, stack overflows happened with string-based manipulations, so this was a way to find those functions. Very few total functions actually get the canary; no measurable performance or size overhead. -fstack-protector-strong Adds the canary for a wider set of functions, since it's not just those with strings that have ultimately been vulnerable to stack-busting. With this superset, more functions end up with a canary, but it still remains small compared to all functions with only a small change in performance. Based on the original design document, a function gets the canary when it contains any of: - local variable's address used as part of the right hand side of an assignment or function argument - local variable is an array (or union containing an array), regardless of array type or length - uses register local variables https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU Find below a comparison of "size" and "objdump" output when built with gcc-4.9 in three configurations: - defconfig 11430641 kernel text size 36110 function bodies - defconfig + CONFIG_CC_STACKPROTECTOR_REGULAR 11468490 kernel text size (+0.33%) 1015 of 36110 functions are stack-protected (2.81%) - defconfig + CONFIG_CC_STACKPROTECTOR_STRONG via this patch 11692790 kernel text size (+2.24%) 7401 of 36110 functions are stack-protected (20.5%) With -strong, ARM's compressed boot code now triggers stack protection, so a static guard was added. Since this is only used during decompression and was never used before, the exposure here is very small. Once it switches to the full kernel, the stack guard is back to normal. Chrome OS has been using -fstack-protector-strong for its kernel builds for the last 8 months with no problems. Signed-off-by: Kees Cook Cc: Arjan van de Ven Cc: Michal Marek Cc: Russell King Cc: Ralf Baechle Cc: Paul Mundt Cc: James Hogan Cc: Stephen Rothwell Cc: Shawn Guo Cc: Linus Torvalds Cc: Andrew Morton Cc: Peter Zijlstra Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mips@linux-mips.org Cc: linux-arch@vger.kernel.org Link: http://lkml.kernel.org/r/1387481759-14535-3-git-send-email-keescook@chromium.org [ Improved the changelog and descriptions some more. ] Signed-off-by: Ingo Molnar Git-commit: 8779657d29c0ebcc0c94ede4df2f497baf1b563f Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Change-Id: I0c53785c54b9c2bedd6134fb959b59d1d1afb0ef Signed-off-by: David Brown

ARM: add documentation for finding start of physical memory

2016-09-28T13:16:03+00:00

Occasionally, there's a question about the method we use to find the start of physical memory. Add some documentation so we don't have to keep repeating outselves on the mailing list. Signed-off-by: Russell King Signed-off-by: Chet Kener Signed-off-by: engstk

ARM: 8294/1: ATAG_DTB_COMPAT: remove the DT workspace's hardcoded 64KB size

2016-09-28T13:16:02+00:00

There is currently a hardcoded limit of 64KB for the DTB to live in and be extended with ATAG info. Some DTBs have outgrown that limit: $ du -b arch/arm/boot/dts/omap3-n900.dtb 70212 arch/arm/boot/dts/omap3-n900.dtb Furthermore, the actual size passed to atags_to_fdt() included the stack size which is obviously wrong. The initial DTB size is known, so use it to size the allocated workspace with a 50% growth assumption and relocate the temporary stack above that. This is also clamped to 32KB min / 1MB max for robustness against bad DTB data. Reported-by: Pali Rohár Tested-by: Pavel Machek Signed-off-by: Nicolas Pitre Signed-off-by: Russell King Signed-off-by: Chet Kener Signed-off-by: engstk

ARM: compressed/head.S: remove s3c24xx special case

2016-09-28T13:16:01+00:00

addruart from the generic debug macro is doing exactly the same using the common lowlevel uart definition, so there is no cause for this special casing for s3c24xx. Signed-off-by: Heiko Stuebner Signed-off-by: Kukjin Kim Signed-off-by: Chet Kener Signed-off-by: engstk

ARM: 8191/1: decompressor: ensure I-side picks up relocated code

2016-09-28T13:14:30+00:00

To speed up decompression, the decompressor sets up a flat, cacheable mapping of memory. However, when there is insufficient space to hold the page tables for this mapping, we don't bother to enable the caches and subsequently skip all the cache maintenance hooks. Skipping the cache maintenance before jumping to the relocated code allows the processor to predict the branch and populate the I-cache with stale data before the relocation loop has completed (since a bootloader may have SCTLR.I set, which permits normal, cacheable instruction fetches regardless of SCTLR.M). This patch moves the cache maintenance check into the maintenance routines themselves, allowing the v6/v7 versions to invalidate the I-cache regardless of the MMU state. Cc: Reported-by: Marc Carino Tested-by: Julien Grall Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Chet Kener Signed-off-by: engstk

first commit

2016-08-15T02:19:42+00:00