Re: [PATCH v3 2/2] rust: crypto: add synchronous RSA akcipher support

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Aug 27, 2026 at 04:46:55PM +0200, Miguel Ojeda wrote:
> On Thu, Aug 27, 2026 at 5:05 AM Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > As I've been commenting on other of these bindings patches, it also
> > doesn't really make sense to have the kconfig symbol be in lib/ but then
> > have the actual code be in rust/.  They should be in the same place.
> 
> Did you see my reply at
> 
>   https://lore.kernel.org/rust-for-linux/CANiq72=uUR4Vo9W55Kq6tQjc+6Q4_+wiWhCo-VLdkvg6PJeoAw@mail.gmail.com/
> 
> ?
> 
> But if you feel strongly about it, I guess it can be temporarily
> placed elsewhere, i.e. Kconfig symbols are not tied to the path anyway
> so they should be easy to move later on.

Yes, it doesn't explain why they need to be inconsistent though.

And if the code is "conceptually part of the subsystem", why is the
MAINTAINERS entry for "CRYPTO LIBRARY" not being updated to include it?

FWIW: I do think the Rust bindings need to live alongside the code
itself and be maintained by the same people.

I just don't think it makes sense to mostly *not* be doing it that way,
but then also having the kconfig options randomly be different.  We
should at least be consistent.

> If you mean a function in the standard library to zero memory without
> being optimized out: no, there isn't.
> 
> For context: I added `memset_explicit` to the ISO C standard and
> informally asked upstream Rust about adding an equivalent function
> many years ago, but at least back then they didn't want to add it (or
> at least in a way similar to how it is specified in C, which doesn't
> really give guarantees, letting compiler writers do their best
> effort).
> 
> I guess I can ask again since now we would finally have an actual user
> in Linux... :)

Userspace crypto libraries need this too, so it's kind of surprising it
would just be coming up now.

- Eric