Linux kernel documentation tree maintained by Jonathan Corbet http://mirrors.hust.edu.cn/git/lwn.git/atom?h=v3.14.39 2014-10-05T21:52:16+00:00 2014-10-05T21:52:16+00:00 Nathan Lynch nathan_lynch@mentor.com 2014-09-11T01:49:08+00:00 urn:sha1:d164cc67d028228ac8f216930aec3442c47321bc commit fbfb872f5f417cea48760c535e0ff027c88b507a upstream. The TPIDRURO and TPIDRURW registers need to be flushed during exec; otherwise TLS information is potentially leaked. TPIDRURO in particular needs careful treatment. Since flush_thread basically needs the same code used to set the TLS in arm_syscall, pull that into a common set_tls helper in tls.h and use it in both places. Similarly, TEEHBR needs to be cleared during exec as well. Clearing its save slot in thread_info isn't right as there is no guarantee that a thread switch will occur before the new program runs. Just setting the register directly is sufficient. Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2013-12-09T23:24:31+00:00 Konstantin Khlebnikov k.khlebnikov@samsung.com 2013-12-05T13:21:36+00:00 urn:sha1:1b15ec7a7427d4188ba91b9bbac696250a059d22 get_wchan() is lockless. Task may wakeup at any time and change its own stack, thus each next stack frame may be overwritten and filled with random stuff. /proc/$pid/stack interface had been disabled for non-current tasks, see [1] But 'wchan' still allows to trigger stack frame unwinding on volatile stack. This patch fixes oops in unwind_frame() by adding stack pointer validation on each step (as x86 code do), unwind_frame() already checks frame pointer. Also I've found another report of this oops on stackoverflow (irony). Link: http://www.spinics.net/lists/arm-kernel/msg110589.html [1] Link: http://stackoverflow.com/questions/18479894/unwind-frame-cause-a-kernel-paging-error Cc: <stable@vger.kernel.org> Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 2013-08-13T19:23:28+00:00 Russell King rmk+kernel@arm.linux.org.uk 2013-08-13T19:23:28+00:00 urn:sha1:2a2822475d0e734adffab72644329d9c042ce2e1 2013-08-07T13:00:10+00:00 Russell King rmk+kernel@arm.linux.org.uk 2013-08-06T08:49:14+00:00 urn:sha1:1d0bbf428924f94867542d49d436cf254b9dbd06 Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 2013-08-03T09:49:38+00:00 Russell King rmk+kernel@arm.linux.org.uk 2013-08-03T09:49:38+00:00 urn:sha1:e35ac62d2202e31307c0f9b278a61e484c4727f2 2013-08-03T09:30:05+00:00 Russell King rmk+kernel@arm.linux.org.uk 2013-08-03T09:30:05+00:00 urn:sha1:e0d407564b532d978b03ceccebd224a05d02f111 Unfortunately, I never committed the fix to a nasty oops which can occur as a result of that commit: ------------[ cut here ]------------ kernel BUG at /home/olof/work/batch/include/linux/mm.h:414! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 490 Comm: killall5 Not tainted 3.11.0-rc3-00288-gabe0308 #53 task: e90acac0 ti: e9be8000 task.ti: e9be8000 PC is at special_mapping_fault+0xa4/0xc4 LR is at __do_fault+0x68/0x48c This doesn't show up unless you do quite a bit of testing; a simple boot test does not do this, so all my nightly tests were passing fine. The reason for this is that install_special_mapping() expects the page array to stick around, and as this was only inserting one page which was stored on the kernel stack, that's why this was blowing up. Reported-by: Olof Johansson <olof@lixom.net> Tested-by: Olof Johansson <olof@lixom.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 2013-08-01T19:51:13+00:00 Russell King rmk+kernel@arm.linux.org.uk 2013-08-01T19:51:13+00:00 urn:sha1:24195cad3e00557da166d629c8b0fd2f984f2170 2013-08-01T13:41:39+00:00 Stephen Boyd sboyd@codeaurora.org 2013-07-30T22:09:46+00:00 urn:sha1:44424c34049f41123a3a8b4853822f47f4ff03a2 If one process calls sys_reboot and that process then stops other CPUs while those CPUs are within a spin_lock() region we can potentially encounter a deadlock scenario like below. CPU 0 CPU 1 ----- ----- spin_lock(my_lock) smp_send_stop() <send IPI> handle_IPI() disable_preemption/irqs while(1); <PREEMPT> spin_lock(my_lock) <--- Waits forever We shouldn't attempt to run any other tasks after we send a stop IPI to a CPU so disable preemption so that this task runs to completion. We use local_irq_disable() here for cross-arch consistency with x86. Reported-by: Sundarajan Srinivasan <sundaraj@codeaurora.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 2013-08-01T13:31:58+00:00 Russell King rmk+kernel@arm.linux.org.uk 2013-07-31T20:58:56+00:00 urn:sha1:a5463cd3435475386cbbe7b06e01292ac169d36f If kuser helpers are not provided by the kernel, disable user access to the vectors page. With the kuser helpers gone, there is no reason for this page to be visible to userspace. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 2013-08-01T13:31:56+00:00 Russell King rmk+kernel@arm.linux.org.uk 2013-07-23T23:29:18+00:00 urn:sha1:48be69a026b2c17350a5ef18a1959a919f60be7d Move the signal handlers into a VDSO page rather than keeping them in the vectors page. This allows us to place them randomly within this page, and also map the page at a random location within userspace further protecting these code fragments from ROP attacks. The new VDSO page is also poisoned in the same way as the vector page. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>