From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16C39C433E0 for ; Fri, 12 Feb 2021 06:59:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 91B2C64E38 for ; Fri, 12 Feb 2021 06:59:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 91B2C64E38 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1855C8D0024; Fri, 12 Feb 2021 01:59:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 136408D0015; Fri, 12 Feb 2021 01:59:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 025128D0024; Fri, 12 Feb 2021 01:59:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0068.hostedemail.com [216.40.44.68]) by kanga.kvack.org (Postfix) with ESMTP id DDE708D0015 for ; Fri, 12 Feb 2021 01:59:45 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 97E2A180ACF84 for ; Fri, 12 Feb 2021 06:59:45 +0000 (UTC) X-FDA: 77808715530.13.64F102C Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf10.hostedemail.com (Postfix) with ESMTP id 86438407F8DF for ; Fri, 12 Feb 2021 06:59:43 +0000 (UTC) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 11C6eoiS150341; Fri, 12 Feb 2021 01:59:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : mime-version : content-type; s=pp1; bh=+TP7sP/ni7v6Ho3/L0taKftX1AIspyrtwn+pdk1k/DI=; b=M6J14FsgNtyYzijBEOd+vc2ijQrVPW/2C4W6yqhH4tUQXtpA0SMgsEjrQ6CC+YG6NAA4 GyKHDQJf7TJdyaNptyO8KZWZMTtWPjkP2r7z90lcn95EuDJZjA+qF/FcctUdT9UbOgJR +MKmpOvspFIb+3NVieFZ6W3GcDN5qBXypb2bSHxz+1lZNbxjjvQOs3PIqnjfNBjHhL+i vz1hQy4grCC3dBfclKen1QDvkXtIKDGTvXPZVvLIq+BWk/7qvmXMiy9LLU57fPxzvojN rCOfWb3mt9HjAt4hkzkU3OTaEHjE+B0ap5GULGmXgPpRw0Se8yd3AJs3tIbn1eB8rA5g MA== Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com with ESMTP id 36nma80j1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Feb 2021 01:59:38 -0500 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 11C6o8L5031418; Fri, 12 Feb 2021 06:59:37 GMT Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by ppma02wdc.us.ibm.com with ESMTP id 36hjra3aca-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Feb 2021 06:59:37 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 11C6xaLf30802198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 12 Feb 2021 06:59:36 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B2458AE063; Fri, 12 Feb 2021 06:59:36 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E49ECAE05F; Fri, 12 Feb 2021 06:59:34 +0000 (GMT) Received: from skywalker.linux.ibm.com (unknown [9.199.62.96]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 12 Feb 2021 06:59:34 +0000 (GMT) X-Mailer: emacs 27.1 (via feedmail 11-beta-1 I) From: "Aneesh Kumar K.V" To: Jens Axboe , Dave Hansen , Michael Ellerman 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 Message-ID: <877dndzs8c.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369,18.0.737 definitions=2021-02-12_01:2021-02-12,2021-02-11 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 mlxscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 bulkscore=0 clxscore=1011 adultscore=0 phishscore=0 mlxlogscore=869 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102120050 X-Stat-Signature: jqy541d48g1o1hqgmu7xj6i77ietcfut X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 86438407F8DF Received-SPF: none (linux.ibm.com>: No applicable sender policy available) receiver=imf10; identity=mailfrom; envelope-from=""; helo=mx0a-001b2d01.pphosted.com; client-ip=148.163.156.1 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1613113183-831408 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 #include #include #include #include #include #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