[PATCH 0/6] KGDB/KDB FIQ (NMI) debugger
ccross at android.com
Fri Jul 13 12:43:45 EDT 2012
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.
>> > 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').
More information about the linux-arm-kernel