linux-kernel - Re: [PATCH 0/6] KGDB/KDB FIQ (NMI) debugger

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMbhsRR6AU2MhX9MO1tV7-Py=sM7jOQdbFP-_WeBhsCL3wGS0A@mail.gmail.com>
Date:	Fri, 13 Jul 2012 09:43:45 -0700
From:	Colin Cross <ccross@...roid.com>
To:	Anton Vorontsov <anton.vorontsov@...aro.org>
Cc:	Russell King <linux@....linux.org.uk>,
	Jason Wessel <jason.wessel@...driver.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	John Stultz <john.stultz@...aro.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linaro-kernel@...ts.linaro.org, patches@...aro.org,
	kernel-team@...roid.com, kgdb-bugreport@...ts.sourceforge.net
Subject: Re: [PATCH 0/6] KGDB/KDB FIQ (NMI) debugger

On Fri, Jul 13, 2012 at 2:49 AM, Anton Vorontsov
<anton.vorontsov@...aro.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/