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]
Date:	Fri, 2 May 2008 09:44:32 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Matt Domsch <Matt_Domsch@...l.com>
Cc:	akpm@...ux-foundation.org, jgarzik@...ox.com, muli@...ibm.com,
	davej@...hat.com, tglx@...utronix.de, mingo@...hat.com,
	hpa@...or.com, bunk@...nel.org, linux-bugs@...l.com,
	linux-kernel@...r.kernel.org, greg@...ah.com,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [PATCH] fix x86 DMI checks for PCI quirks


* Matt Domsch <Matt_Domsch@...l.com> wrote:

> fix x86 DMI checks for PCI quirks
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=10583
> https://bugzilla.redhat.com/show_bug.cgi?id=444791
> 
> Since git commit 08f1c192c3c32797068bfe97738babb3295bbf42 (between 
> kernels 2.6.22 and 2.6.23), arch/x86/pci/acpi.c has not called 
> pcibios_scan_root(), which would have called 
> arch/x86/pci/common.c:dmi_check_system().  This has prevented the 
> quirks listed in pciprobe_dmi_table[] from being checked and 
> appropriate action taken.

ugh ...

> This manifests itself in several Dell and HP servers not automatically 
> having the pci=bfsort option be applied, as well as Samsung X20 and 
> Compaq EVO N800c systems needing pci=assign-all-busses was no longer 
> automatically applied.
> 
> This patch moves the DMI tests into its own file, arch/x86/pci/dmi.c, 
> and invokes them via subsys_initcall() before pci_acpi_init(), 
> pci_legacy_init(), and pcibios_init() are called, which may rely upon 
> these tests having been executed.

Jesse Barnes (new PCI maintainer) Cc:-ed.

i'm wondering how we could avoid such mishaps in the future. This was 
broken from 2.6.23 through 2.6.25 - way too long. Perhaps we should 
create a known signature of the device tree in user-space, and somehow 
warn if the kernel changes it? Could this somehow be put into the 
kernel?

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ