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 <[email protected]> trigger. An offensive weapon is one with yours."
--- linux-2.6.17.6.orig/include/linux/serial_core.h 2006-07-15 20:00:43.000000000 +0100 +++ linux-2.6.17.6/include/linux/serial_core.h 2006-08-30 07:55:00.000000000 +0100 @@ -411,7 +411,7 @@ #ifdef SUPPORT_SYSRQ if (port->sysrq) { if (ch && time_before(jiffies, port->sysrq)) { - handle_sysrq(ch, regs, NULL); + handle_sysrq(ch, regs, port->info ? port->info->tty : NULL); port->sysrq = 0; return 1; }
Attachment:
config.gz
Description: Binary data
- Follow-Ups:
- Re: Magic SysRq SAK does nothing on serial consoles
- From: Pavel Machek <[email protected]>
- Re: Magic SysRq SAK does nothing on serial consoles
- Prev by Date: Re: [PATCH 18/19] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]
- Next by Date: Re: [PATCH 1/2] NOMMU: Set BDI capabilities for /dev/mem and /dev/kmem
- Previous by thread: [PATCH][RFC] exception processing in early boot
- Next by thread: Re: Magic SysRq SAK does nothing on serial consoles
- Index(es):