linux-kernel - Re: Extending the kernel crypto uAPI to support decryption into secure buffers

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

Message-ID: <CAMRc=Mfse2N-X9CNnpct211nfDNu4FewQ9qqnNQeqK=eQXoZGw@mail.gmail.com>
Date: Fri, 28 Mar 2025 11:56:09 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, Kees Cook <kees@...nel.org>, 
	Jens Wiklander <jens.wiklander@...aro.org>, Joakim Bech <joakim.bech@...aro.org>, 
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE" <linux-crypto@...r.kernel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>, Daniel Perez-Zoghbi <dperezzo@...cinc.com>, 
	Gaurav Kashyap <gaurkash@....qualcomm.com>, Udit Tiwari <utiwari@....qualcomm.com>, 
	Md Sadre Alam <mdalam@....qualcomm.com>, Amirreza Zarrabi <quic_azarrabi@...cinc.com>
Subject: Re: Extending the kernel crypto uAPI to support decryption into
 secure buffers

On Wed, Mar 26, 2025 at 5:59 PM Eric Biggers <ebiggers@...nel.org> wrote:
>
> On Tue, Mar 25, 2025 at 09:23:09PM +0100, Bartosz Golaszewski wrote:
> >
> > There are many out-of-tree implementations of DRM stacks (Widevine or
> > otherwise) by several vendors out there but so far there's none using
> > mainline kernel exclusively.
> >
> > Now that Jens' work[1] on restricted DMA buffers is pretty far along
> > as is the QTEE implementation from Amirreza, most pieces seem to be
> > close to falling into place and I'd like to tackl
> > e the task of implementing Widevine for Qualcomm platforms on linux.
> >
> > I know that talk is cheap but before I show any actual code, I'd like
> > to first discuss the potential extensions to the kernel crypto uAPI
> > that this work would require.
> >
>
> What would you get out of building this on top of AF_ALG, vs. building a new
> UAPI from scratch?  There seem to be an awful lot of differences between what
> this needs and what AF_ALG does.
>

I don't have much against building it from scratch. If anything, I
would love me a green-field kernel development instead of tweaking
existing code, it would probably make the work much more enjoyable.

But if I'm being honest, it's hard to tell whether there are more
differences than similarities. A big part of the existing crypto code
- especially the driver boiler-plate - could potentially be reused as
could the existing netlink infrastructure for setsockopt() and
write().

That being said: if I were to design a new interface for this, I would
probably not go with netlink and instead provide a regular character
device (let's say: /dev/secure_crypto) with a set of ioctls() for key,
cipher and general management and support for write() for data
decryption. IMO socket() interface is so much more clunky than
chardev.

Bartosz