Re: [PATCH 6/7] kdb: Mark safe commands as KDB_SAFE andKDB_SAFE_NO_ARGS

[Anton Vorontsov]

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@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/