Possible bug in arch/i386/kernel/process.c for reloading of debug registers (DRx)?

Possible bug in arch/i386/kernel/process.c for reloading of debug registers (DRx)?

[Kevin Lawton]

I was scanning through the source and noticed the lines below.
Should the code below, be reloading at least the local bits of
DR7 if the current DR7 value != 0?  From a quick glance, it
looks like only if the next task's DR7 value is non-zero,
that DR7 is reloaded.  I'm wondering if this would leave
a new task to receive "local" debug events for the previous
task if prev->DR7!=0 && next->DR7==0.

-Kevin


linux-2.5.59: arch/i386/kernel/process.c: line 462+:

  /*
   * Now maybe reload the debug registers
   */
  if (unlikely(next->debugreg[7])) {
    loaddebug(next, 0);
    loaddebug(next, 1);
    loaddebug(next, 2);
    loaddebug(next, 3);
    /* no 4 and 5 */
    loaddebug(next, 6);
    loaddebug(next, 7);
  }

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: Possible bug in arch/i386/kernel/process.c for reloading of debug registers (DRx)?

[Andi Kleen]

> 	- However, DR6 bit B0 is now set.

You cannot detect it. Linux offers no way to read DR6 from user space
as far as I can see. The only way to handle break points is to catch
the signals caused by the debug exceptions.

Yo access debug registers you need to use ptrace from another process.
ptrace only ever returns cached values in tsk->thread, but the register is 
never stored in there.

So in fact __switch_to could drop the loaddebug(next, 6) because it is 
useless.

-Andi

Re: Possible bug in arch/i386/kernel/process.c for reloading of debug registers (DRx)?

[Jamie Lokier]

Andi Kleen wrote:
> > What if DRx contains sensitive data? ...Its probably pretty
> > unlikely. Still it allows for example easy communication between tasks
> > that should not be able to communicate.
> 
> The user never sees the stale value, it is eaten by the kernel's do_debug
> handler.

DR6 isn't cleared.  Here is a nice security exploit for you:

	- Task A sets DR0 and DR7 to enable a watchpoint (or breakpoint).
	- It also clears DR6.
	- Task A wakes up task B, which has DR7 clear.
	- Task A then communicates with "sshd" or some other sensitive task.

	- Because of lazy DR7 clearing, sshd inherits the watchpoints.
	- If sshd reads the memory address mentioned in DR0, it will
	  call do_debug in the kernel, which clears DR7 and continues.
	- However, DR6 bit B0 is now set.

	- Eventually task B is scheduled.  It inherits the value of DR6
	  from sshd, and therefore knows if sshd read from a particular
	  memory location.

	- Task A and task B cooperate to analyse what values sshd is
	  examining in its lookup tables, and therefore retrieve the
	  server key or something.  (Hand waving at this point).

-- Jamie

Re: Possible bug in arch/i386/kernel/process.c for reloading of debug registers (DRx)?

[Andi Kleen]

> What if DRx contains sensitive data? ...Its probably pretty
> unlikely. Still it allows for example easy communication between tasks
> that should not be able to communicate.

The user never sees the stale value, it is eaten by the kernel's do_debug
handler.

-Andi

Re: Possible bug in arch/i386/kernel/process.c for reloading of debug registers (DRx)?

[Pavel Machek]

Hi!

> > I was scanning through the source and noticed the lines below.
> > Should the code below, be reloading at least the local bits of
> > DR7 if the current DR7 value != 0?  From a quick glance, it
> > looks like only if the next task's DR7 value is non-zero,
> > that DR7 is reloaded.  I'm wondering if this would leave
> > a new task to receive "local" debug events for the previous
> > task if prev->DR7!=0 && next->DR7==0.
> 
> The do_debug trap handler handles that. It checks that
> the debug event is set in the current process before doing anything
> and if they weren't they are clared.
> 
> So yes they leak, but only once and the user should never notice.

What if DRx contains sensitive data? ...Its probably pretty
unlikely. Still it allows for example easy communication between tasks
that should not be able to communicate.

								Pavel

-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: Possible bug in arch/i386/kernel/process.c for reloading of debug registers (DRx)?

[Andi Kleen]

Kevin Lawton <kevinlawton2001@yahoo.com> writes:

> I was scanning through the source and noticed the lines below.
> Should the code below, be reloading at least the local bits of
> DR7 if the current DR7 value != 0?  From a quick glance, it
> looks like only if the next task's DR7 value is non-zero,
> that DR7 is reloaded.  I'm wondering if this would leave
> a new task to receive "local" debug events for the previous
> task if prev->DR7!=0 && next->DR7==0.

The do_debug trap handler handles that. It checks that
the debug event is set in the current process before doing anything
and if they weren't they are clared.

So yes they leak, but only once and the user should never notice.

-Andi