[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMbhsRSM3QwwVfUMBWq1bDJxHX+Ox2CQtbvJVmemuMWjxfmDoQ@mail.gmail.com>
Date: Fri, 27 Jul 2012 12:30:49 -0700
From: Colin Cross <ccross@...gle.com>
To: Anton Vorontsov <anton.vorontsov@...aro.org>
Cc: Jason Wessel <jason.wessel@...driver.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Steven Rostedt <rostedt@...dmis.org>,
John Stultz <john.stultz@...aro.org>, arve@...roid.com,
linux-kernel@...r.kernel.org, linaro-kernel@...ts.linaro.org,
patches@...aro.org, kernel-team@...roid.com,
kgdb-bugreport@...ts.sourceforge.net
Subject: Re: [PATCH 0/7] KDB: Kiosk (reduced capabilities) mode
On Thu, Jul 26, 2012 at 7:25 AM, Anton Vorontsov
<anton.vorontsov@...aro.org> wrote:
> Hi all,
>
> Here is a patchset that implements "kiosk" mode for KDB debugger. The
> mode provides reduced set of features, so that it is no longer possible
> to leak sensitive data via the debugger, and not possible to change
> program flow in a predefined manner.
>
> The are two use-cases for the mode, one is evil, but another is quite
> legitimate.
>
> The evil use case is used by some (ahem) phone manufaturers that want
> to have a debuging facilities on a production device, but still don't
> want you to use the debugger to gain root access. I don't like locked
> phones, and I would not touch this/get my hands dirty by implementing
> the feature just for this evil (IMHO) use case.
The point of the reduced feature set in FIQ debugger is not to prevent
you from accessing your own phone, it designed to prevent others from
trivially rooting your phone and reading your data. Both locked and
unlocked phones run FIQ debugger. Would you carry a phone with
personal data on it and KGDB enabled on the serial console?
An alternate option would be to allow userspace to write a password
hash to a sysfs file, and require the password to be entered over the
serial console to unlock KGDB or enable unsafe KGDB commands.
> But there is another non-evil use case: limitting access to public
> devices, i.e. "kiosks", ATMs (is that too much?) or just public
> computers w/ guest access. I can imagine that an administrator would
> want to setup a kernel so that upon an oops (or a sysrq event) the
> kernel would enter KDB, but at the same time, he would not want to
> leak sensitive data from the PC by means of the debugger.
>
> There are seven patches, the first five of them are just cleanups and
> preparations. I believe these five patches are good even if not
> considering the kiosk mode. And the rest of patches actually implement
> the mode -- it is pretty straightforward.
>
> Note that we might impelement the same mode for KGDB stub, but so far
> we don't bother.
>
> Thanks!
>
> --
> include/linux/kdb.h | 16 ++--
> kernel/debug/kdb/kdb_bp.c | 35 ++++----
> kernel/debug/kdb/kdb_main.c | 183 +++++++++++++++++++++-------------------
> kernel/debug/kdb/kdb_private.h | 3 +-
> kernel/trace/trace_kdb.c | 4 +-
> 5 files changed, 126 insertions(+), 115 deletions(-)
>
> --
> Anton Vorontsov
> Email: cbouatmailru@...il.com
> --
> 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/
--
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/
Powered by blists - more mailing lists