From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755381AbcAROvF (ORCPT ); Mon, 18 Jan 2016 09:51:05 -0500 Received: from unicorn.mansr.com ([81.2.72.234]:44996 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752538AbcAROvD convert rfc822-to-8bit (ORCPT ); Mon, 18 Jan 2016 09:51:03 -0500 From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Borislav Petkov Cc: Thomas Voegtle , Michal Marek , Markus Trippelsdorf , linux-kernel@vger.kernel.org, x86-ml Subject: Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig References: <568FCC45.1010301@suse.cz> <20160111194311.GF4686@pd.tnic> <20160111205945.GH4686@pd.tnic> <20160111211712.GI4686@pd.tnic> <20160114184350.GB12109@pd.tnic> <20160118140649.GC12651@pd.tnic> <20160118144114.GE12651@pd.tnic> Date: Mon, 18 Jan 2016 14:51:00 +0000 In-Reply-To: <20160118144114.GE12651@pd.tnic> (Borislav Petkov's message of "Mon, 18 Jan 2016 15:41:14 +0100") Message-ID: 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: X-Mailing-List: linux-kernel@vger.kernel.org Borislav Petkov writes: > On Mon, Jan 18, 2016 at 02:11:49PM +0000, Måns Rullgård wrote: >> Wasn't the idea *not* to disable CONFIG_MICROCODE? > > Is the error message not understandable? > > +MSG="\nYou have CONFIG_MICROCODE enabled without BLK_DEV_INITRD. The preferred\n\ > +way is to enable it and make sure microcode is added to your initrd as\n\ > +explained in Documentation/x86/early-microcode.txt. This is also the\n\ > +most tested method as the majority of distros do it. Alternatively, and\n\ > +if you don't want to enable modules, you should make sure the microcode\n\ > +is built into the kernel.\n" I understand and disagree. I think you're being overzealous in trying to bludgeon people into doing things the way you think they should be done. >>From the point of view of the actual update mechanism, what difference does it make where the microcode data was retrieved from? If you want to warn about what you consider "unsafe" updates, do that when the update happens instead. With this patch, simply enabling BLK_DEV_INITRD will shut up the warning even if an initrd is never actually used. Also, what do modules have to do with anything? -- Måns Rullgård