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: <CA+55aFxFu9k7xOWd8DqXx8t+PONoV5ijGJv5mshZrYeVsVp32w@mail.gmail.com>
Date:	Sat, 12 Oct 2013 11:05:56 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...nel.org>, Peter Anvin <hpa@...or.com>,
	Avi Kivity <avi@...hat.com>,
	Matthew Garrett <matthew.garrett@...ula.com>,
	Len Brown <len.brown@...el.com>
Cc:	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

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.

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?

The history behind this seems to be that we _used_ to default to
REBOOT_KBD (since that's the traditional method), and fall back to the
triple fault. Then, it was changed to default to ACPI back in 2008 by
Avi Kivity, because those methods apparently could "assert INIT
instead of RESET", and INIT is apparently blocked in Intel VT.  See
commit

But that immediately caused problems, and got reverted by commit
8d00450d296d. But despite the _known_ problems with the ACPI method,
then in 2011 Matthew Garrett defaulted to ACPI again in commit
660e34cebf0a, claiming that that is what Windows does. Which is
clearly NOT TRUE, since I can pretty much guarantee that Windows works
fine on Dell computers.

So Windows clearly does not default to the ACPI reboot model, at least
not unconditionally. There must be something we're missing. I'm
wondering if the way Matthew figured out the Windows defaults was to
run it in a virtual environment? Or uses some other flag to determine
whether the ACPI reboot is reliable or not. Because considering the
known issues with VT, maybe what Windows actually does is to use ACPI
only on VT machines, or something like that.

Because since that whole re-introduction of "default to ACPI", the
majority of patches to the reboot.c file seems to be just "ACPI reboot
doesn't work on this machine, so let's quirk it".

The alternative is that our "acpi_reboot" code is just completely
bogus. If you look at it, it does magic things with
ACPI_ADR_SPACE_PCI_CONFIG: and then calls acpi_reset() if that's not
the case. And the two functions have *inconsistent* validation of the
ACPI registers. acpi_reboot() will happily use a zero address forits
ACPI_ADR_SPACE_PCI_CONFIG poking, for example. And those functions
have gone back and forth on their breakage too (like not checking
ACPI_FADT_RESET_REGISTER which broke things entirely etc etc).

Guys, any ideas/suggestions? Because this constant "let's quirk things
because we're clearly doing something wrong" is wrong.

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