Re: [PATCH] lockdep: disable lock debugging when kernel state becomes untrusted

Re: [PATCH] lockdep: disable lock debugging when kernel state becomes untrusted

[Voluspa]

On 2006-07-10 21:02:59 git-commits-head received:
> commit 2c16e9c888985761511bd1905b00fb271169c3c0
> tree e17756b3ed27b0f4953547c39cf46864cdd6f818
> parent e54695a59c278b9ff48cd4b263da7a1d392f5061
> author Arjan van de Ven Mon, 10 Jul 2006
> 18:45:42 -0700 committer Linus Torvalds Tue, 11
> Jul 2006 03:24:27 -0700
>
> [PATCH] lockdep: disable lock debugging when kernel state becomes
> untrusted
>
> Disable lockdep debugging in two situations where the integrity of the
> kernel no longer is guaranteed: when oopsing and when hitting a
> tainting-condition.  The goal is to not get weird lockdep traces that
> don't make sense or are otherwise undebuggable, to not waste time.
>
> Lockdep assumes that the previous state it knows about is valid to
> operate, which is why lockdep turns itself off after the first
> violation it reports, after that point it can no longer make that
> assumption.
>
> A kernel oops means that the integrity of the kernel compromised; in
> addition anything lockdep would report is of lesser importance than the
> oops.
>
> All the tainting conditions are of similar integrity-violating nature
> and also make debugging/diagnosing more difficult.

On my x86_64 notebook I need ndiswrapper. No but-s, if-s or anything-s.
Period. I also have to work outside of X in a clean terminal (console).

This patch unfortunately creates a 'pipe' directly from
 /var/log/messages to the screen. So if I work in a textbased program,
and something happens in the log, the program gets a broken interface.
Programs that simultaniously output to the log becomes unusable.

It is also darn irritating when text strings materializes at the shell
prompt...

Once the 'pipe' is established (by tainting) it can not be reverted by
eg rmmod ndiswrapper.

I haven't even enabled any lockdep debugging:

loke:sleipner:/usr/src/testing$ grep -i debug 2.6.18-rc4-.config 
# CONFIG_PM_DEBUG is not set
# CONFIG_ACPI_DEBUG is not set
# CONFIG_CPU_FREQ_DEBUG is not set
# CONFIG_PCMCIA_DEBUG is not set
# CONFIG_NETDEBUG is not set
# CONFIG_IRDA_DEBUG is not set
# CONFIG_PNP_DEBUG is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_DETECT is not set
# CONFIG_SND_PCM_XRUN_DEBUG is not set
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_MMC_DEBUG is not set
# CONFIG_JBD_DEBUG is not set
# CONFIG_NTFS_DEBUG is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_DEBUG_FS is not set

And there is no interface to disable the lockdep:

loke:sleipner:/usr/src/testing$ grep -i lockdep 2.6.18-rc4-.config 
CONFIG_LOCKDEP_SUPPORT=y

So, reverting the offending patch is the only way to sanity. A direct
link (instead of my mangled quoting):

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=2c16e9c888985761511bd1905b00fb271169c3c0;hp=e54695a59c278b9ff48cd4b263da7a1d392f5061

> Signed-off-by: Arjan van de Ven
> Signed-off-by: Ingo Molnar
> Signed-off-by: Andrew Morton
> Signed-off-by: Linus Torvalds
>
> kernel/panic.c |    2 ++
> 1 files changed, 2 insertions(+)

> diff --git a/kernel/panic.c b/kernel/panic.c
> index ab13f0f..d8a0bca 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -172,6 +172,7 @@ const char *print_tainted(void)
> 
> void add_taint(unsigned flag)
> {
> +	debug_locks_off(); /* can't trust the integrity of the kernel
> anymore */ tainted |= flag;
> }
> EXPORT_SYMBOL(add_taint);
> @@ -256,6 +257,7 @@ int oops_may_print(void)
>  */
> void oops_enter(void)
> {
> +	debug_locks_off(); /* can't trust the integrity of the kernel
> anymore */ do_oops_enter_exit();
> }

Mvh
Mats Johannesson
 

Re: [PATCH] lockdep: disable lock debugging when kernel state becomes untrusted

[Andrew Morton]

On Mon, 14 Aug 2006 03:09:54 +0200
Voluspa <lista1@comhem.se> wrote:

> On 2006-07-10 21:02:59 git-commits-head received:
> > commit 2c16e9c888985761511bd1905b00fb271169c3c0
> > tree e17756b3ed27b0f4953547c39cf46864cdd6f818
> > parent e54695a59c278b9ff48cd4b263da7a1d392f5061
> > author Arjan van de Ven Mon, 10 Jul 2006
> > 18:45:42 -0700 committer Linus Torvalds Tue, 11
> > Jul 2006 03:24:27 -0700
> >
> > [PATCH] lockdep: disable lock debugging when kernel state becomes
> > untrusted
> >
> > Disable lockdep debugging in two situations where the integrity of the
> > kernel no longer is guaranteed: when oopsing and when hitting a
> > tainting-condition.  The goal is to not get weird lockdep traces that
> > don't make sense or are otherwise undebuggable, to not waste time.
> >
> > Lockdep assumes that the previous state it knows about is valid to
> > operate, which is why lockdep turns itself off after the first
> > violation it reports, after that point it can no longer make that
> > assumption.
> >
> > A kernel oops means that the integrity of the kernel compromised; in
> > addition anything lockdep would report is of lesser importance than the
> > oops.
> >
> > All the tainting conditions are of similar integrity-violating nature
> > and also make debugging/diagnosing more difficult.
> 
> On my x86_64 notebook I need ndiswrapper. No but-s, if-s or anything-s.
> Period. I also have to work outside of X in a clean terminal (console).
> 
> This patch unfortunately creates a 'pipe' directly from
>  /var/log/messages to the screen. So if I work in a textbased program,
> and something happens in the log, the program gets a broken interface.
> Programs that simultaniously output to the log becomes unusable.
> 
> It is also darn irritating when text strings materializes at the shell
> prompt...
> 
> Once the 'pipe' is established (by tainting) it can not be reverted by
> eg rmmod ndiswrapper.
> 
> I haven't even enabled any lockdep debugging:

That would appear to be a bug.  debug_locks_off() is running
console_verbose() waaaay after the locking selftest code has completed.

Re: [PATCH] lockdep: disable lock debugging when kernel state becomes untrusted

[Voluspa]

On Sun, 13 Aug 2006 18:41:59 -0700 Andrew Morton wrote:
> On Mon, 14 Aug 2006 03:09:54 +0200
> Voluspa wrote:
> 
> > On 2006-07-10 21:02:59 git-commits-head received:
> > > commit 2c16e9c888985761511bd1905b00fb271169c3c0
> > > tree e17756b3ed27b0f4953547c39cf46864cdd6f818
> > > parent e54695a59c278b9ff48cd4b263da7a1d392f5061
> > > author Arjan van de Ven Mon, 10 Jul 2006
> > > 18:45:42 -0700 committer Linus Torvalds Tue, 11
> > > Jul 2006 03:24:27 -0700
> > >
> > > [PATCH] lockdep: disable lock debugging when kernel state becomes
> > > untrusted
> > >
> > > Disable lockdep debugging in two situations where the integrity
> > > of the kernel no longer is guaranteed: when oopsing and when
> > > hitting a tainting-condition.  The goal is to not get weird
> > > lockdep traces that don't make sense or are otherwise
> > > undebuggable, to not waste time.
> > >
> > > Lockdep assumes that the previous state it knows about is valid to
> > > operate, which is why lockdep turns itself off after the first
> > > violation it reports, after that point it can no longer make that
> > > assumption.
> > >
> > > A kernel oops means that the integrity of the kernel compromised;
> > > in addition anything lockdep would report is of lesser importance
> > > than the oops.
> > >
> > > All the tainting conditions are of similar integrity-violating
> > > nature and also make debugging/diagnosing more difficult.
> > 
> > On my x86_64 notebook I need ndiswrapper. No but-s, if-s or
> > anything-s. Period. I also have to work outside of X in a clean
> > terminal (console).
> > 
> > This patch unfortunately creates a 'pipe' directly from
> >  /var/log/messages to the screen. So if I work in a textbased
> > program, and something happens in the log, the program gets a
> > broken interface. Programs that simultaniously output to the log
> > becomes unusable.
> > 
> > It is also darn irritating when text strings materializes at the
> > shell prompt...
> > 
> > Once the 'pipe' is established (by tainting) it can not be reverted
> > by eg rmmod ndiswrapper.
> > 
> > I haven't even enabled any lockdep debugging:
> 
> That would appear to be a bug.  debug_locks_off() is running
> console_verbose() waaaay after the locking selftest code has
> completed.

The possibly final -rc6 is likewise broken. What would it take to incur
some respect for us, the millions of users effected by this shit?
Should we all become quasi-developers and bombard lkml with patches
that taint the kernel whenever some of the Intel binary blobs are
loaded?

Would that cluebat Arjan off of his high horse?

Mvh
Mats Johannesson

Re: [PATCH] lockdep: disable lock debugging when kernel state becomes untrusted

[Andrew Morton]

On Tue, 5 Sep 2006 08:40:42 +0200
Voluspa <lista1@comhem.se> wrote:

> > That would appear to be a bug.  debug_locks_off() is running
> > console_verbose() waaaay after the locking selftest code has
> > completed.
> 
> The possibly final -rc6 is likewise broken. What would it take to incur
> some respect for us, the millions of users effected by this shit?
> Should we all become quasi-developers and bombard lkml with patches
> that taint the kernel whenever some of the Intel binary blobs are
> loaded?
> 
> Would that cluebat Arjan off of his high horse?

Thanks for the reminder ;)

Arjan, what's that console_verbose() doing in debug_locks_off()?  Whatever
it is, can we fix it?  Presumably the previous loglevel needs to be
readopted somehow, or we just take it out of there.

Re: [PATCH] lockdep: disable lock debugging when kernel state becomes untrusted

[Arjan van de Ven]

Andrew Morton wrote:
> On Tue, 5 Sep 2006 08:40:42 +0200
> Voluspa <lista1@comhem.se> wrote:
> 
>>> That would appear to be a bug.  debug_locks_off() is running
>>> console_verbose() waaaay after the locking selftest code has
>>> completed.
>> The possibly final -rc6 is likewise broken. What would it take to incur
>> some respect for us, the millions of users effected by this shit?
>> Should we all become quasi-developers and bombard lkml with patches
>> that taint the kernel whenever some of the Intel binary blobs are
>> loaded?

don't use those btw, they're ancient and unneeded/superceded since ages.

>>
>> Would that cluebat Arjan off of his high horse?
> 
> Thanks for the reminder ;)
> 
> Arjan, what's that console_verbose() doing in debug_locks_off()?  Whatever
> it is, can we fix it?  Presumably the previous loglevel needs to be
> readopted somehow, or we just take it out of there.

I'd say take them out of there; I don't know why they're there in the first place.. Ingo ?

Re: [PATCH] lockdep: disable lock debugging when kernel state becomes untrusted

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> That would appear to be a bug.  debug_locks_off() is running 
> console_verbose() waaaay after the locking selftest code has 
> completed.

debug_locks_off() should only be used when a real bug is being displayed 
- which isnt the case when we call add_taint(). The patch below should 
fix this.

	Ingo

---------------->
Subject: lockdep: do not touch console state when tainting the kernel
From: Ingo Molnar <mingo@elte.hu>

Remove an unintended console_verbose() side-effect from add_taint().

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/panic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/kernel/panic.c
===================================================================
--- linux.orig/kernel/panic.c
+++ linux/kernel/panic.c
@@ -173,7 +173,7 @@ const char *print_tainted(void)
 
 void add_taint(unsigned flag)
 {
-	debug_locks_off(); /* can't trust the integrity of the kernel anymore */
+	debug_locks = 0; /* can't trust the integrity of the kernel anymore */
 	tainted |= flag;
 }
 EXPORT_SYMBOL(add_taint);

Re: [PATCH] lockdep: disable lock debugging when kernel state becomes untrusted

[Voluspa]

On Tue, 5 Sep 2006 09:15:01 +0200 Ingo Molnar wrote:
> 
> * Andrew Morton wrote:
> 
> > That would appear to be a bug.  debug_locks_off() is running 
> > console_verbose() waaaay after the locking selftest code has 
> > completed.
> 
> debug_locks_off() should only be used when a real bug is being
> displayed 
> - which isnt the case when we call add_taint(). The patch below
> should fix this.

Thanks, it works as advertised.

Mvh
Mats Johannesson