linux-kernel - Re: [tip:x86/urgent] [PATCH] x86: Try the BIOS reboot method before the PCI reboot method

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: <20140414112714.GC4050@gmail.com>
Date:	Mon, 14 Apr 2014 13:27:14 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	hpa@...or.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, mjg59@...f.ucam.org,
	aubrey.li@...ux.intel.com, rostedt@...dmis.org, tglx@...utronix.de,
	Borislav Petkov <bp@...en8.de>
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] [PATCH] x86: Try the BIOS reboot method before
 the PCI reboot method


* tip-bot for Ingo Molnar <tipbot@...or.com> wrote:

> Commit-ID:  f042310bf8a846bcf21012ffee78d9eb562a7fa4
> Gitweb:     http://git.kernel.org/tip/f042310bf8a846bcf21012ffee78d9eb562a7fa4
> Author:     Ingo Molnar <mingo@...nel.org>
> AuthorDate: Fri, 4 Apr 2014 08:41:26 +0200
> Committer:  Ingo Molnar <mingo@...nel.org>
> CommitDate: Mon, 14 Apr 2014 13:13:30 +0200
> 
> [PATCH] x86: Try the BIOS reboot method before the PCI reboot method
> 
> Steve reported a reboot hang and bisected it back to this commit:
> 
>   a4f1987e4c54 x86, reboot: Add EFI and CF9 reboot methods into the default list
> 
> He heroically tested all reboot methods and found the following:
> 
>   reboot=t       # triple fault                  ok
>   reboot=k       # keyboard ctrl                 FAIL
>   reboot=b       # BIOS                          ok
>   reboot=a       # ACPI                          FAIL
>   reboot=e       # EFI                           FAIL   [system has no EFI]
>   reboot=p       # PCI 0xcf9                     FAIL
> 
> And I think it's pretty obvious that we should only try 0xcf9 as a
> last resort - if at all.
> 
> The other observation is that (on this box) we should never try
> the PCI reboot method, but close with either the 'triple fault'
> or the 'BIOS' (terminal!) reboot methods.
> 
> Thirdly, CF9_COND is a total misnomer - it should be something like
> CF9_SAFE or CF9_CAREFUL, and 'CF9' should be 'CF9_FORCE' ...
> 
> So this patch fixes the worst problems:
> 
>  - it orders the actual reboot logic to follow the reboot ordering
>    pattern - it was in a pretty random order before for no good
>    reason.
> 
>  - it fixes the CF9 misnomers and uses BOOT_CF9_FORCE and
>    BOOT_CF9_SAFE flags to make the code more obvious.
> 
>  - it tries the BIOS reboot method before the PCI reboot method.
>    (Since 'BIOS' is a terminal reboot method resulting in a hang
>     if it does not work, this is essentially equivalent to removing
>     the PCI reboot method from the default reboot chain.)
> 
>  - just for the miraculous possibility of terminal (resulting
>    in hang) reboot methods of triple fault or BIOS returning
>    without having done their job, there's an ordering between
>    them as well.
> 
> Reported-and-bisected-and-tested-by: Steven Rostedt <rostedt@...dmis.org>
> Cc: Li Aubrey <aubrey.li@...ux.intel.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Matthew Garrett <mjg59@...f.ucam.org>
> Link: http://lkml.kernel.org/r/20140404064120.GB11877@gmail.com
> Signed-off-by: Ingo Molnar <mingo@...nel.org>

So I rebased the patch Steve tested as-is and only fixed the patch 
description and some comments in the code, preserving Steve's testing 
status, and propagated it into x86/urgent.

I've added this description that tries to describe the new/old logic:

> + * To the best of our knowledge Windows compatible x86 hardware expects
> + * the following on reboot:
>   *
>   * 1) If the FADT has the ACPI reboot register flag set, try it
>   * 2) If still alive, write to the keyboard controller
>   * 3) If still alive, write to the ACPI reboot register again
>   * 4) If still alive, write to the keyboard controller again
>   * 5) If still alive, call the EFI runtime service to reboot
> + * 6) If no EFI runtime service, call the BIOS to do a reboot
>   *
> + * We default to following the same pattern. We also have
> + * two other reboot methods: 'triple fault' and 'PCI', which
> + * can be triggered via the reboot= kernel boot option or
> + * via quirks.
> + *
> + * This means that this function can never return, it can misbehave
> + * by not rebooting properly and hanging.

If this is inaccurate (or undesirable, or fails to match the fine 
code) then please object.

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/