linux-kernel - Re: Why the auxiliary cipher in gss_krb5

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]

Date:   Tue, 08 Dec 2020 13:25:03 +0000
From:   David Howells <dhowells@...hat.com>
To:     Chuck Lever <chuck.lever@...cle.com>,
        Ard Biesheuvel <ardb@...nel.org>
Cc:     dhowells@...hat.com, Bruce Fields <bfields@...ldses.org>,
        CIFS <linux-cifs@...r.kernel.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        linux-crypto@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-afs@...ts.infradead.org
Subject: Re: Why the auxiliary cipher in gss_krb5_crypto.c?

I wonder - would it make sense to reserve two arrays of scatterlist structs
and a mutex per CPU sufficient to map up to 1MiB of pages with each array
while the krb5 service is in use?

That way sunrpc could, say, grab the mutex, map the input and output buffers,
do the entire crypto op in one go and then release the mutex - at least for
big ops, small ops needn't use this service.

For rxrpc/afs's use case this would probably be overkill - it's doing crypto
on each packet, not on whole operations - but I could still make use of it
there.

However, that then limits the maximum size of an op to 1MiB, plus dangly bits
on either side (which can be managed with chained scatterlist structs) and
also limits the number of large simultaneous krb5 crypto ops we can do.

David