From: Anton Vorontsov <anton.vorontsov@linaro.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jason Wessel <jason.wessel@windriver.com>,
Andrew Morton <akpm@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
John Stultz <john.stultz@linaro.org>,
arve@android.com, linux-kernel@vger.kernel.org,
linaro-kernel@lists.linaro.org, patches@linaro.org,
kernel-team@android.com, kgdb-bugreport@lists.sourceforge.net
Subject: Re: [PATCH 6/7] kdb: Mark safe commands as KDB_SAFE and KDB_SAFE_NO_ARGS
Date: Thu, 26 Jul 2012 10:39:02 -0700 [thread overview]
Message-ID: <20120726173902.GA20023@lizard> (raw)
In-Reply-To: <20120726180709.09777a3b@pyramind.ukuu.org.uk>
On Thu, Jul 26, 2012 at 06:07:09PM +0100, Alan Cox wrote:
> > The following commands were marked as "safe":
> >
> > Clear Breakpoint
> > Enable Breakpoint
> > Disable Breakpoint
> > Display exception frame
> > Stack traceback
>
> This is sufficient to steal cryptographic keys in many environments. In
> fact you merely need two or three breakpoints and to log the order they
> are hit through the crypto computation.
Neat. :-)
Breakpoints are no good then.
> > Display stack for process
>
> Exposes all sorts of user data unless you mean just the call trace, in
> which case it's still quite useful.
>
> > Display stack all processes
>
> Ditto
What I think is, should we just mark single stepping (as well as
breakpoints) as unsafe, then it's hard to impossible to use the call
trace as something meaningful?
> > Send a signal to a process
>
> Like say sending SIGSTOP to security monitoring threads or the battery
> manager on locked devices that rely on software battery management ?
Yeah, will need to zap it too.
> It's an interesting idea but you need almost nothing to extract keys from
> a system or to subvert it.
Apart from the above issues?
(Now it might seem that we cut almost everything from the KDB, but KDB is
not just about ordinary debugging facilities, like breakpoints or
variables watch. KDB is a shell that also implements commands to query
kernel about its state: e.g. in Android case there is "irqs" commands that
just shows interrupts counters, that is a nice feature if used w/ KDB
NMI/FIQ debugger[1], so you can see which interrupt is misbehaving.
There is also a 'dmesg' command, and 'summary' and maybe others.)
Thanks!
[1] http://lwn.net/Articles/506673/
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
next prev parent reply other threads:[~2012-07-26 17:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-26 14:25 [PATCH 0/7] KDB: Kiosk (reduced capabilities) mode Anton Vorontsov
2012-07-26 14:26 ` [PATCH 1/7] kdb: Remove currently unused kdbtab_t->cmd_flags Anton Vorontsov
2012-07-26 14:26 ` [PATCH 2/7] kdb: Rename kdb_repeat_t to kdb_cmdflags_t, cmd_repeat to cmd_flags Anton Vorontsov
2012-07-26 14:26 ` [PATCH 3/7] kdb: Rename kdb_register_repeat() to kdb_register_flags() Anton Vorontsov
2012-07-26 14:26 ` [PATCH 4/7] kdb: Use KDB_REPEAT_* values as flags Anton Vorontsov
2012-07-26 14:26 ` [PATCH 5/7] kdb: Remove KDB_REPEAT_NONE flag Anton Vorontsov
2012-07-26 14:26 ` [PATCH 6/7] kdb: Mark safe commands as KDB_SAFE and KDB_SAFE_NO_ARGS Anton Vorontsov
2012-07-26 17:07 ` Alan Cox
2012-07-26 17:39 ` Anton Vorontsov [this message]
2012-07-30 12:04 ` [PATCH v2 " Anton Vorontsov
2012-07-26 14:26 ` [PATCH 7/7] kdb: Add kiosk mode Anton Vorontsov
2012-07-27 19:30 ` [PATCH 0/7] KDB: Kiosk (reduced capabilities) mode Colin Cross
2012-07-28 1:26 ` Anton Vorontsov
2012-07-28 1:49 ` John Stultz
2012-07-28 1:53 ` Colin Cross
-- strict thread matches above, loose matches on Subject: below --
2012-10-16 1:17 Anton Vorontsov
2012-10-16 1:18 ` [PATCH 6/7] kdb: Mark safe commands as KDB_SAFE and KDB_SAFE_NO_ARGS Anton Vorontsov
2012-11-23 0:53 [PATCH resend 0/7] KDB: Kiosk (reduced capabilities) mode Anton Vorontsov
2012-11-23 0:53 ` [PATCH 6/7] kdb: Mark safe commands as KDB_SAFE and KDB_SAFE_NO_ARGS Anton Vorontsov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120726173902.GA20023@lizard \
--to=anton.vorontsov@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arve@android.com \
--cc=jason.wessel@windriver.com \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@linaro.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox