linux-kernel - Re: [PATCH v3 01/11] x86/boot: enumerate documentation for the x86 hardware

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: <20160302194006.GK25240@wotan.suse.de>
Date:	Wed, 2 Mar 2016 20:40:06 +0100
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	"Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:	Ingo Molnar <mingo@...nel.org>, bp@...en8.de, hpa@...or.com,
	tglx@...utronix.de, mingo@...hat.com, rusty@...tcorp.com.au,
	x86@...nel.org, linux-kernel@...r.kernel.org, luto@...capital.net,
	boris.ostrovsky@...cle.com, david.vrabel@...rix.com,
	konrad.wilk@...cle.com, xen-devel@...ts.xensource.com,
	lguest@...ts.ozlabs.org,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v3 01/11] x86/boot: enumerate documentation for the x86
 hardware_subarch

On Wed, Mar 02, 2016 at 01:43:42AM +0100, Luis R. Rodriguez wrote:
> On Wed, Feb 24, 2016 at 09:32:59AM +0100, Ingo Molnar wrote:
> There's only one problem with this strategy I can think so far which differs
> from my original approach, which is partly why I actually started looking at
> this stuff:
> 
>   it doesn't help us pro-actively vet each early boot sequence
>   thrown at the x86 path well work on all required subarchs
> 
> The quirks stuff / proactive solution should perhaps be considered orthogonal.
> It just so happened that I was able to address some quirks with what I was

Since it is orthogonal I'll simply work off on the paravirt_enabled() removal
separately as its possible. Since the clarity on semantics will be needed
for other work I'm doing (proactive solution to avoid issues on early boot)
and since the proposed alternative still uses subarch for the quirks as
you recommended I'll at least still push for documentation update on subarch
use as well for now.

After this, and then after sort a simple link table upstream I can then start
focusing more on the proactive solution once again. That should help keep
things separate and make it clearer what I'm trying to achieve later.

  Luis