xavi/android_kernel_m2note, branch lp-5.1

Revert "proc: Remove verifiedbootstate flag from /proc/cmdline"

2016-11-24T20:21:12+00:00

This commit breaks Offline Charging mode on Mediatek platforms (at least mt6753 and mt6795) This reverts commit 81cd48af4ce91983fa556039f52bdede850c4e52.

Revert "hand-pick: mediatek:remove unnecessary sido call flow"

2016-11-11T01:48:27+00:00

This reverts commit 9a7858491639342b5d3c8d496d3b9370d2330591.

wlan: WiFi Direct CTS fixs

2016-11-11T01:45:23+00:00

Cylen Yao Details: 1. WiFi Direct CTS tests will fail as supplicant and driver could not keep sync in following case: 1.1 supplicant will request channel when do p2p listen, but driver/firmware has not switch to the target channel when supplicant get remain on channel credit by call driver API of remain on channel; This will make supplicant and driver in unsync state which will make supplicant fail to go to listen state randomly. 1.2 Supplicant and driver will also keep unsync when do mgmt frame TX; supplicant will do other task once mgmt frame TX is returned by calling driver API mgmt_tx, but, driver has not actually TX the mgmt frame out. In extremely case, driver will drop the second mgmt frame if the previous on has not been TX out, just as the group owner test case.

tty: Properly fix memleak of alloc_pid

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

Cylen Yao bug: 7845126 MT67x2 Memleak is due to unreleased pid->count, which execute in function: get_pid()(pid->count++) and put_pid()(pid->count--). The race condition as following: task[dumpsys] task[adbd] in disassociate_ctty() in tty_signal_session_leader() ----------------------- ------------------------- tty = get_current_tty(); // tty is not NULL ... spin_lock_irq(¤t->sighand->siglock); put_pid(current->signal->tty_old_pgrp); current->signal->tty_old_pgrp = NULL; spin_unlock_irq(¤t->sighand->siglock); spin_lock_irq(&p->sighand->siglock); ... p->signal->tty = NULL; ... spin_unlock_irq(&p->sighand->siglock); tty = get_current_tty(); // tty NULL, goto else branch by accident. if (tty) { ... put_pid(tty_session); put_pid(tty_pgrp); ... } else { print msg } in task[dumpsys], in disassociate_ctty(), tty is set NULL by task[adbd], tty_signal_session_leader(), then it goto else branch and lack of put_pid(), cause memleak. move spin_unlock(sighand->siglock) after get_current_tty() can avoid the race and fix the memleak.

KBUILD_CFLAGS: Some more tuning

2016-11-11T01:45:21+00:00

use -ftree-vectorize

KBUILD_CFLAGS: Some tuning

2016-11-11T01:45:20+00:00

use cortex-a53 and arm platf proper optimized flags

Fix "Security Vulnerability - kernel info leak of wifi driver"

2016-11-11T01:45:18+00:00

stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG

2016-11-11T01:04:09+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

stackprotector: Unify the HAVE_CC_STACKPROTECTOR logic between architectures

2016-11-11T01:04:05+00:00

Instead of duplicating the CC_STACKPROTECTOR Kconfig and Makefile logic in each architecture, switch to using HAVE_CC_STACKPROTECTOR and keep everything in one place. This retains the x86-specific bug verification scripts. 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: Thomas Gleixner 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-2-git-send-email-keescook@chromium.org Signed-off-by: Ingo Molnar [davidb@codeaurora.org: Simple Kconfig merge resolution] Git-commit: 19952a92037e752f9d3bbbad552d596f9a56e146 Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Change-Id: I6e430de3c79306724e90ea1178f242145c39f059 Signed-off-by: David Brown Conflicts: arch/x86/Kconfig

defconfig: enable CC_STACKPROTECTOR-STRONG

2016-11-11T00:59:59+00:00