public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: "Ⓐlï P☮latel" <alip@chesswob.org>
Cc: linux-crypto@vger.kernel.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
	Taeyang Lee <0wn@theori.io>, Brian Pak <bpak@theori.io>,
	Juno Im <juno@theori.io>, Jungwon Lim <setuid0@theori.io>,
	Tim Becker <tjbecker@theori.io>,
	Demi Marie Obenour <demiobenour@gmail.com>,
	Feng Ning <feng@innora.ai>,
	stable@vger.kernel.org
Subject: Re: [PATCH] crypto: af_alg - Remove zero-copy support from AF_ALG
Date: Mon, 4 May 2026 15:25:18 -0700	[thread overview]
Message-ID: <20260504222518.GA21478@quark> (raw)
In-Reply-To: <xxEJMG_wLMObY-emZXfETJ6HxxJQCY3OnYiBIUTyAWEMiAcr8QQd2t7c8O-Qj43zBGRv64st0_IrW9ABgaVwco9-puLVlIDh3ijeJ-cxXaE=@chesswob.org>

On Mon, May 04, 2026 at 06:26:10PM +0000, Ⓐlï P☮latel wrote:
> On Monday, 4 May 2026 at 19:51, Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > On Mon, May 04, 2026 at 04:07:45PM +0000, Ⓐlï P☮latel wrote:
> > > Syd sandbox uses AF_ALG zero-copy for its Force Sandboxing[1] and Crypt Sandboxing[1].
> > > Zero-copy means Syd does not have to copy sandbox process data into its own address
> > > space providing safety and security. Switching to read/write rather than pipes and
> > > splice breaks a fundamental safety guarantee for the sandbox. Please do not break
> > > userspace.
> > >
> > > Will sendfile(2) continue to work?
> > >
> > > [1]: https://man.exherbo.org/syd.7.html#Force_Sandboxing
> > > [2]: https://man.exherbo.org/syd.7.html#Crypt_Sandboxing
> > 
> 
> > It's very unclear what that feature (which I don't think anyone knew
> > even existed) is trying to accomplish.  Regardless, this patch doesn't
> > break the splice or sendfile syscalls.  It just makes them run a bit
> > more slowly since the kernel will copy the data internally.  So I think
> > your concern isn't justified.
> > 
> 
> > > How can i test? Please help me.
> > 
> 
> > If this is a feature you care about, perhaps you know how to test it?
> 
> Thank you very much for the explanation and excuse me I panicked.
> 
> > - Eric

I've tested that all three cases of read/write, sendfile, and
vmsplice+splice still work.  The difference is just in how the kernel
implements them internally.  See the following test program.

#define _GNU_SOURCE
#include <assert.h>
#include <fcntl.h>
#include <linux/if_alg.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <sys/sendfile.h>
#include <sys/socket.h>
#include <unistd.h>

int main(void)
{
	for (int test = 0; test < 3; test++) {
		uint8_t msg[32] = {};
		uint8_t key[16] = {1,2,3,4};
		struct sockaddr_alg addr = {
			.salg_family = AF_ALG,
			.salg_type = "skcipher",
			.salg_name = "cbc(aes)",
		};
		int filefd, algfd, reqfd, pipefd[2], ret;

		filefd = open("msg_file", O_RDWR|O_CREAT|O_TRUNC, 0600);
		assert(filefd >= 0);
		ret = pwrite(filefd, msg, sizeof(msg), 0);
		assert(ret == sizeof(msg));

		algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
		assert(algfd >= 0);
		ret = bind(algfd, (struct sockaddr *)&addr, sizeof(addr));
		assert(ret == 0);
		ret = setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
		assert(ret == 0);

		reqfd = accept(algfd, NULL, NULL);
		assert(reqfd >= 0);

		switch (test) {
		case 0:
			printf("read/write test\n");
			ret = read(filefd, msg, sizeof(msg));
			assert(ret == sizeof(msg));
			ret = write(reqfd, msg, sizeof(msg));
			assert(ret == sizeof(msg));
			break;
		case 1:
			printf("sendfile test\n");
			ret = sendfile(reqfd, filefd, NULL, sizeof(msg));
			assert(ret == sizeof(msg));
			break;
		case 2:
			printf("splice test\n");
			ret = pipe(pipefd);
			assert(ret == 0);
			struct iovec iov = { .iov_base = msg, .iov_len = sizeof(msg) };
			ret = vmsplice(pipefd[1], &iov, 1, SPLICE_F_GIFT);
			assert(ret == sizeof(msg));
			ret = splice(pipefd[0], NULL, reqfd, NULL, sizeof(msg), SPLICE_F_MOVE);
			assert(ret == sizeof(msg));
			break;
		}
		ret = read(reqfd, msg, sizeof(msg));
		assert(ret == sizeof(msg));
		for (int i = 0; i < sizeof(msg); i++)
			printf("%02x ", msg[i]);
		printf("\n");
	}
}

      reply	other threads:[~2026-05-04 22:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-04  6:15 [PATCH] crypto: af_alg - Remove zero-copy support from AF_ALG Eric Biggers
2026-05-04  6:54 ` Demi Marie Obenour
2026-05-04  6:56   ` Eric Biggers
2026-05-04  6:59     ` Demi Marie Obenour
2026-05-04  7:07       ` Eric Biggers
2026-05-04  7:10         ` [PATCH v2] " Eric Biggers
2026-05-04  9:24           ` Eric Biggers
2026-05-04 22:53             ` [PATCH v3] crypto: af_alg - Remove zero-copy support from skcipher and aead Eric Biggers
2026-05-04 16:07 ` [PATCH] crypto: af_alg - Remove zero-copy support from AF_ALG Ⓐlï P☮latel
2026-05-04 17:47   ` Eric Biggers
2026-05-04 18:26     ` Ⓐlï P☮latel
2026-05-04 22:25       ` Eric Biggers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260504222518.GA21478@quark \
    --to=ebiggers@kernel.org \
    --cc=0wn@theori.io \
    --cc=alip@chesswob.org \
    --cc=bpak@theori.io \
    --cc=demiobenour@gmail.com \
    --cc=feng@innora.ai \
    --cc=herbert@gondor.apana.org.au \
    --cc=juno@theori.io \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=setuid0@theori.io \
    --cc=stable@vger.kernel.org \
    --cc=tjbecker@theori.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox