| Message ID | 20211202152358.60116-1-hare@suse.de |
|---|---|
| Headers | show |
| Series | nvme: In-band authentication support | expand |
So if we want to make progress on this we need the first 3 patches rewviewed by the crypto maintainers. In fact I'd prefer to get them merged through the crypto tree as well, and would make sure we have a branch that pulls them in for the nvme changes. I'll try to find some time to review the nvme bits as well.
On 12/13/21 9:08 AM, Christoph Hellwig wrote: > So if we want to make progress on this we need the first 3 patches > rewviewed by the crypto maintainers. In fact I'd prefer to get them > merged through the crypto tree as well, and would make sure we have > a branch that pulls them in for the nvme changes. I'll try to find > some time to review the nvme bits as well. > That is _actually_ being addressed already. Nicolai Stange send a patchset for ephemeral keys, FFDHE support, and FIPS-related thingies for the in-kernel DH crypto implementation (https://lore.kernel.org/linux-crypto/20211209090358.28231-1-nstange@suse.de/). This obsoletes my preliminary patches, and I have ported my patchset to run on top of those. Question is how to continue from here; I can easily rebase my patchset and send it relative to Nicolais patches. But then we'll be bound to the acceptance of those patches, so I'm not quite sure if that's the best way to proceed. Cheers, Hannes
>> So if we want to make progress on this we need the first 3 patches >> rewviewed by the crypto maintainers. In fact I'd prefer to get them >> merged through the crypto tree as well, and would make sure we have >> a branch that pulls them in for the nvme changes. I'll try to find >> some time to review the nvme bits as well. >> > That is _actually_ being addressed already. > Nicolai Stange send a patchset for ephemeral keys, FFDHE support, and > FIPS-related thingies for the in-kernel DH crypto implementation > (https://lore.kernel.org/linux-crypto/20211209090358.28231-1-nstange@suse.de/). > > This obsoletes my preliminary patches, and I have ported my patchset to > run on top of those. > > Question is how to continue from here; I can easily rebase my patchset > and send it relative to Nicolais patches. But then we'll be bound to the > acceptance of those patches, so I'm not quite sure if that's the best > way to proceed. Don't know if we have a choice here... What is the alternative you are proposing?
On 12/13/21 10:31 AM, Sagi Grimberg wrote: > >>> So if we want to make progress on this we need the first 3 patches >>> rewviewed by the crypto maintainers. In fact I'd prefer to get them >>> merged through the crypto tree as well, and would make sure we have >>> a branch that pulls them in for the nvme changes. I'll try to find >>> some time to review the nvme bits as well. >>> >> That is _actually_ being addressed already. >> Nicolai Stange send a patchset for ephemeral keys, FFDHE support, and >> FIPS-related thingies for the in-kernel DH crypto implementation >> (https://lore.kernel.org/linux-crypto/20211209090358.28231-1-nstange@suse.de/). >> >> This obsoletes my preliminary patches, and I have ported my patchset >> to run on top of those. >> >> Question is how to continue from here; I can easily rebase my patchset >> and send it relative to Nicolais patches. But then we'll be bound to >> the acceptance of those patches, so I'm not quite sure if that's the >> best way to proceed. > > Don't know if we have a choice here... What is the alternative you are > proposing? That's the thing, I don't really have a good alternative, either. It's just that I have so no idea about the crypto subsystem, and consequently wouldn't know how long we need to wait... But yeah, Nicolais patchset is far superior to my attempts, so I'd be happy to ditch my preliminary attempts there. Cheers, Hannes
>>>> So if we want to make progress on this we need the first 3 patches >>>> rewviewed by the crypto maintainers. In fact I'd prefer to get them >>>> merged through the crypto tree as well, and would make sure we have >>>> a branch that pulls them in for the nvme changes. I'll try to find >>>> some time to review the nvme bits as well. >>>> >>> That is _actually_ being addressed already. >>> Nicolai Stange send a patchset for ephemeral keys, FFDHE support, and >>> FIPS-related thingies for the in-kernel DH crypto implementation >>> (https://lore.kernel.org/linux-crypto/20211209090358.28231-1-nstange@suse.de/). >>> >>> This obsoletes my preliminary patches, and I have ported my patchset >>> to run on top of those. >>> >>> Question is how to continue from here; I can easily rebase my patchset >>> and send it relative to Nicolais patches. But then we'll be bound to >>> the acceptance of those patches, so I'm not quite sure if that's the >>> best way to proceed. >> >> Don't know if we have a choice here... What is the alternative you are >> proposing? > > That's the thing, I don't really have a good alternative, either. > It's just that I have so no idea about the crypto subsystem, and > consequently wouldn't know how long we need to wait... > > But yeah, Nicolais patchset is far superior to my attempts, so I'd be > happy to ditch my preliminary attempts there. Can we get a sense from the crypto folks to the state of Nicolais patchset?
On 12/13/21 2:53 PM, Sagi Grimberg wrote: > >>>>> So if we want to make progress on this we need the first 3 patches >>>>> rewviewed by the crypto maintainers. In fact I'd prefer to get them >>>>> merged through the crypto tree as well, and would make sure we have >>>>> a branch that pulls them in for the nvme changes. I'll try to find >>>>> some time to review the nvme bits as well. >>>>> >>>> That is _actually_ being addressed already. >>>> Nicolai Stange send a patchset for ephemeral keys, FFDHE support, and >>>> FIPS-related thingies for the in-kernel DH crypto implementation >>>> (https://lore.kernel.org/linux-crypto/20211209090358.28231-1-nstange@suse.de/). >>>> >>>> >>>> This obsoletes my preliminary patches, and I have ported my patchset >>>> to run on top of those. >>>> >>>> Question is how to continue from here; I can easily rebase my patchset >>>> and send it relative to Nicolais patches. But then we'll be bound to >>>> the acceptance of those patches, so I'm not quite sure if that's the >>>> best way to proceed. >>> >>> Don't know if we have a choice here... What is the alternative you are >>> proposing? >> >> That's the thing, I don't really have a good alternative, either. >> It's just that I have so no idea about the crypto subsystem, and >> consequently wouldn't know how long we need to wait... >> >> But yeah, Nicolais patchset is far superior to my attempts, so I'd be >> happy to ditch my preliminary attempts there. > > Can we get a sense from the crypto folks to the state of Nicolais > patchset? According to Nicolai things look good, rules seem to be that it'll be accepted if it has positive reviews (which it has) and no-one objected (which no-one did). Other than that one would have to ask the maintainer. Herbert? Cheers, Hannes
>>>>> Question is how to continue from here; I can easily rebase my patchset >>>>> and send it relative to Nicolais patches. But then we'll be bound to >>>>> the acceptance of those patches, so I'm not quite sure if that's the >>>>> best way to proceed. >>>> >>>> Don't know if we have a choice here... What is the alternative you are >>>> proposing? >>> >>> That's the thing, I don't really have a good alternative, either. >>> It's just that I have so no idea about the crypto subsystem, and >>> consequently wouldn't know how long we need to wait... >>> >>> But yeah, Nicolais patchset is far superior to my attempts, so I'd be >>> happy to ditch my preliminary attempts there. >> >> Can we get a sense from the crypto folks to the state of Nicolais >> patchset? > > According to Nicolai things look good, rules seem to be that it'll be > accepted if it has positive reviews (which it has) and no-one objected > (which no-one did). > Other than that one would have to ask the maintainer. > Herbert? Any updates on this?
On 12/21/21 9:55 PM, Sagi Grimberg wrote: > >>>>>> Question is how to continue from here; I can easily rebase my >>>>>> patchset >>>>>> and send it relative to Nicolais patches. But then we'll be bound to >>>>>> the acceptance of those patches, so I'm not quite sure if that's the >>>>>> best way to proceed. >>>>> >>>>> Don't know if we have a choice here... What is the alternative you are >>>>> proposing? >>>> >>>> That's the thing, I don't really have a good alternative, either. >>>> It's just that I have so no idea about the crypto subsystem, and >>>> consequently wouldn't know how long we need to wait... >>>> >>>> But yeah, Nicolais patchset is far superior to my attempts, so I'd be >>>> happy to ditch my preliminary attempts there. >>> >>> Can we get a sense from the crypto folks to the state of Nicolais >>> patchset? >> >> According to Nicolai things look good, rules seem to be that it'll be >> accepted if it has positive reviews (which it has) and no-one objected >> (which no-one did). >> Other than that one would have to ask the maintainer. >> Herbert? > > Any updates on this? Sigh. Herbert suggested reworking the patch, and make ffdhe a separate algorithm (instead of having enums to specify the values for the existing DH algorithm). Discussion is ongoing :-( Cheers, Hannes
> Hannes and co, > > Do you know what is the state of this dependency? Or when should > we expect to revisit this patch set? Ping?
On Mon, Mar 14, 2022 at 07:54:28AM +0100, Hannes Reinecke wrote: > Pondering what the next steps should be. Herbert Xu has merged Nicolais > patchset, so I _could_ submit the patches, but then I would need to base it > on Herberts cryptodev-2.6 branch. > And without these patches my patchset won't compile. > So no sure how to proceed; sending the patches relative to Herberts tree? > Waiting for the patches to appear upstream? Not sure what'll be best... We're at 5.17-rc8, so hopefully they will in mainline for 5.18-rc1 in a few weeks. Let's wait until then to avoid complex tree dependencies.