linux-kernel - RE: Options depending on STANDALONE

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: <1154972011.4302.712.camel@queen.suse.de>
Date:	Mon, 07 Aug 2006 19:33:31 +0200
From:	Thomas Renninger <trenn@...e.de>
To:	"Brown, Len" <len.brown@...el.com>
Cc:	Greg KH <greg@...ah.com>, Adrian Bunk <bunk@...sta.de>,
	Dave Jones <davej@...hat.com>,
	Zachary Amsden <zach@...are.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>,
	Christoph Hellwig <hch@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jack Lo <jlo@...are.com>, v4l-dvb-maintainer@...uxtv.org,
	linux-acpi@...r.kernel.org
Subject: RE: Options depending on STANDALONE

On Thu, 2006-08-03 at 16:49 -0400, Brown, Len wrote:
> >On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
> >> ACPI_CUSTOM_DSDT seems to be the most interesting case.
> >> It's anyway not usable for distribution kernels, and AFAIR the ACPI 
> >> people prefer to get the kernel working with all original DSDTs
> >> (which usually work with at least one other OS) than letting 
> >> the people workaround the problem by using a custom DSDT.
> >
> >Not true at all.  For SuSE kernels, we have a patch that lets people
> >load a new DSDT from initramfs due to broken machines requiring a
> >replacement in order to work properly.
> 
> CONFIG_ACPI_CUSTOM_DSDT allows hackers to debug their system
> by building a modified DSDT into the kernel to over-ride what
> came with the system.  It would make no sense for a distro
> to use it, unless the distro were shipping only on 1 model machine.
> This technique is necessary for debugging, but makes no
> sense for production.
> 
> The initramfs method shipped by SuSE is more flexible, allowing
> the hacker to stick the DSDT image in the initrd and use it
> without re-compiling the kernel.
> 
> I have refused to accept the initrd patch into Linux many times,
> and always will.
> 
> I've advised SuSE many times that they should not be shipping it,
> as it means that their supported OS is running on modified firmware --
> which, by definition, they can not support.  
Tainting the kernel if done so should be sufficient.
> Indeed, one could view
> this method as couter-productive to the evolution of Linux --
> since it is our stated goal to run on the same machines that Windows
> runs on -- without requiring customers to modify those machines
> to run Linux.

There are three reasons for the initrd patch (last one also applies for
the compile in functionality):

1)
There might be "BIOS bugs" that will never get fixed:
https://bugzilla.novell.com/show_bug.cgi?id=160671
(Because it's an obvious BIOS bug, "compatibility" fixing it could make
things worse).

2)
There might be "ACPICA/kernel bugs" that take a while until they get
fixed:

This happens often. There comes out a new machine, using AML in a
slightly other way, we need to fix it in kernel/ACPICA. Until the patch
appears mainline may take a month or two. Until the distro of your
choice that makes use of the fix comes out might take half a year or
more...
And backporting ACPICA fixes to older kernels is currently not possible
as ACPICA patches appear in a big bunch of some thousand lines patches.
But this hopefully changes soon.

In my mind come:
- alias broken in certain cases
   https://bugziall.novell.com/show_bug.cgi?id=113099
- recon amount of elements in packages
   https://bugzilla.novell.com/show_bug.cgi?id=189488
- wrong offsets at Field and Operation Region declarations
   -> should be compatible for quite a while now
- ...

3)
Debugging.
This is why at least compile in or via initrd must be provided in
mainline kernel IMHO. Intel people themselves ask the bug reporter to
override ACPI tables with a patched table to debug the system.
Do you really think ripping out all overriding functionality from the
kernel is a good idea?

     Thomas

It is true that some users are happy with a fixed DSDT, even you tell
them to find the root cause..., but sooner or later they always come
back.

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