netdev - Re: [PATCH net-next 04/15] ice: add devlink parameters to read and write minimum security revision

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: <20210210105145.4d8a4936@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Wed, 10 Feb 2021 10:51:45 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jacob Keller <jacob.e.keller@...el.com>,
        Tony Brelinski <tonyx.brelinski@...el.com>
Cc:     Tony Nguyen <anthony.l.nguyen@...el.com>, davem@...emloft.net,
        netdev@...r.kernel.org, sassmann@...hat.com
Subject: Re: [PATCH net-next 04/15] ice: add devlink parameters to read and
 write minimum security revision

On Thu, 4 Feb 2021 13:53:34 -0800 Jacob Keller wrote:
> On 2/4/2021 11:10 AM, Jacob Keller wrote:
> > I'd rather see the right solution designed here, so if this isn't the
> > right direction I want to work with the list to figure out what makes
> > the most sense. (Even if that's "minimum security should update
> > automatically").
> >  
> I want to clarify here based on feedback I received from customer
> support engineers: We believe it is not acceptable to update this
> automatically, because not all customers want that behavior and would
> prefer to have control over when to lock in the minimum security revision.
> 
> Previous products have behaved this way and we had significant feedback
> when this occurred that many of our customers were unhappy about this,
> even after we explained the reasoning.
> 
> I do not believe that we can accept an automatic/default update of
> minimum security revision.

I spent some time reading through various docs, and my main concern 
now is introduction of an API which does not have any cryptographic
guarantees.

An attacker who has infiltrated the OS but did not manage to crack 
the device yet, can fake the SEV responses and keep the counter from
ever being bumped until they successfully expoit the device. Is the 
min SEV counter included in device measurements?

I'm starting to think that distributing separate FW builds with and
without auto-SEV bump is the best way to fit into the SecBoot infra,
without additional wrinkles and attack vectors.

WDYT?