linux-kernel - Re: [RFC] fs: add userspace critical mounts event support

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:   Wed, 7 Sep 2016 00:32:55 +0200
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Felix Fietkau <nbd@....name>,
        David Woodhouse <dwmw2@...radead.org>,
        Roman Pen <r.peniaev@...il.com>,
        Ming Lei <ming.lei@...onical.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Marek <mmarek@...e.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Vikram Mulukutla <markivx@...eaurora.org>,
        Stephen Boyd <stephen.boyd@...aro.org>,
        Mark Brown <broonie@...nel.org>, Takashi Iwai <tiwai@...e.de>,
        Johannes Berg <johannes@...solutions.net>,
        Christian Lamparter <chunkeey@...glemail.com>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Josh Boyer <jwboyer@...oraproject.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Jiri Slaby <jslaby@...e.com>,
        Andy Lutomirski <luto@...capital.net>,
        Wu Fengguang <fengguang.wu@...el.com>,
        Richard Purdie <rpurdie@...ys.net>,
        Jeff Mahoney <jeffm@...e.com>,
        Jacek Anaszewski <j.anaszewski@...sung.com>,
        Abhay_Salunke@...l.com, Julia Lawall <Julia.Lawall@...6.fr>,
        Gilles.Muller@...6.fr, nicolas.palix@...g.fr,
        Tom Gundersen <teg@...m.no>, Kay Sievers <kay@...y.org>,
        David Howells <dhowells@...hat.com>,
        Alessandro Rubini <rubini@...dd.com>,
        Kevin Cernekee <cernekee@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Jonathan Corbet <corbet@....net>,
        Thierry Martinez <martinez@...p.org>,
        linux-serial <linux-serial@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 06, 2016 at 11:32:05AM -0700, Linus Torvalds wrote:
> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson
> <bjorn.andersson@...aro.org> wrote:
> >
> > Linus, I reversed the order of your questions/answers to fit my answer
> > better.
> 
> Nobody has actually answered the "why don't we just tie the firmware

This is not about firmware anymore. The fact that we were reading files from
the filesystem in different ways called for a generic API, that was done by
Mimi with the new generic kernel_read_file_from_path(), the fact that there
were race concerns with firmware means such races are also in theory possible
outside of firmware.

> and module together" question.

In terms of the firmware, licensing is one reason I'm aware of. Another reason
is updates to firmware files may not implicate a driver update -- its pointless
to rebuild a kernel if all you need is a firmware update.

For both modules and built-in we already have the option to bundle firmware
into initramfs, and CONFIG_EXTRA_FIRMWARE, some folks do not want to use these.
Bjorn noted a few reasons why. Here's the full list of reasons I've heard why
folks shy away from these:

  o Licensing
  o You still want the ability to do updates
  o The size of the files can be huge (remoteproc is talking about 10 MiB files)

Do we want to bring the firmware closer together than what we allow for modules? If
so it may make sense to use a modpost command to try to bundle module and
firmware together, the build system could use the MODULE_FIRMWARE() for that.
It does mean you now have a build dependency for linux-firmware on the kernel.
Do we want that?

> Really. If the driver doesn't work without the firmware, then why the
> hell is it separated from it in the first place?

This I agree with, although you still have to consider you may want to enable
updates for firmware without a driver update.

  Luis