linux-kernel - Re: [GIT PULL] x86 fixes

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: <20131012184920.GA19065@gmail.com>
Date:	Sat, 12 Oct 2013 20:49:20 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	Matthew Garrett <matthew.garrett@...ula.com>,
	Len Brown <len.brown@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86 fixes


* H. Peter Anvin <hpa@...or.com> wrote:

> On 10/12/2013 11:05 AM, Linus Torvalds wrote:
> > On Sat, Oct 12, 2013 at 10:15 AM, Ingo Molnar <mingo@...nel.org> wrote:
> >>
> >> Ville Syrjälä (1):
> >>       x86/reboot: Add reboot quirk for Dell Latitude E5410
> > 
> > So we have a number of these quirks, and Dell seems to be one of the
> > more common factors.

I raised this with hpa when the latest round of Dell quirks were added, 
but I agree that the quirk frequency sucks (for every quirk there's likely 
5 times as many boxes still out there that we haven't applied a quirk for 
yet ...) and I agree that this needs to be discussed more widely.

> > Now, I'd suggest we just trigger it automatically for Dell, but the 
> > thing is, Dell tends to be the *least* differentiating PC maker out 
> > there, so I'm wondering if it is our default reboot order that is just 
> > plain wrong.
> > 
> > We start off trying to reboot using ACPI. Is that really sane? Is 
> > there any reason to not make the default case be to use the PCI 
> > reboot?
> 
> We tried it, it broke too many systems.  However, I'm seriously 
> considering it for the case of Dell specificall.
> 
> The problem with Dell is that they are using something unusual like the 
> KBC to reboot, *and* apparently it is broken when VT-d is enabled.  This 
> may becase the versions of Windows they're testing on aren't using it, 
> or because they "expect" the OS to disable VT-d before shutdown.

If Windows doesn't use and enable VT-d then we probably should not use it 
either, or we should _at minimum_ disable VT-d again when we shut down.

I.e. if possible we should leave the hardware roughly in the state we got 
it from the firmware, that leads probably to the least amount of 
surprises.

So I'd be tempted to just not use IRQ remapping until this is cleared up 
and fixed properly. I.e. don't quirk the reboot method, quirk VT-d ...

Thanks,

	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/