Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/814450/?format=api
{ "id": 814450, "url": "http://patchwork.ozlabs.org/api/patches/814450/?format=api", "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=api", "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=api", "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=api", "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": "<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>", "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 <patchwork-incoming@ozlabs.org>;\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 <patchwork-incoming@ozlabs.org>;\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 <linuxppc-dev@lists.ozlabs.org>;\n\tSat, 16 Sep 2017 11:21:45 +1000 (AEST)", "by mail-qk0-x241.google.com with SMTP id i14so2432927qke.3\n\tfor <linuxppc-dev@lists.ozlabs.org>;\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=<UNKNOWN>)", "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 <linuxram@us.ibm.com>", "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<linuxppc-dev.lists.ozlabs.org>", "List-Unsubscribe": "<https://lists.ozlabs.org/options/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=unsubscribe>", "List-Archive": "<http://lists.ozlabs.org/pipermail/linuxppc-dev/>", "List-Post": "<mailto:linuxppc-dev@lists.ozlabs.org>", "List-Help": "<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=help>", "List-Subscribe": "<https://lists.ozlabs.org/listinfo/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=subscribe>", "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<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>" }, "content": "Since PowerPC and Intel both support memory protection keys, moving\nthe documenation to arch-neutral directory.\n\nSigned-off-by: Ram Pai <linuxram@us.ibm.com>\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" ] }