linux-kernel - Re: [RFC v1] tree-wide: remove "select FW

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]

Date:	Fri, 22 May 2015 09:11:34 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	"David S. Miller" <davem@...emloft.net>, clemens@...isch.de,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	JBottomley@...n.com, David Airlie <airlied@...ux.ie>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Marcel Holtmann <marcel@...tmann.org>,
	"Gustavo F. Padovan" <gustavo@...ovan.org>,
	Johan Hedberg <johan.hedberg@...il.com>,
	Mikael Starvik <starvik@...s.com>,
	Jesper Nilsson <jesper.nilsson@...s.com>,
	Imre Kaloz <kaloz@...nwrt.org>, khalasa@...p.pl,
	ohad@...ery.com, Arnd Bergmann <arnd@...db.de>, 3chas3@...il.com,
	Jiri Slaby <jslaby@...e.cz>, Bryan Wu <cooloney@...il.com>,
	Richard Purdie <rpurdie@...ys.net>,
	Jacek Anaszewski <j.anaszewski@...sung.com>,
	Paul Bolle <pebolle@...cali.nl>, Takashi Iwai <tiwai@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses

Hi Boris,

On Fri, May 22, 2015 at 8:53 AM, Borislav Petkov <bp@...en8.de> wrote:
> On Fri, May 22, 2015 at 12:21:29AM +0200, Borislav Petkov wrote:
>> On Thu, May 21, 2015 at 01:45:49PM -0700, Luis R. Rodriguez wrote:
>> > The above history is just *one* set of reasons to remove all kernel
>> > "select FW_LOADER" entries. Another simple reason is that since
>> > FW_LOADER can only be disabled by an EXPERT and it defaults to y
>> > its now a superfluous select. We will ensure things build for you
>> > if using EXPERT but if you have selected EXPERT you should know
>> > what run time requirements you need.
>>
>> Couple of notes only:

> So the "depends" thing is a step backwards IMO because people would have
> to go and enable FW_LOADER first. For the microcode loader, at least,
> "select" is perfectly fine.

That's what the EXPERT protection is for.
FW_LOADER will always be enabled, unless people think they're smarter
than they are, and enable EXPERT, and disable FW_LOADER.

> One thing I forgot last night: what about randconfigs? All that
> functionality which selects FW_LOADER, won't boot anymore, right? I
> mean, there are provisions to build fine even with FW_LOADER unset but
> if you want to boot-test those kernels, you will artificially fail due
> to missing request_firmware* things...

If you expect to _boot_ randconfig kernels, you better disable EXPERT.
Still, your kernel can fail to boot due to some other critical dependency
(does your kernel support your CPU?).

If you want to boot randconfig kernels, create an allrandomconfig file
listing all options that must have a certain value:

$ cat allrandomconfig
CONFIG_EXPERT=n
CONFIG_MY_CRITICAL_FEATURE=y
...
$

and use "make randconfig KCONFIG_ALLCONFIG=1".

> ECO tip #101: Trim your mails when you reply.

You trimmed too much, so I had to readd it manually ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/