Message-Id: <E1GILQi-0004QF-00@ixion.tartarus.org>
Date:	Wed, 30 Aug 2006 09:28:12 +0100
From:	Simon Tatham <anakin@...ox.com>
To:	linux-kernel@...r.kernel.org
Subject: Magic SysRq SAK does nothing on serial consoles

The SAK subfunction of the `magic SysRq key' feature does not do
anything when invoked on a serial console. It should.

I am running Linux 2.6.17.6 on a Soekris net4501, which is a machine
with no graphics card and just a (normal 8250) serial port. I am
using the serial port as the kernel's console. I also have
CONFIG_MAGIC_SYSRQ enabled in my kernel configuration. When I
instruct my terminal to send a BREAK down the serial line and then
press Return, the kernel prints the SysRq menu, with one of the
options being `saK'. But if I send a BREAK and then press k, the
kernel prints `SysRq : SAK' and then does nothing further. No
processes are killed.

Investigation suggested that the problem might be that
sysrq_handle_SAK() in drivers/char/sysrq.c was not getting a tty
structure passed in, so that it did not know which tty to kill
processes associated with. So I traced the chain of calls leading to
that point, and ended up in include/linux/serial_core.h, where
uart_handle_sysrq_char() calls handle_sysrq() and does indeed pass
NULL as the third (struct tty *) parameter. The fix seemed simple:
instead of NULL it should pass the tty structure associated with the
serial port.

Applying the attached patch resolved the problem for me; now when I
send BREAK-k, the kernel prints `SysRq : SAK', then prints a couple
of lines indicating that some processes have been killed, and then
init spawns a new login process as I would expect.

(The patch is defensively coded, since I wasn't sure whether
port->info was guaranteeably non-NULL. If it is, the change can be
even simpler!)

This bug could be argued to have security implications. Suppose
somebody has written a program which imitates a login prompt, and
left it running on the serial port. I come along and send BREAK-k,
expecting it to kill any malicious programs and return me to a real
login prompt. The kernel prints `SysRq : SAK', indicating that it's
heard me and intends to perform the SAK function, and then I hit
Return and get what looks like a login prompt - but no processes
have been killed, so it's still the malicious imitation! I admit
that _now_ I wouldn't fall for this, since I've now seen the proper
SAK in action and I know that (a) it prints additional messages to
indicate what processes it's killing and (b) I would expect the
login prompt to return immediately afterwards without me having to
press Return; but I might have fallen for it if I'd tried this
before I knew there was a problem.

Some details of my hardware and software follow, as suggested in
http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html . I
think this problem is simple enough that most of this should be
unnecessary, but here it is anyway just in case.

Output of linux-2.6.17.6/scripts/ver_linux, on the machine on which
I built the kernel (which is not the same machine I saw the problem
on, because the net4501 is too slow for me to want to build a kernel
on it at all):

| If some fields are empty or look unusual you may have an old version.
| Compare to the current minimal requirements in Documentation/Changes.
|
| Linux stormhawk 2.6.17.6 #11 Tue Aug 8 18:32:04 BST 2006 i686 GNU/Linux
|
| Gnu C                  3.3.5
| Gnu make               3.80
| binutils               2.15
| util-linux             2.12p
| mount                  2.12p
| module-init-tools      implemented
| e2fsprogs              1.37
| nfs-utils              1.0.6
| Linux C Library        2.3.2
| Dynamic linker (ldd)   2.3.2
| Procps                 3.2.1
| Net-tools              1.60
| Console-tools          0.2.3
| Sh-utils               5.2.1
| udev                   056
| Modules Loaded

Contents of /proc/cpuinfo on the machine which exhibits the problem:

| processor       : 0
| vendor_id       : AuthenticAMD
| cpu family      : 4
| model           : 15
| model name      : Am5x86-WB
| stepping        : 4
| fdiv_bug        : no
| hlt_bug         : no
| f00f_bug        : no
| coma_bug        : no
| fpu             : yes
| fpu_exception   : yes
| cpuid level     : 1
| wp              : yes
| flags           : fpu up
| bogomips        : 66.76

No kernel modules are loaded on the problem machine: /proc/modules
is completely empty.

Contents of /proc/ioports on the problem machine:

| 0000-001f : dma1
| 0020-0021 : pic1
| 0040-0043 : timer0
| 0050-0053 : timer1
| 0060-006f : keyboard
| 0070-0077 : rtc
| 0080-008f : dma page reg
| 00a0-00a1 : pic2
| 00c0-00df : dma2
| 00f0-00ff : fpu
| 01f0-01f7 : ide0
| 02f8-02ff : serial
| 03d4-03d5 : cga
| 03f6-03f6 : ide0
| 03f8-03ff : serial
| e000-e0ff : 0000:00:12.0
|   e000-e0ff : natsemi
| e100-e1ff : 0000:00:13.0
|   e100-e1ff : natsemi
| e200-e2ff : 0000:00:14.0
|   e200-e2ff : natsemi

Output of `lspci -vvv' on the problem machine:

| 0000:00:00.0 Host bridge: Advanced Micro Devices [AMD] ELanSC520 Microcontroller
| 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
| 	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
| 	Latency: 0
|
| 0000:00:12.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
| 	Subsystem: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
| 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
| 	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
| 	Latency: 63 (2750ns min, 13000ns max)
| 	Interrupt: pin A routed to IRQ 10
| 	Region 0: I/O ports at e000 [size=256]
| 	Region 1: Memory at a0000000 (32-bit, non-prefetchable) [size=4K]
| 	Expansion ROM at 3f000000 [disabled] [size=64K]
| 	Capabilities: [40] Power Management version 2
| 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=320mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
| 		Status: D0 PME-Enable- DSel=0 DScale=0 PME+
|
| 0000:00:13.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
| 	Subsystem: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
| 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
| 	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
| 	Latency: 63 (2750ns min, 13000ns max)
| 	Interrupt: pin A routed to IRQ 11
| 	Region 0: I/O ports at e100 [size=256]
| 	Region 1: Memory at a0001000 (32-bit, non-prefetchable) [size=4K]
| 	Expansion ROM at 10000000 [disabled] [size=64K]
| 	Capabilities: [40] Power Management version 2
| 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=320mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
| 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
|
| 0000:00:14.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
| 	Subsystem: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
| 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
| 	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
| 	Latency: 63 (2750ns min, 13000ns max)
| 	Interrupt: pin A routed to IRQ 5
| 	Region 0: I/O ports at e200 [size=256]
| 	Region 1: Memory at a0002000 (32-bit, non-prefetchable) [size=4K]
| 	Expansion ROM at 10010000 [disabled] [size=64K]
| 	Capabilities: [40] Power Management version 2
| 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=320mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
| 		Status: D0 PME-Enable- DSel=0 DScale=0 PME+

There is no /proc/scsi at all on the problem machine.

I also attach /proc/config.gz from the problem machine, in case it
contains any other important clues.

Finally, I apologise for sending this to the central Linux kernel
address instead of a particular maintainer. I looked through the
MAINTAINERS file and found a variety of people responsible for
particular serial drivers, but couldn't find anyone specifically
responsible for general cross-driver serial functionality. I hope
this report can find its way to the right person.

Cheers,
Simon
-- 
Simon Tatham         "A defensive weapon is one with my finger on the
<anakin@...ox.com>    trigger. An offensive weapon is one with yours."

View attachment "linux-sak-serial.patch" of type "text/x-patch" (423 bytes)

Download attachment "config.gz" of type "application/octet-stream" (7096 bytes)

Powered by blists - more mailing lists