linux-kernel - Re: [PATCH] x86: update mptable v7

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: <alpine.LFD.1.10.0806191412100.3040@localhost.localdomain>
Date:	Thu, 19 Jun 2008 14:16:36 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Yinghai Lu <yhlu.kernel@...il.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: update mptable v7



NAK on this entire direction.

> >>> >>> > Is this an effort to boot an ACPI-mode kernel,
> >>> >>> > and then kexec a non-ACPI kernel?
> >>> >>>
> >>> >>> Yes,
> >>> >>
> >>> >> Why is this feature needed?
> >>> >> There are a number of ways that the resulting kernel may fail,
> >>> >> all platform specific.
> >>> >
> >>> > other os still doesn't have update acpi irq routing support. but has
> >>> > broken mptable.
> >>>
> >>> Which is at least in part a reason to go back to the BIOS manufacturer
> >>> and get them to fix their table.
> >>
> >> Who says it is broken?
> >
> > In the common case if not in general the MP table and the ACPI
> > version of the same table, provide the same data in slight different
> > formats.
> >
> >>> I can see a warning coming from the kernel if these two tables are
> >> inconsistent
> >>> though.
> >>
> >> Again, there may not *be* an MPS table, and if there is but the
> >> interrupt links are programmable, the MPS table may have very little
> >> in common with the state of the machine in ACPI mode.
> >
> > That I will believe.
> >
> >> I'm sorry, kexec continues to sound like science fiction to me.
> >> I don't understand why scribbling on upstream Linux in the name
> >> of science fiction makes any sense.
> >>
> >> I just don't get it.
> >
> > In the normal kexec case not the kexec on panic (aka kdump) we should
> > have shutdown ACPI on the way down.  So the machine won't be running
> > in ACPI mode.  I assume ACPI supports that.
> >
> > What YH is doing does sound potentially dangerous.  If you can indeed compare
> > the two tables and in fact see they are inconsistent.  That is a good case
> > for printing a warning message.  YH clearly started this because in his
> > testing the MP table was broken and he had an older Enterprise kernel to run
> > that had unusable ACPI support.  That however is a BIOS bug.  Pushing back
> > on BIOS bugs and making them easy to find is always a good deal.  Silently
> > fixing them (not just working around them) seems unprecedented.
> 
> the patch did print out the old and updated mptable.
> 
> and that feature is enabled via "update_mptable" command line.
> 
> 
> also it is useful for kexec from acpi kernel to no acpi kernel on MB
> with nvidia chipset with AMI BIOS.
> becuase irq routing is different from mptable and acpi.
> 
> amd8111/amd8131 chipset with AMI bios has same irq routing from
> mptable and acpi.
> 
> Phonix BIOS, has one setup option APIC/PIC, and if select APIC, then
> irq routing from mptable and acpi is the same with
> nvidia chipset.

So you know this can't NEVER be reliable, yet you continue to push for 
upstream changes that carry risk for all systems that DO work.

Please clue me into the use model that justifies risking a single line of 
Linux code for this effort.

-Len

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