public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Jens Axboe <axboe@kernel.dk>, Dave Hansen <dave.hansen@intel.com>,
	Michael Ellerman <mpe@ellerman.id.au>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Memory keys and io_uring.
Date: Fri, 12 Feb 2021 12:29:31 +0530	[thread overview]
Message-ID: <877dndzs8c.fsf@linux.ibm.com> (raw)


Hi,

I am trying to estabilish the behaviour we should expect when passing a
buffer with memory keys attached to io_uring syscalls. As show  in the
blow test

/*
 * gcc -Wall -O2 -D_GNU_SOURCE -o pkey_uring pkey_uring.c -luring
 */
#include <stdio.h>
#include <fcntl.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#include "liburing.h"

#define PAGE_SIZE  (64 << 10)

int main(int argc, char *argv[])
{
	int fd, ret, pkey;
	struct io_uring ring;
	struct io_uring_sqe *sqe;
	struct io_uring_cqe *cqe;
	struct iovec iovec;
	void *buf;

	if (argc < 2) {
		printf("%s: file\n", argv[0]);
		return 1;
	}

	ret = io_uring_queue_init(1, &ring, IORING_SETUP_SQPOLL);
	if (ret < 0) {
		fprintf(stderr, "queue_init: %s\n", strerror(-ret));
		return 1;
	}

	fd = open(argv[1], O_RDONLY | O_DIRECT);
	if (fd < 0) {
		perror("open");
		return 1;
	}

	if (posix_memalign(&buf, PAGE_SIZE, PAGE_SIZE))
		return 1;
	iovec.iov_base = buf;
	iovec.iov_len = PAGE_SIZE;

	//mprotect(buf, PAGE_SIZE, PROT_NONE);
	pkey = pkey_alloc(0, PKEY_DISABLE_WRITE);
	pkey_mprotect(buf, PAGE_SIZE, PROT_READ | PROT_WRITE, pkey);


	sqe = io_uring_get_sqe(&ring);
	if (!sqe) {
		perror("io_uring_get_sqe");
		return 1;
	}
	io_uring_prep_readv(sqe, fd, &iovec, 1, 0);

	ret = io_uring_submit(&ring);
	if (ret != 1) {
		fprintf(stderr, "io_uring_submit: %s\n", strerror(-ret));
		return 1;
	}

	ret = io_uring_wait_cqe(&ring, &cqe);

	if (cqe->res < 0)
		fprintf(stderr, "iouring submit failed %s\n", strerror(-cqe->res));
	else
		fprintf(stderr, "iouring submit success\n");

	io_uring_cqe_seen(&ring, cqe);

	/*
	 * let's access this via a read syscall
	 */
	ret = read(fd, buf, PAGE_SIZE);
	if (ret < 0)
		fprintf(stderr, "read failed : %s\n", strerror(errno));

	close(fd);
	io_uring_queue_exit(&ring);

	return 0;
}

A read syscall do fail with EFAULT. But we allow read via io_uring
syscalls. Is that ok? Considering memory keys are thread-specific we
could debate that kernel thread can be considered to be the one that got all access
allowed via keys or we could update that access is denied via kernel
thread for any key value other than default key (key 0). Other option
is to inherit the memory key restrictions when doing
io_uring_submit() and use the same when accessing the userspace from
kernel thread. 

Any thoughts here with respect to what should be behaviour?

-aneesh

             reply	other threads:[~2021-02-12  7:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-12  6:59 Aneesh Kumar K.V [this message]
2021-02-12  7:30 ` Memory keys and io_uring Dave Hansen
2021-02-12 15:15 ` Jens Axboe
2021-02-12 15:33   ` Aneesh Kumar K.V
2021-02-12 15:37     ` Jens Axboe

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=877dndzs8c.fsf@linux.ibm.com \
    --to=aneesh.kumar@linux.ibm.com \
    --cc=axboe@kernel.dk \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpe@ellerman.id.au \
    /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