{"id":814450,"url":"http://patchwork.ozlabs.org/api/patches/814450/?format=json","web_url":"http://patchwork.ozlabs.org/project/linuxppc-dev/patch/1505524870-4783-6-git-send-email-linuxram@us.ibm.com/","project":{"id":2,"url":"http://patchwork.ozlabs.org/api/projects/2/?format=json","name":"Linux PPC development","link_name":"linuxppc-dev","list_id":"linuxppc-dev.lists.ozlabs.org","list_email":"linuxppc-dev@lists.ozlabs.org","web_url":"https://github.com/linuxppc/wiki/wiki","scm_url":"https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git","webscm_url":"https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/","list_archive_url":"https://lore.kernel.org/linuxppc-dev/","list_archive_url_format":"https://lore.kernel.org/linuxppc-dev/{}/","commit_url_format":"https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id={}"},"msgid":"<1505524870-4783-6-git-send-email-linuxram@us.ibm.com>","list_archive_url":"https://lore.kernel.org/linuxppc-dev/1505524870-4783-6-git-send-email-linuxram@us.ibm.com/","date":"2017-09-16T01:21:09","name":"[5/6] Documentation/x86: Move protecton key documentation to arch neutral directory","commit_ref":null,"pull_url":null,"state":"changes-requested","archived":false,"hash":"40a89e3f58b43460fc3d411dbc4181f938cfe841","submitter":{"id":2667,"url":"http://patchwork.ozlabs.org/api/people/2667/?format=json","name":"Ram Pai","email":"linuxram@us.ibm.com"},"delegate":null,"mbox":"http://patchwork.ozlabs.org/project/linuxppc-dev/patch/1505524870-4783-6-git-send-email-linuxram@us.ibm.com/mbox/","series":[{"id":3406,"url":"http://patchwork.ozlabs.org/api/series/3406/?format=json","web_url":"http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=3406","date":"2017-09-16T01:21:04","name":"mm, x86, powerpc: Memory Protection Keys enhancement","version":1,"mbox":"http://patchwork.ozlabs.org/series/3406/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/patches/814450/comments/","check":"pending","checks":"http://patchwork.ozlabs.org/api/patches/814450/checks/","tags":{},"related":[],"headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xvFBy2r3fz9t2l\n\tfor ;\n\tSat, 16 Sep 2017 11:32:58 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xvFBx5S8JzDqZC\n\tfor ;\n\tSat, 16 Sep 2017 11:32:57 +1000 (AEST)","from mail-qk0-x241.google.com (mail-qk0-x241.google.com\n\t[IPv6:2607:f8b0:400d:c09::241])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xvDy14rYnzDrcM\n\tfor ;\n\tSat, 16 Sep 2017 11:21:45 +1000 (AEST)","by mail-qk0-x241.google.com with SMTP id i14so2432927qke.3\n\tfor ;\n\tFri, 15 Sep 2017 18:21:45 -0700 (PDT)","from localhost.localdomain (50-39-103-96.bvtn.or.frontiernet.net.\n\t[50.39.103.96]) by smtp.gmail.com with ESMTPSA id\n\tv11sm1493189qkl.45.2017.09.15.18.21.41\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 15 Sep 2017 18:21:43 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"sVTDpI9y\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"sVTDpI9y\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400d:c09::241; helo=mail-qk0-x241.google.com;\n\tenvelope-from=ram.n.pai@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"sVTDpI9y\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=sender:from:to:cc:subject:date:message-id:in-reply-to:references;\n\tbh=vO1RSocbkKTl6LNIS3WVbAw0hlfpHietNqQ/jfLRQ9U=;\n\tb=sVTDpI9y2YtlsaJP+xEeu4UySTaLCWjBoGz3v6yMw2BkT0oIOhT52NbPqkSFqMb3Nh\n\thkZ+qAKllqvyZDCuAwECo4GkSqKbjdk7036T8CzTfMKdsu4byMY+Epzo0L5Ya1ic6Sp0\n\t2DI9bVEukkVjKN21s9Epcs4c90YRFQbbx1OsEH56Os3VbXQXxPgxhgLptZMb4Q+MVQ3J\n\tSOqe/VejkzrH942ggeC5STdcnEk8sVIw5EN5IqDI/w169qBsl2gEkCWVSXNVmVnCo8Hc\n\t72pIBZ4EBf4MBFA16okILWI+b/tT91uNlCnzrAE3pgvMQVjIQekL8dJnqPRsAPnRA2qp\n\tFLTA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:sender:from:to:cc:subject:date:message-id\n\t:in-reply-to:references;\n\tbh=vO1RSocbkKTl6LNIS3WVbAw0hlfpHietNqQ/jfLRQ9U=;\n\tb=txi9deBBOPdrwgAQ4fjEimsCkp5HJPlYjvFwYh9UljI/DzhIkvg1PLSLoDo0nvLr1U\n\tCuGbVvh2n52PVYVfOwty2mVzXQSXTwJ1D+mQ8UngkPfhP6c4SDvJCcgDlVAH046vVBUE\n\tZbIIc3ruLDDurkUOSyh46jglC0aoSbbz399jSg/UF23EUA0COj6qDIumnHJButJs+wsa\n\tBbHVvO3I1vc24ENw43MmHmCElt+dtvgIJFnbBsG2MqSHPat+ZLY/ttn62tYBLFeYfrSl\n\tsGiJbWhsoMBzKcmtiTqnjluPCt06uLAEuxEhddkz4UjIyBpIpuBANPiTobu/11CemgXB\n\t7Z5w==","X-Gm-Message-State":"AHPjjUjVug15pL3uy3wZI8YctmAV6ED0t1pjkIbSlh2+QfMUHHrTSFai\n\tkktG+5FW+fY7ww==","X-Google-Smtp-Source":"AOwi7QDElDcB/v03scxuuaCccDIe9CEjagpSENq8ksXY3K15sH4U8swJFOoCDPKs/iNjnyU3FsY05w==","X-Received":"by 10.55.164.12 with SMTP id n12mr10687167qke.246.1505524903641; \n\tFri, 15 Sep 2017 18:21:43 -0700 (PDT)","From":"Ram Pai ","To":"mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,\n\tlinux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,\n\tlinux-mm@kvack.org, x86@kernel.org, linux-doc@vger.kernel.org","Subject":"[PATCH 5/6] Documentation/x86: Move protecton key documentation to\n\tarch neutral directory","Date":"Fri, 15 Sep 2017 18:21:09 -0700","Message-Id":"<1505524870-4783-6-git-send-email-linuxram@us.ibm.com>","X-Mailer":"git-send-email 1.7.1","In-Reply-To":"<1505524870-4783-1-git-send-email-linuxram@us.ibm.com>","References":"<1505524870-4783-1-git-send-email-linuxram@us.ibm.com>","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"ebiederm@xmission.com, arnd@arndb.de, corbet@lwn.net, linuxram@us.ibm.com,\n\tmhocko@kernel.org, mingo@redhat.com, paulus@samba.org,\n\taneesh.kumar@linux.vnet.ibm.com, bauerman@linux.vnet.ibm.com,\n\takpm@linux-foundation.org, khandual@linux.vnet.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"},"content":"Since PowerPC and Intel both support memory protection keys, moving\nthe documenation to arch-neutral directory.\n\nSigned-off-by: Ram Pai \n---\n Documentation/vm/protection-keys.txt | 85 +++++++++++++++++++++++++++++++++\n Documentation/x86/protection-keys.txt | 85 ---------------------------------\n 2 files changed, 85 insertions(+), 85 deletions(-)\n create mode 100644 Documentation/vm/protection-keys.txt\n delete mode 100644 Documentation/x86/protection-keys.txt","diff":"diff --git a/Documentation/vm/protection-keys.txt b/Documentation/vm/protection-keys.txt\nnew file mode 100644\nindex 0000000..b643045\n--- /dev/null\n+++ b/Documentation/vm/protection-keys.txt\n@@ -0,0 +1,85 @@\n+Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature\n+which will be found on future Intel CPUs.\n+\n+Memory Protection Keys provides a mechanism for enforcing page-based\n+protections, but without requiring modification of the page tables\n+when an application changes protection domains. It works by\n+dedicating 4 previously ignored bits in each page table entry to a\n+\"protection key\", giving 16 possible keys.\n+\n+There is also a new user-accessible register (PKRU) with two separate\n+bits (Access Disable and Write Disable) for each key. Being a CPU\n+register, PKRU is inherently thread-local, potentially giving each\n+thread a different set of protections from every other thread.\n+\n+There are two new instructions (RDPKRU/WRPKRU) for reading and writing\n+to the new register. The feature is only available in 64-bit mode,\n+even though there is theoretically space in the PAE PTEs. These\n+permissions are enforced on data access only and have no effect on\n+instruction fetches.\n+\n+=========================== Syscalls ===========================\n+\n+There are 3 system calls which directly interact with pkeys:\n+\n+\tint pkey_alloc(unsigned long flags, unsigned long init_access_rights)\n+\tint pkey_free(int pkey);\n+\tint pkey_mprotect(unsigned long start, size_t len,\n+\t\t\t unsigned long prot, int pkey);\n+\n+Before a pkey can be used, it must first be allocated with\n+pkey_alloc(). An application calls the WRPKRU instruction\n+directly in order to change access permissions to memory covered\n+with a key. In this example WRPKRU is wrapped by a C function\n+called pkey_set().\n+\n+\tint real_prot = PROT_READ|PROT_WRITE;\n+\tpkey = pkey_alloc(0, PKEY_DENY_WRITE);\n+\tptr = mmap(NULL, PAGE_SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);\n+\tret = pkey_mprotect(ptr, PAGE_SIZE, real_prot, pkey);\n+\t... application runs here\n+\n+Now, if the application needs to update the data at 'ptr', it can\n+gain access, do the update, then remove its write access:\n+\n+\tpkey_set(pkey, 0); // clear PKEY_DENY_WRITE\n+\t*ptr = foo; // assign something\n+\tpkey_set(pkey, PKEY_DENY_WRITE); // set PKEY_DENY_WRITE again\n+\n+Now when it frees the memory, it will also free the pkey since it\n+is no longer in use:\n+\n+\tmunmap(ptr, PAGE_SIZE);\n+\tpkey_free(pkey);\n+\n+(Note: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions.\n+ An example implementation can be found in\n+ tools/testing/selftests/x86/protection_keys.c)\n+\n+=========================== Behavior ===========================\n+\n+The kernel attempts to make protection keys consistent with the\n+behavior of a plain mprotect(). For instance if you do this:\n+\n+\tmprotect(ptr, size, PROT_NONE);\n+\tsomething(ptr);\n+\n+you can expect the same effects with protection keys when doing this:\n+\n+\tpkey = pkey_alloc(0, PKEY_DISABLE_WRITE | PKEY_DISABLE_READ);\n+\tpkey_mprotect(ptr, size, PROT_READ|PROT_WRITE, pkey);\n+\tsomething(ptr);\n+\n+That should be true whether something() is a direct access to 'ptr'\n+like:\n+\n+\t*ptr = foo;\n+\n+or when the kernel does the access on the application's behalf like\n+with a read():\n+\n+\tread(fd, ptr, 1);\n+\n+The kernel will send a SIGSEGV in both cases, but si_code will be set\n+to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when\n+the plain mprotect() permissions are violated.\ndiff --git a/Documentation/x86/protection-keys.txt b/Documentation/x86/protection-keys.txt\ndeleted file mode 100644\nindex b643045..0000000\n--- a/Documentation/x86/protection-keys.txt\n+++ /dev/null\n@@ -1,85 +0,0 @@\n-Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature\n-which will be found on future Intel CPUs.\n-\n-Memory Protection Keys provides a mechanism for enforcing page-based\n-protections, but without requiring modification of the page tables\n-when an application changes protection domains. It works by\n-dedicating 4 previously ignored bits in each page table entry to a\n-\"protection key\", giving 16 possible keys.\n-\n-There is also a new user-accessible register (PKRU) with two separate\n-bits (Access Disable and Write Disable) for each key. Being a CPU\n-register, PKRU is inherently thread-local, potentially giving each\n-thread a different set of protections from every other thread.\n-\n-There are two new instructions (RDPKRU/WRPKRU) for reading and writing\n-to the new register. The feature is only available in 64-bit mode,\n-even though there is theoretically space in the PAE PTEs. These\n-permissions are enforced on data access only and have no effect on\n-instruction fetches.\n-\n-=========================== Syscalls ===========================\n-\n-There are 3 system calls which directly interact with pkeys:\n-\n-\tint pkey_alloc(unsigned long flags, unsigned long init_access_rights)\n-\tint pkey_free(int pkey);\n-\tint pkey_mprotect(unsigned long start, size_t len,\n-\t\t\t unsigned long prot, int pkey);\n-\n-Before a pkey can be used, it must first be allocated with\n-pkey_alloc(). An application calls the WRPKRU instruction\n-directly in order to change access permissions to memory covered\n-with a key. In this example WRPKRU is wrapped by a C function\n-called pkey_set().\n-\n-\tint real_prot = PROT_READ|PROT_WRITE;\n-\tpkey = pkey_alloc(0, PKEY_DENY_WRITE);\n-\tptr = mmap(NULL, PAGE_SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);\n-\tret = pkey_mprotect(ptr, PAGE_SIZE, real_prot, pkey);\n-\t... application runs here\n-\n-Now, if the application needs to update the data at 'ptr', it can\n-gain access, do the update, then remove its write access:\n-\n-\tpkey_set(pkey, 0); // clear PKEY_DENY_WRITE\n-\t*ptr = foo; // assign something\n-\tpkey_set(pkey, PKEY_DENY_WRITE); // set PKEY_DENY_WRITE again\n-\n-Now when it frees the memory, it will also free the pkey since it\n-is no longer in use:\n-\n-\tmunmap(ptr, PAGE_SIZE);\n-\tpkey_free(pkey);\n-\n-(Note: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions.\n- An example implementation can be found in\n- tools/testing/selftests/x86/protection_keys.c)\n-\n-=========================== Behavior ===========================\n-\n-The kernel attempts to make protection keys consistent with the\n-behavior of a plain mprotect(). For instance if you do this:\n-\n-\tmprotect(ptr, size, PROT_NONE);\n-\tsomething(ptr);\n-\n-you can expect the same effects with protection keys when doing this:\n-\n-\tpkey = pkey_alloc(0, PKEY_DISABLE_WRITE | PKEY_DISABLE_READ);\n-\tpkey_mprotect(ptr, size, PROT_READ|PROT_WRITE, pkey);\n-\tsomething(ptr);\n-\n-That should be true whether something() is a direct access to 'ptr'\n-like:\n-\n-\t*ptr = foo;\n-\n-or when the kernel does the access on the application's behalf like\n-with a read():\n-\n-\tread(fd, ptr, 1);\n-\n-The kernel will send a SIGSEGV in both cases, but si_code will be set\n-to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when\n-the plain mprotect() permissions are violated.\n","prefixes":["5/6"]}