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");
}
}
prev parent 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