From mboxrd@z Thu Jan 1 00:00:00 1970 From: ccross@android.com (Colin Cross) Date: Fri, 13 Jul 2012 09:43:45 -0700 Subject: [PATCH 0/6] KGDB/KDB FIQ (NMI) debugger In-Reply-To: <20120713094954.GA12917@lizard> References: <20120705231034.GA16931@lizard> <20120713094954.GA12917@lizard> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Jul 13, 2012 at 2:49 AM, Anton Vorontsov wrote: > On Thu, Jul 05, 2012 at 05:02:12PM -0700, Colin Cross wrote: > [...] >> KGDB can obviously only be enabled on development >> devices, although perhaps a more limited KDB could be left enabled. > > Um, I would argue about 'obviously'. :-) It doesn't require > CONFIG_DEBUG_INFO (-g) or something like this, so if the concern is > the size (which is about 30..40 KB), then it is all manageable. If we > want it to be smaller, we should just work on making KGDB/KDB more > modular, so that we can exclude non-production features. I was referring to the security implications, not size. Leaving KDB on is effectively instant root access over the serial console. > > This might look as a drastic change, but it is not. There is actually >> > no difference whether you have sync or async shell, or at least I >> > couldn't find any use-case where this would matter at all. Anyways, >> > it is still possible to do async shell in KDB, just don't see any >> > need for this. >> >> I think it could be an issue if KDB stopped execution whenever it >> received any character. Serial ports are often noisy, especially when >> muxed over another port (we often use serial over the headset >> connector). Noise on the async command line just causes characters >> that are ignored, on a command line that blocked execution noise would >> be catastrophic. > > Aha, that's the real use-case, thanks! I started hacking the KDB > to add the async shell support, but then I realized that we still > don't need all the complexity. If the only purpose is to be safe from > the noise, then we can just do "knocking" before entering the debugger. > > The thing is, we even have a standard sequence for entering KDB, > it is GDB-protocol command $3#33, so it actually makes sense to > implement this. This would be the only async command, and it doesn't > affect anything but the new code. I prepared a separate patch for this. I would suggest making the sequence longer than just return. A single character is not that unlikely to be generated by random noise - I've seen multiple devices reboot when the serial console was connected because it received a SysRq-Crash (a break is all zeroes, which is very common while shorting the lines as the console is plugged in, and then random noise sent a 'c').