[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240529104302.70c96c25@kernel.org>
Date: Wed, 29 May 2024 10:43:02 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Lance Richardson <lance604@...il.com>
Cc: netdev@...r.kernel.org, pabeni@...hat.com,
willemdebruijn.kernel@...il.com, borisp@...dia.com, gal@...dia.com,
cratiu@...dia.com, rrameshbabu@...dia.com, steffen.klassert@...unet.com,
tariqt@...dia.com, Lance Richardson <rlance@...gle.com>
Subject: Re: [RFC net-next 05/15] psp: add op for rotation of secret state
On Thu, 16 May 2024 15:59:14 -0400 Lance Richardson wrote:
> On Thu, May 9, 2024 at 11:05 PM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > Rotating the secret state is a key part of the PSP protocol design.
> > Some external daemon needs to do it once a day, or so.
> > Add a netlink op to perform this operation.
> > Add a notification group for informing users that key has been
> > rotated and they should rekey (next rotation will cut them off).
> >
> Does this allow for the possibility of NIC firmware or the driver initiating
> a rotation? E.g. during key generation if the SPI space has been
> exhausted a rotation will be required in order to generate a new
> derived key.
I think it should be fine - I was designing with that use case in mind,
but ended up not needing it. We can export a driver facing function
which will basically perform the equivalent of psp_nl_key_rotate_doit().
I added the "key generation", because I worried that if unsynchronized
agents on multiple hosts can rotate the key - the chances of
double-rotation and immediate reuse of a SPI are much higher.
Not sure if the extra key generation bits are really necessary..
it seemed like a good idea at the time :)
Powered by blists - more mailing lists