On Fri, Jul 13, 2012 at 2:49 AM, Anton Vorontsov anton.vorontsov@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').