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
| ||
|
Message-ID: <YtWeUOJewho7p/vM@intel.com> Date: Mon, 18 Jul 2022 13:54:24 -0400 From: Rodrigo Vivi <rodrigo.vivi@...el.com> To: Dave Airlie <airlied@...il.com> CC: <torvalds@...ux-foundation.org>, Jonathan Corbet <corbet@....net>, <linux-doc@...r.kernel.org>, <gregkh@...uxfoundation.org>, Daniel Vetter <daniel@...ll.ch>, <mcgrof@...nel.org>, <alsa-devel@...a-project.org>, <netdev@...r.kernel.org>, <linux-wireless@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <linux-block@...r.kernel.org>, <dri-devel@...ts.sf.net>, Dave Airlie <airlied@...hat.com>, <linux-media@...r.kernel.org> Subject: Re: [PATCH] docs: driver-api: firmware: add driver firmware guidelines. On Mon, Jul 18, 2022 at 05:21:44PM +1000, Dave Airlie wrote: > From: Dave Airlie <airlied@...hat.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@...hat.com> > --- > Documentation/driver-api/firmware/core.rst | 1 + > .../firmware/firmware-usage-guidelines.rst | 34 +++++++++++++++++++ > 2 files changed, 35 insertions(+) > create mode 100644 Documentation/driver-api/firmware/firmware-usage-guidelines.rst > > diff --git a/Documentation/driver-api/firmware/core.rst b/Documentation/driver-api/firmware/core.rst > index 1d1688cbc078..803cd574bbd7 100644 > --- a/Documentation/driver-api/firmware/core.rst > +++ b/Documentation/driver-api/firmware/core.rst > @@ -13,4 +13,5 @@ documents these features. > direct-fs-lookup > fallback-mechanisms > lookup-order > + firmware-usage-guidelines > > diff --git a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst > new file mode 100644 > index 000000000000..34d2412e78c6 > --- /dev/null > +++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst > @@ -0,0 +1,34 @@ > +=================== > +Firmware Guidelines > +=================== > + > +Drivers that use firmware from linux-firmware should attempt to follow > +the rules in this guide. > + > +* Firmware should be versioned with at least a major/minor version. It > + is suggested that the firmware files in linux-firmware be named with > + some device specific name, and just the major version. The > + major/minor/patch versions should be stored in a header in the > + firmware file for the driver to detect any non-ABI fixes/issues. The > + firmware files in linux-firmware should be overwritten with the newest > + compatible major version. Newer major version firmware should remain > + compatible with all kernels that load that major number. would symbolic links be acceptable in the linux-firmware.git where the <fmw>_<major>.bin is a sym link to <fwm>_<major>.<minor>.bin or having the <fwm>_<major>.bin really to be the overwritten every minor update? > + > +* Users should *not* have to install newer firmware to use existing > + hardware when they install a newer kernel. If the hardware isn't > + enabled by default or under development, this can be ignored, until > + the first kernel release that enables that hardware. This means no > + major version bumps without the kernel retaining backwards > + compatibility for the older major versions. Minor version bumps > + should not introduce new features that newer kernels depend on > + non-optionally. > + > +* If a security fix needs lockstep firmware and kernel fixes in order to > + be successful, then all supported major versions in the linux-firmware > + repo should be updated with the security fix, and the kernel patches > + should detect if the firmware is new enough to declare if the security > + issue is fixed. All communications around security fixes should point > + at both the firmware and kernel fixes. If a security fix requires > + deprecating old major versions, then this should only be done as a > + last option, and be stated clearly in all communications. Everything makes sense to me. Thanks for writing this down. Acked-by: Rodrigo Vivi <rodrigo.vivi@...el.com> > + > -- > 2.36.1 > > > > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel@...ts.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel
Powered by blists - more mailing lists