On Fri, Jul 13, 2012 at 2:49 AM, Anton Vorontsov <anton.voront...@linaro.org> 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. <snip >> > 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'). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/