From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754085AbcASM6K (ORCPT <rfc822;w@1wt.eu>);
	Tue, 19 Jan 2016 07:58:10 -0500
Received: from unicorn.mansr.com ([81.2.72.234]:46824 "EHLO unicorn.mansr.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752547AbcASM56 convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 19 Jan 2016 07:57:58 -0500
From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans@mansr.com>
To: Michal Marek <mmarek@suse.cz>
Cc: Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@suse.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Markus Trippelsdorf <markus@trippelsdorf.de>,
        Thomas Voegtle <tv@lio96.de>, linux-kernel@vger.kernel.org,
        x86-ml <x86@kernel.org>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
        Thomas Gleixner <tglx@linutronix.de>, Jiri Olsa <jolsa@redhat.com>,
        Arnaldo Carvalho de Melo <acme@infradead.org>,
        =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker <fweisbec@gmail.com>
Subject: Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y
References: <20160108122719.GG14673@pd.tnic> <568FB028.1030706@suse.cz>
	<20160108133725.GH14673@pd.tnic> <568FCC45.1010301@suse.cz>
	<20160111194311.GF4686@pd.tnic> <yw1x4mejx3le.fsf@unicorn.mansr.com>
	<20160111205945.GH4686@pd.tnic> <yw1xziwbvnde.fsf@unicorn.mansr.com>
	<20160111211712.GI4686@pd.tnic> <20160114184350.GB12109@pd.tnic>
	<20160119082022.GB18237@gmail.com>
	<yw1xbn8hsqf7.fsf@unicorn.mansr.com> <569E2F5C.2040904@suse.cz>
Date: Tue, 19 Jan 2016 12:57:56 +0000
In-Reply-To: <569E2F5C.2040904@suse.cz> (Michal Marek's message of "Tue, 19
	Jan 2016 13:43:08 +0100")
Message-ID: <yw1x37ttsp4b.fsf@unicorn.mansr.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Michal Marek <mmarek@suse.cz> writes:

> Dne 19.1.2016 v 13:29 Måns Rullgård napsal(a):
>> Force-enabling BLK_DEV_INITRD isn't going to make anyone change their
>> boot scripts.
>
> If you are on a regular distro, /sbin/installkernel should do the right
> thing: Run mkinitrd / dracut and if the tools are recent enough and
> there is a microcode update for your CPU, a cpio with the microcode blob
> will be prepended to the initrd. So this is more or less covered.

I'd be rather cross if something suddenly started building initrds on my
systems.  To me they're just a useless level of complexity to maintain.
(I'm not denying they can be useful to others.)

>> I'd also like to get a coherent answer to why microcode update is 
>> preferably done from an initrd as opposed to shortly after mounting
>> a regular disk.  My systems seem perfectly happy doing the latter.
>
> It's not even done *from* the initrd but way earlier. We learned the
> hard way when Intel released a microcode update for Haswell which
> disabled TSX: Userspace did not expect the feature flags to change and
> previously valid instructions to start trapping. This can in principle
> happen again and with any vendor.

OK, I can see how that might be a problem.

-- 
Måns Rullgård