Re: [PATCH 1/2] bpf: Add BPF_MAP_TYPE_CRED_STORAGE map type and kfuncs

[Song Liu]

On Tue, Sep 16, 2025 at 8:25 AM David Windsor <dwindsor@xxxxxxxxx> wrote:
[...]
> >
> > makes sense thanks
> >
>
> Hi,
>
> Thinking about this more, hashmaps are still problematic for this case.
>
> Meaning, placing a hook on security_cred_free alone for garbage
> collection / end-of-life processing isn't enough - we still have to
> deal with prepare/commit_creds. This flow works by having
> prepare_creds clone an existing cred object, then commit_creds works
> by swapping old creds with new one atomically, then later freeing the
> original cred. If we are not very careful there will be a period of
> time during which both cred objects could be valid, and I think this
> is worth the feature alone.

With cred local storage, we still need to deal with prepare/commit creds,
right? cred local storage only makes sure the storage is allocated and
freed. The BPF LSM programs still need to initiate the data properly
based on the policy. IOW, whether we have cred local storage or not,
it is necessary to handle all the paths that alloc/free the cred. Did I miss
something here?

Thanks,
Song