10 Feb, 2009
1 commit
-
Impact: no default -fno-stack-protector if stackp is enabled, cleanup
Stackprotector make rules had the following problems.
* cc support test and warning are scattered across makefile and
kernel/panic.c.* -fno-stack-protector was always added regardless of configuration.
Update such that cc support test and warning are contained in makefile
and -fno-stack-protector is added iff stackp is turned off. While at
it, prepare for 32bit support.Signed-off-by: Tejun Heo
Signed-off-by: Ingo Molnar
19 Jan, 2009
1 commit
-
Conflicts:
arch/x86/include/asm/pda.h
arch/x86/include/asm/system.hAlso, moved include/asm-x86/stackprotector.h to arch/x86/include/asm.
Signed-off-by: Ingo Molnar
07 Jan, 2009
1 commit
-
... because we do want repeated same-oops to be seen by automated
tools like kerneloops.orgSigned-off-by: Arjan van de Ven
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
31 Dec, 2008
1 commit
-
Conflicts:
arch/x86/include/asm/pda.h
kernel/fork.c
25 Dec, 2008
1 commit
02 Dec, 2008
1 commit
-
The description for 'D' was missing in the comment... (causing me a
minute of WTF followed by looking at more of the code)Signed-off-by: Arjan van de Ven
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
29 Nov, 2008
3 commits
-
Impact: cleanup, eliminate code
now that warn_on_slowpath() uses warn_slowpath(...,NULL), we can
eliminate warn_on_slowpath() altogether and use warn_slowpath().Signed-off-by: Ingo Molnar
-
Impact: extend WARN_ON() output with DMI_PRODUCT_NAME
It's very useful for many low level WARN_ON's to find out which
motherboard has the broken BIOS etc... this patch adds a printk
to the WARN_ON code for this.On architectures without DMI, gcc should optimize the code out.
Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar -
Impact: cleanup, code reduction
warn_slowpath is a superset of warn_on_slowpath; just have
warn_on_slowpath call warn_slowpath with a NULL 3rd argument.Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
22 Oct, 2008
1 commit
-
This allows them to be examined and set after boot, plus means they
actually give errors if they are misused (eg. panic=yes).Signed-off-by: Rusty Russell
18 Oct, 2008
1 commit
-
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6: (25 commits)
staging: at76_usb wireless driver
Staging: workaround build system bug
Staging: Lindent sxg.c
Staging: SLICOSS: Call pci_release_regions at driver exit
Staging: SLICOSS: Fix remaining type names
Staging: SLICOSS: Fix warnings due to static usage
Staging: SLICOSS: lots of checkpatch fixes
Staging: go7007 v4l fixes
Staging: Fix gcc warnings in sxg
Staging: add echo cancelation module
Staging: add wlan-ng prism2 usb driver
Staging: add w35und wifi driver
Staging: USB/IP: add host driver
Staging: USB/IP: add client driver
Staging: USB/IP: add common functions needed
Staging: add the go7007 video driver
Staging: add me4000 pci data collection driver
Staging: add me4000 firmware files
Staging: add sxg network driver
Staging: add Alacritech slicoss network driver
...Fixed up conflicts due to taint flags changes and MAINTAINERS cleanup in
MAINTAINERS, include/linux/kernel.h and kernel/panic.c.
17 Oct, 2008
2 commits
-
Move print_tainted() kernel-doc to avoid the following error:
Error(/var/linsrc/mmotm-2008-1002-1617//kernel/panic.c:155): cannot understand prototype: 'struct tnt '
Signed-off-by: Randy Dunlap
Cc: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
It's somewhat unlikely that it happens, but right now a race window
between interrupts or machine checks or oopses could corrupt the tainted
bitmap because it is modified in a non atomic fashion.Convert the taint variable to an unsigned long and use only atomic bit
operations on it.Unfortunately this means the intvec sysctl functions cannot be used on it
anymore.It turned out the taint sysctl handler could actually be simplified a bit
(since it only increases capabilities) so this patch actually removes
code.[akpm@linux-foundation.org: remove unneeded include]
Signed-off-by: Andi Kleen
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Oct, 2008
1 commit
-
Conflicts:
arch/x86/kernel/Makefile
include/asm-x86/pda.h
11 Oct, 2008
1 commit
-
We need to add a flag for all code that is in the drivers/staging/
directory to prevent all other kernel developers from worrying about
issues here, and to notify users that the drivers might not be as good
as they are normally used to.Based on code from Andreas Gruenbacher and Jeff Mahoney to provide a
TAINT flag for the support level of a kernel module in the Novell
enterprise kernel release.This is the kernel portion of this feature, the ability for the flag to
be set needs to be done in the build process and will happen in a
follow-up patch.Cc: Andreas Gruenbacher
Cc: Jeff Mahoney
Signed-off-by: Greg Kroah-Hartman
26 Jul, 2008
1 commit
-
Add a WARN() macro that acts like WARN_ON(), with the added feature that it
takes a printk like argument that is printed as part of the warning message.[akpm@linux-foundation.org: fix printk arguments]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Arjan van de Ven
Cc: Greg KH
Cc: Jiri Slaby
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Jul, 2008
2 commits
-
turns out gcc generates such stackprotector-failure sequences
in certain circumstances:movq -8(%rbp), %rax # D.16032,
xorq %gs:40, %rax #,
jne .L17 #,
leave
ret
.L17:
call __stack_chk_fail #
.size __stack_chk_test_func, .-__stack_chk_test_func
.section .init.text,"ax",@progbits
.type panic_setup, @function
panic_setup:
pushq %rbp #note that there's no jump back to the failing context after the
call to __stack_chk_fail - i.e. it has a ((noreturn)) attribute.Which is fair enough in the normal case but kills the self-test.
(as we cannot reliably return in the self-test)Signed-off-by: Ingo Molnar
-
Clean up the code by removing no longer needed code;
make sure the pda is updated and kept in syncSigned-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
12 Jul, 2008
1 commit
-
check stackprotector functionality by manipulating the canary briefly
during bootup.far more robust than trying to overflow the stack. (which is architecture
dependent, etc.)Signed-off-by: Ingo Molnar
26 May, 2008
5 commits
-
If the user selects the stack-protector config option, but does not have
a gcc that has the right bits enabled (for example because it isn't build
with a glibc that supports TLS, as is common for cross-compilers, but also
because it may be too old), then the runtime test fails right now.This patch adds a warning message for this scenario. This warning accomplishes
two goals
1) the user is informed that the security option he selective isn't available
2) the user is suggested to turn of the CONFIG option that won't work for him,
and would make the runtime test fail anyway.Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
trivial: remove white space addition in stack protector
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
This patch adds a simple self-test capability to the stackprotector
feature. The test deliberately overflows a stack buffer and then
checks if the canary trap function gets called.Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
if CONFIG_DEBUG_BUGVERBOSE is set then the user most definitely wanted
to see as much information about kernel crashes as possible - so give
them at least a stack dump.this is particularly useful for stackprotector related panics, where
the stacktrace can give us the exact location of the (attempted)
attack.Pointed out by pageexec@freemail.hu in the stackprotector breakage
threads.Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
pointed out by pageexec@freemail.hu:
we just simply panic() when there's a stackprotector attack - giving
the attacked person no information about what kernel code the attack went
against.print out the attacked function.
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
29 Apr, 2008
1 commit
-
The kernel is sent to tainted within the warn_on_slowpath() function, and
whenever a warning occurs the new taint flag 'W' is set. This is useful to
know if a warning occurred before a BUG by preserving the warning as a flag
in the taint state.This does not work on architectures where WARN_ON has its own definition.
These archs are:
1. s390
2. superh
3. avr32
4. pariscThe maintainers of these architectures have been added in the Cc: list
in this email to alert them to the situation.The documentation in oops-tracing.txt has been updated to include the
new flag.Signed-off-by: Nur Hussein
Cc: Arjan van de Ven
Cc: "Randy.Dunlap"
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Kyle McMartin
Cc: Martin Schwidefsky
Cc: Haavard Skinnemoen
Cc: Paul Mundt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Feb, 2008
1 commit
-
When an ACPI table is overridden (for now this can happen only for DSDT)
display a big warning and taint the kernel with flag A.Signed-off-by: Eric Piel
Signed-off-by: Len Brown
30 Jan, 2008
2 commits
-
Unlike oopses, WARN_ON() currently does't print the loaded modules list.
This makes it harder to take action on certain bug reports. For example,
recently there were a set of WARN_ON()s reported in the mac80211 stack,
which were just signalling a driver bug. It takes then anther round trip
to the bug reporter (if he responds at all) to find out which driver
is at fault.Another issue is that, unlike oopses, WARN_ON() doesn't currently printk
the helpful "cut here" line, nor the "end of trace" marker.
Now that WARN_ON() is out of line, the size increase due to this is
minimal and it's worth adding.Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
A quick grep shows that there are currently 1145 instances of WARN_ON
in the kernel. Currently, WARN_ON is pretty much entirely inlined,
which makes it hard to enhance it without growing the size of the kernel
(and getting Andrew unhappy).This patch build on top of Olof's patch that introduces __WARN,
and places the slowpath out of line. It also uses Ingo's suggestion
to not use __FUNCTION__ but to use kallsyms to do the lookup;
this saves a ton of extra space since gcc doesn't need to store the function
string twice now:3936367 833603 624736 5394706 525112 vmlinux.before
3917508 833603 624736 5375847 520767 vmlinux-slowpath15Kb savings...
Signed-off-by: Arjan van de Ven
CC: Andrew Morton
CC: Olof Johansson
Acked-by: Matt Meckall
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
20 Dec, 2007
1 commit
-
Right now it's nearly impossible for parsers that collect kernel crashes
from logs or emails (such as www.kerneloops.org) to detect the
end-of-oops condition. In addition, it's not currently possible to
detect whether or not 2 oopses that look alike are actually the same
oops reported twice, or are truly two unique oopses.This patch adds an end-of-oops marker, and makes the end marker include
a very simple 64-bit random ID to be able to detect duplicate reports.Normally, this ID is calculated as a late_initcall() (in the hope that
at that time there is enough entropy to get a unique enough ID); however
for early oopses the oops_exit() function needs to generate the ID on
the fly.We do this all at the _end_ of an oops printout, so this does not impact
our ability to get the most important portions of a crash out to the
console first.[ Sidenote: the already existing oopses-since-bootup counter we print
during crashes serves as the differentiator between multiple oopses
that trigger during the same bootup. ]Tested on 32-bit and 64-bit x86. Artificially injected very early
crashes as well, as expected they result in this constant ID after
multiple bootups:---[ end trace ca143223eefdc828 ]---
---[ end trace ca143223eefdc828 ]---because the random pools are still all zero. But it all still works
fine and causes no additional problems (which is the main goal of
instrumentation code).Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
20 Oct, 2007
1 commit
-
Signed-off-by: Daniel Roesen
Signed-off-by: Adrian Bunk
19 Oct, 2007
1 commit
-
Signed-off-by: Daniel Walker
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
18 Jul, 2007
1 commit
-
If the kernel OOPSed or BUGed then it probably should be considered as
tainted. Thus, all subsequent OOPSes and SysRq dumps will report the
tainted kernel. This saves a lot of time explaining oddities in the
calltraces.Signed-off-by: Pavel Emelianov
Acked-by: Randy Dunlap
Cc:
Signed-off-by: Andrew Morton
[ Added parisc patch from Matthew Wilson -Linus ]
Signed-off-by: Linus Torvalds
12 Feb, 2007
1 commit
-
Allow taint flags to be set from userspace by writing to
/proc/sys/kernel/tainted, and add a new taint flag, TAINT_USER, to be used
when userspace has potentially done something dangerous that might
compromise the kernel. This will allow support personnel to ask further
questions about what may have caused the user taint flag to have been set.For example, they might examine the logs of the realtime JVM to see if the
Java program has used the really silly, stupid, dangerous, and
completely-non-portable direct access to physical memory feature which MUST
be implemented according to the Real-Time Specification for Java (RTSJ).
Sigh. What were those silly people at Sun thinking?[akpm@osdl.org: build fix]
[bunk@stusta.de: cleanup]
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Adrian Bunk
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Sep, 2006
1 commit
-
Use prototypes in headers
Don't define panic_on_unrecovered_nmi for all architecturesCc: dzickus@redhat.com
Signed-off-by: Andi Kleen
26 Sep, 2006
2 commits
-
GCC emits a call to a __stack_chk_fail() function when the stack canary is
not matching the expected value.Since this is a bad security issue; lets panic the kernel rather than limping
along; the kernel really can't be trusted anymore when this happens.Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
Signed-off-by: Andi Kleen
CC: Andi Kleen -
To quote Alan Cox:
The default Linux behaviour on an NMI of either memory or unknown is to
continue operation. For many environments such as scientific computing
it is preferable that the box is taken out and the error dealt with than
an uncorrected parity/ECC error get propogated.A small number of systems do generate NMI's for bizarre random reasons
such as power management so the default is unchanged. In other respects
the new proc/sys entry works like the existing panic controls already in
that directory.This is separate to the edac support - EDAC allows supported chipsets to
handle ECC errors well, this change allows unsupported cases to at least
panic rather than cause problems further down the line.Signed-off-by: Don Zickus
Signed-off-by: Andi Kleen
07 Sep, 2006
1 commit
-
Remove an unintended console_verbose() side-effect from add_taint().
Signed-off-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Aug, 2006
1 commit
-
kernel/panic.c: In function 'add_taint':
kernel/panic.c:176: warning: implicit declaration of function 'debug_locks_off'Cc: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman
11 Jul, 2006
1 commit
-
Disable lockdep debugging in two situations where the integrity of the
kernel no longer is guaranteed: when oopsing and when hitting a
tainting-condition. The goal is to not get weird lockdep traces that don't
make sense or are otherwise undebuggable, to not waste time.Lockdep assumes that the previous state it knows about is valid to operate,
which is why lockdep turns itself off after the first violation it reports,
after that point it can no longer make that assumption.A kernel oops means that the integrity of the kernel compromised; in
addition anything lockdep would report is of lesser importance than the
oops.All the tainting conditions are of similar integrity-violating nature and
also make debugging/diagnosing more difficult.Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 Jul, 2006
1 commit
-
Signed-off-by: Jörn Engel
Signed-off-by: Adrian Bunk
