linux-kernel - Re: [PATCH] apci: dump slit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080914122618.GD16097@elte.hu>
Date:	Sun, 14 Sep 2008 14:26:18 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pavel Machek <pavel@...e.cz>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Andi Kleen <andi@...stfloor.org>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>, hpa@...or.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] apci: dump slit

* Pavel Machek <pavel@...e.cz> wrote:

> On Fri 2008-09-12 23:19:21, Thomas Gleixner wrote:
> > On Fri, 12 Sep 2008, Andi Kleen wrote:
> > > "Yinghai Lu" <yhlu.kernel@...il.com> writes:
> > > >
> > > > to see how wrong could be set by BIOS.
> > > 
> > > Just dump it from user space then.  There are plenty of tools
> > > to access ACPI tables.
> > 
> > 1.) what guarantees that we reach user space ?
> 
> We can dump in *any* kernel.
>
> > 2) If it is _valuable_ information which we can gather via kernel
> >    output, then it is much more conveniant than asking the user to type
> >    whatevercryptictoolcommandline and provide the output.
> 
> Ooh, 'lets dump more junk at everyone, typing commands is hard' :-(.

no, the principle is, information like the boot-time CPUID information 
(and even the BIOS environment) can be indicative of _kernel bugs_. It 
is often essential to dump what the booting (and failing) kernel thinks 
is its environment.

Often that environment is corrupted (by the kernel) and that leads to 
problems. This 'environment' can also be affected by things like hard 
boot vs cold boot differences, whether it's in a kexec environment, 
whether it's booted as a virtual guest, etc., etc.

For a long time we had the kernel's x86 bootup pretty much as a mostly 
silent black box and when it broke we tried to figure things out 
afterwards which was difficult and error-prone. Now we've got various 
quite effective debug mechanisms (which includes printouts as well) and 
figuring out x86 problems is visibly easier. We definitely wont go back 
to the 'black box code, can only be debugged by a few experts' method.

So extending on that is a good and obvious idea in general - and i agree 
with Peter that this should be command-line dependent, i.e. not printed 
by default. Only printing it when 'debug' is specified on the command 
line is a good solution.

	Ingo
--
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/