linux-kernel - Re: [PATCH v3 2/5] firmware: annotate thou shalt not request fw on init or probe

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, 24 Aug 2016 10:17:38 +0200
From:   Gabriel Paubert <paubert@...m.es>
To:     mcgrof@...nel.org
Cc:     ming.lei@...onical.com, akpm@...ux-foundation.org,
        gregkh@...uxfoundation.org, dmitry.torokhov@...il.com,
        linux-doc@...r.kernel.org, Gilles.Muller@...6.fr, tiwai@...e.de,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Alessandro Rubini <rubini@...dd.com>, stephen.boyd@...aro.org,
        bjorn.andersson@...aro.org, teg@...m.no, chunkeey@...glemail.com,
        cocci@...teme.lip6.fr, jwboyer@...oraproject.org,
        Jonathan Corbet <corbet@....net>,
        Kevin Cernekee <cernekee@...il.com>,
        Thierry Martinez <martinez@...p.org>,
        linux-serial@...r.kernel.org, jslaby@...e.com,
        zohar@...ux.vnet.ibm.com, arend.vanspriel@...adcom.com,
        linuxppc-dev@...ts.ozlabs.org, Kees Cook <keescook@...omium.org>,
        hauke@...ke-m.de, nicolas.palix@...g.fr, Abhay_Salunke@...l.com,
        Julia.Lawall@...6.fr, broonie@...nel.org, j.anaszewski@...sung.com,
        kvalo@...eaurora.org, dhowells@...hat.com, dwmw2@...radead.org,
        markivx@...eaurora.org, daniel.wagner@...-carit.de,
        linux-kernel@...r.kernel.org, luto@...capital.net, mmarek@...e.com,
        rpurdie@...ys.net, johannes@...solutions.net,
        fengguang.wu@...el.com, torvalds@...ux-foundation.org
Subject: Re: [PATCH v3 2/5] firmware: annotate thou shalt not request fw on
 init or probe

On Tue, Aug 23, 2016 at 05:45:04PM -0700, mcgrof@...nel.org wrote:

[snip]
> ---
>  Documentation/firmware_class/README                |  20 ++++
>  drivers/base/Kconfig                               |   2 +-
>  .../request_firmware-avoid-init-probe-init.cocci   | 130 +++++++++++++++++++++
>  3 files changed, 151 insertions(+), 1 deletion(-)
>  create mode 100644 scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
> 
> diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README
> index cafdca8b3b15..056d1cb9d365 100644
> --- a/Documentation/firmware_class/README
> +++ b/Documentation/firmware_class/README
> @@ -93,6 +93,26 @@
>     user contexts to request firmware asynchronously, but can't be called
>     in atomic contexts.
>  
> +Requirements:
> +=============
> +
> +You should avoid at all costs requesting firmware on both init and probe paths
> +of your device driver. Reason for this is the complexity needed to ensure a
> +firmware will be available for a driver early in boot through different
> +build configurations. Consider built-in drivers needing firmware early, or
> +consider a driver assuming it will only get firmware after pivot_root().
> +
> +Drivers that really need firmware early should use stuff the firmware in

Minor grammatical nit: s/use//

> +initramfs or consider using CONFIG_EXTRA_FIRMWARE. Using initramfs is much
> +more portable to more distributions as not all distributions wish to enable
> +CONFIG_EXTRA_FIRMWARE. Should a driver require the firmware being built-in
> +it should depend on CONFIG_EXTRA_FIRMWARE. There is no current annotation for
> +requiring a firmware on initramfs.
> +
> +If you're a maintainer you can help police this with:
> +
> +$ export COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
> +$ make coccicheck MODE=report
>  
>   about in-kernel persistence:
>   ---------------------------