Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 18 Jul 2022 15:00:11 -0700
From:   Luis Chamberlain <mcgrof@kernel.org>
To:     Dave Airlie <airlied@gmail.com>
Cc:     torvalds@linux-foundation.org, Jonathan Corbet <corbet@lwn.net>,
        linux-doc@vger.kernel.org, gregkh@linuxfoundation.org,
        Daniel Vetter <daniel@ffwll.ch>, linux-kernel@vger.kernel.org,
        dri-devel@lists.sf.net, netdev@vger.kernel.org,
        linux-wireless@vger.kernel.org, alsa-devel@alsa-project.org,
        linux-media@vger.kernel.org, linux-block@vger.kernel.org,
        Dave Airlie <airlied@redhat.com>,
        Paul Moore <paul@paul-moore.com>,
        Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH] docs: driver-api: firmware: add driver firmware
 guidelines.
Message-ID: <YtXX604B2X8vdH9b@bombadil.infradead.org>
References: <20220718072144.2699487-1-airlied@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220718072144.2699487-1-airlied@gmail.com>
Sender: Luis Chamberlain <mcgrof@infradead.org>
Precedence: bulk

On Mon, Jul 18, 2022 at 05:21:44PM +1000, Dave Airlie wrote:
> From: Dave Airlie <airlied@redhat.com>
> 
> A recent snafu where Intel ignored upstream feedback on a firmware
> change, led to a late rc6 fix being required. In order to avoid this
> in the future we should document some expectations around
> linux-firmware.
> 
> I was originally going to write this for drm, but it seems quite generic
> advice.
> 
> I'm cc'ing this quite widely to reach subsystems which use fw a lot.
> 
> Signed-off-by: Dave Airlie <airlied@redhat.com>

Document well deserved to be written, thanks for making this happen.
Modulo all the silly spelling / bike-shedding issues folks might find,
in case you care to re-spin for a v2:

Acked-by: Luis Chamberlain <mcgrof@kernel.org>

Now let's think about the impact of two corner cases which *do*
happen and so this poses security implications on enablement:

1) Devices which end up with a security issue which a vendor considers
   obsolete, and the only way to fix something is firmware. We're
   security-out-of-luck. For this I've previously sucessfully have put
   effort into organizations to open source the firmware. We were
   successful more than once:

     * https://github.com/qca/open-ath9k-htc-firmware
     * https://github.com/qca/ath6kl-firmware

   When these efforts fall short we have a slew of reverse engineering
   efforts which fortunately also have been sucessfull.

2) Vendor goes belly up

Both implicate the need to help persuade early on a strategy for open
source firmware, and I don't want to hear anyone tell me it is not
possible.

When that fails we can either reverse engineer and worst case, I am not
sure if we have a process for annotations or should. Perhaps a kconfig
symbol which drivers with buggy firmware can depend on, and only if you
enable that kconfig symbol would these drivers be available to be
enabled?

Are we aware of such device drivers? They must exist...

  Luis