[PATCH 0/6] KGDB/KDB FIQ (NMI) debugger

[Colin Cross]

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