netdev - Re: [RFC net-next 01/15] psp: add documentation

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

Message-ID: <CAHWOjVL2hM4Lv=jNAv9CmLHYJL5ZBHmDH=ySQr7fr1Z6kgAvjg@mail.gmail.com>
Date: Fri, 28 Jun 2024 15:33:28 -0400
From: Lance Richardson <rlance@...gle.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>, netdev@...r.kernel.org, 
	pabeni@...hat.com, borisp@...dia.com, gal@...dia.com, cratiu@...dia.com, 
	rrameshbabu@...dia.com, steffen.klassert@...unet.com, tariqt@...dia.com
Subject: Re: [RFC net-next 01/15] psp: add documentation

On Thu, Jun 27, 2024 at 6:33 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> I was under the possibly mistaken impression that Google have used PSP
> for years without rekeying... Did I misunderstand?
>
Actually Google does implement connection rekeying when master key
rotation occurs. I believe this was the case even in the first production
deployment (Willem would know the history better).

> > A tiny bit logic would also be needed on the Rx
> > side to track the current and previous SPI, if the hardware supports
> > keys indescriptors then nothing more should be needed on the Tx side.
> > If the NIC maintains an SA database and doesn't allow existing
> > entries to be updated, a small amount of additional logic would be
> > needed, but perhaps that could be (waving hands a bit) the
> > responsibility of the driver.
>
> Interesting. Hm. But SADB drivers would then have to implement some
> complex logic to make sure all rings have cycled, or take references.
> I'd rather have an opt-in for core to delay reaping old keys until
> all sockets which used them went empty at least once (in wmem sense).

Right, ensuring that the old entry is no longer referenced by packets in the
transmit pipeline before removing is definitely a concern. One simple
approach is to simply keep the old entry around for long enough (e.g. a
minute or two) to ensure that any packets referencing it have been transmitted.