netdev - Re: [RFC 0/1] Proposal for new devlink command to enforce firmware security

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] [day] [month] [year] [list]

Message-ID: <20241216075303.7667c1a1@kernel.org>
Date: Mon, 16 Dec 2024 07:53:03 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: "Szapar-Mudlaw, Martyna" <martyna.szapar-mudlaw@...ux.intel.com>,
 <andrew+netdev@...n.ch>, <netdev@...r.kernel.org>, <horms@...nel.org>,
 <jiri@...nulli.us>, <stephen@...workplumber.org>,
 <anthony.l.nguyen@...el.com>, <jacob.e.keller@...el.com>,
 <intel-wired-lan@...ts.osuosl.org>
Subject: Re: [RFC 0/1] Proposal for new devlink command to enforce firmware
 security

On Mon, 16 Dec 2024 16:09:12 +0100 Przemek Kitszel wrote:
> > Please point me to relevant standard that supports locking in security
> > revision as an action separate from FW update, and over an insecure
> > channel.
> > 
> > If you can't find one, please let's not revisit this conversation.  
> 
> It's not standard, just the design for our e810 (e82x?) FW, but we could 
> achieve the goal in one step, while preserving the opt-out mechanism for
> those unwilling customers. I think that this will allow at least some
> customers to prevent possibility of running a known-to-be-bad FW
> (prior to opening given server to the world).
> 
> We could simply add DEVLINK_FLASH_OVERWRITE_MIN_VERSION (*) flag for the
> single-step flash update [1], and do the update AND bump our "minsrev"
> in one step.
> The worst that could happen, is that customer will get some newer
> version of the firmware (but a one released by Intel).
> We preserve the simplicity of one .bin file with that too.

Please explain to me how this will all fit into the existing standards
like SPDM. Please take security seriously.. this is not just another
knob. How will attestation of the fact that someone flipped the knob
work?

A much better workaround would be for you to build multiple FW images
and give customers an image which locks in the min version and one
which doesn't.