Cover Letter Detail
Show a cover letter.
GET /api/covers/816498/?format=api
{ "id": 816498, "url": "http://patchwork.ozlabs.org/api/covers/816498/?format=api", "web_url": "http://patchwork.ozlabs.org/project/netdev/cover/1505940337-79069-1-git-send-email-keescook@chromium.org/", "project": { "id": 7, "url": "http://patchwork.ozlabs.org/api/projects/7/?format=api", "name": "Linux network development", "link_name": "netdev", "list_id": "netdev.vger.kernel.org", "list_email": "netdev@vger.kernel.org", "web_url": null, "scm_url": null, "webscm_url": null, "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<1505940337-79069-1-git-send-email-keescook@chromium.org>", "list_archive_url": null, "date": "2017-09-20T20:45:06", "name": "[v3,00/31] Hardened usercopy whitelisting", "submitter": { "id": 10641, "url": "http://patchwork.ozlabs.org/api/people/10641/?format=api", "name": "Kees Cook", "email": "keescook@chromium.org" }, "mbox": "http://patchwork.ozlabs.org/project/netdev/cover/1505940337-79069-1-git-send-email-keescook@chromium.org/mbox/", "series": [ { "id": 4231, "url": "http://patchwork.ozlabs.org/api/series/4231/?format=api", "web_url": "http://patchwork.ozlabs.org/project/netdev/list/?series=4231", "date": "2017-09-20T20:45:22", "name": "Hardened usercopy whitelisting", "version": 3, "mbox": "http://patchwork.ozlabs.org/series/4231/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/covers/816498/comments/", "headers": { "Return-Path": "<netdev-owner@vger.kernel.org>", "X-Original-To": "patchwork-incoming@ozlabs.org", "Delivered-To": "patchwork-incoming@ozlabs.org", "Authentication-Results": [ "ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)", "ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"S+RPZtze\"; dkim-atps=neutral" ], "Received": [ "from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyBkK30WDz9s83\n\tfor <patchwork-incoming@ozlabs.org>;\n\tThu, 21 Sep 2017 06:51:53 +1000 (AEST)", "(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751809AbdITUqB (ORCPT <rfc822;patchwork-incoming@ozlabs.org>);\n\tWed, 20 Sep 2017 16:46:01 -0400", "from mail-pg0-f47.google.com ([74.125.83.47]:56503 \"EHLO\n\tmail-pg0-f47.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751678AbdITUp6 (ORCPT\n\t<rfc822;netdev@vger.kernel.org>); Wed, 20 Sep 2017 16:45:58 -0400", "by mail-pg0-f47.google.com with SMTP id 7so2323541pgd.13\n\tfor <netdev@vger.kernel.org>; Wed, 20 Sep 2017 13:45:57 -0700 (PDT)", "from www.outflux.net\n\t(173-164-112-133-Oregon.hfc.comcastbusiness.net. [173.164.112.133])\n\tby smtp.gmail.com with ESMTPSA id\n\tz26sm10002287pfa.49.2017.09.20.13.45.53\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 20 Sep 2017 13:45:54 -0700 (PDT)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=chromium.org; s=google;\n\th=from:to:cc:subject:date:message-id;\n\tbh=paAARrQG9KdS3SyW62Z8K9HBhRb7f/y2osBZPFn3QkA=;\n\tb=S+RPZtzeAmFObnJ+WOuqNEcLkibQJszcim6IktlR2kpzNDjPzdcaQtwMWCc/mLXX4I\n\tpf0yEwTbzkBoH3JcI91Z2bKGj7RVh+43LKEl3WXmAQNH+/JroATvNcX7uPJT46V+AW3q\n\twQQnDPw18wgLpkU0O6LGBvVDH+megaDMjATBA=", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:from:to:cc:subject:date:message-id;\n\tbh=paAARrQG9KdS3SyW62Z8K9HBhRb7f/y2osBZPFn3QkA=;\n\tb=ctO7cOl8SdOWvw/DEy3XlR2WSXdu3SRL9iLgWCY3BWNIb94SofDCbMemFVX7gmE+K1\n\tvAm+ykXsB6r1ilsTfGS7wQI8Esmtghx0cq8p5d1T83XgDoTQkIQFIXMl51TFh5hL2m0+\n\tdHtm5vCtJKkknEHcGOQovjRMlQkzRweyqXE1JgDJipKo3iiI3MFkxGznEIPleDTY4h4p\n\tWQaGT44BX8G0PFp2JaK6ap3JWN9SrZSjEeHT1PwXA6cRIG2n9Cm2QMPla5r+42sIZNUZ\n\tNiMMZXEDEpBqnHW8oNR1wjCRq+Pz7yQjC5vGgMf1qtYr1loLJCpqhVvsH3ENRRbfJLv1\n\tjATQ==", "X-Gm-Message-State": "AHPjjUjQ7/1nV9NmYv1RijKI6+OWqgbfrdYF+9yxDVvkYuEHhyrDWSSb\n\tACPx8X82Hyn89oa+UoivWIir93+lb0M=", "X-Google-Smtp-Source": "AOwi7QDxBCtmSK/hCrKdo+9MgvEL2TA3tA3Ka7m5727PvjDDEMoQVrBpGM9ySBOPyvgFF2PeWHYrcA==", "X-Received": "by 10.159.204.147 with SMTP id t19mr3273221plo.242.1505940357483;\n\tWed, 20 Sep 2017 13:45:57 -0700 (PDT)", "From": "Kees Cook <keescook@chromium.org>", "To": "linux-kernel@vger.kernel.org", "Cc": "Kees Cook <keescook@chromium.org>, linux-fsdevel@vger.kernel.org,\n\tnetdev@vger.kernel.org, linux-mm@kvack.org,\n\tkernel-hardening@lists.openwall.com, David Windsor <dave@nullcore.net>", "Subject": "[PATCH v3 00/31] Hardened usercopy whitelisting", "Date": "Wed, 20 Sep 2017 13:45:06 -0700", "Message-Id": "<1505940337-79069-1-git-send-email-keescook@chromium.org>", "X-Mailer": "git-send-email 2.7.4", "Sender": "netdev-owner@vger.kernel.org", "Precedence": "bulk", "List-ID": "<netdev.vger.kernel.org>", "X-Mailing-List": "netdev@vger.kernel.org" }, "content": "v3:\n- added LKDTM update patch\n- downgrade BUGs to WARNs and fail closed\n- add Acks/Reviews from v2\n\nv2:\n- added tracing of allocation and usage\n- refactored solutions for task_struct\n- split up network patches for readability\n\nI intend for this to land via my usercopy hardening tree, so Acks,\nReviewed, and Tested-bys would be greatly appreciated. I have some\nquestions in a few patches (e.g. CIFS and thread_stack) that would be nice\nto get answered for completeness. FWIW, this series has survived generally\nfor weeks in 0-day testing, and specifically over a couple days rebased\non v4.14-rc1, so I intend to put this in -next shortly unless there is\nfurther feedback.\n\n----\n\nThis series is modified from Brad Spengler/PaX Team's PAX_USERCOPY code\nin the last public patch of grsecurity/PaX based on our understanding\nof the code. Changes or omissions from the original code are ours and\ndon't reflect the original grsecurity/PaX code.\n\nDavid Windsor did the bulk of the porting, refactoring, splitting,\ntesting, etc; I did some extra tweaks, hunk moving, traces, and extra\npatches.\n\nDescription from patch 1:\n\n\nCurrently, hardened usercopy performs dynamic bounds checking on slab\ncache objects. This is good, but still leaves a lot of kernel memory\navailable to be copied to/from userspace in the face of bugs. To further\nrestrict what memory is available for copying, this creates a way to\nwhitelist specific areas of a given slab cache object for copying to/from\nuserspace, allowing much finer granularity of access control. Slab caches\nthat are never exposed to userspace can declare no whitelist for their\nobjects, thereby keeping them unavailable to userspace via dynamic copy\noperations. (Note, an implicit form of whitelisting is the use of constant\nsizes in usercopy operations and get_user()/put_user(); these bypass\nhardened usercopy checks since these sizes cannot change at runtime.)\n\nTo support this whitelist annotation, usercopy region offset and size\nmembers are added to struct kmem_cache. The slab allocator receives a\nnew function, kmem_cache_create_usercopy(), that creates a new cache\nwith a usercopy region defined, suitable for declaring spans of fields\nwithin the objects that get copied to/from userspace.\n\nIn this patch, the default kmem_cache_create() marks the entire allocation\nas whitelisted, leaving it semantically unchanged. Once all fine-grained\nwhitelists have been added (in subsequent patches), this will be changed\nto a usersize of 0, making caches created with kmem_cache_create() not\ncopyable to/from userspace.\n\nAfter the entire usercopy whitelist series is applied, less than 15%\nof the slab cache memory remains exposed to potential usercopy bugs\nafter a fresh boot:\n\nTotal Slab Memory: 48074720\nUsercopyable Memory: 6367532 13.2%\n task_struct 0.2% 4480/1630720\n RAW 0.3% 300/96000\n RAWv6 2.1% 1408/64768\n ext4_inode_cache 3.0% 269760/8740224\n dentry 11.1% 585984/5273856\n mm_struct 29.1% 54912/188448\n kmalloc-8 100.0% 24576/24576\n kmalloc-16 100.0% 28672/28672\n kmalloc-32 100.0% 81920/81920\n kmalloc-192 100.0% 96768/96768\n kmalloc-128 100.0% 143360/143360\n names_cache 100.0% 163840/163840\n kmalloc-64 100.0% 167936/167936\n kmalloc-256 100.0% 339968/339968\n kmalloc-512 100.0% 350720/350720\n kmalloc-96 100.0% 455616/455616\n kmalloc-8192 100.0% 655360/655360\n kmalloc-1024 100.0% 812032/812032\n kmalloc-4096 100.0% 819200/819200\n kmalloc-2048 100.0% 1310720/1310720\n\nAfter some kernel build workloads, the percentage (mainly driven by\ndentry and inode caches expanding) drops under 10%:\n\nTotal Slab Memory: 95516184\nUsercopyable Memory: 8497452 8.8%\n task_struct 0.2% 4000/1456000\n RAW 0.3% 300/96000\n RAWv6 2.1% 1408/64768\n ext4_inode_cache 3.0% 1217280/39439872\n dentry 11.1% 1623200/14608800\n mm_struct 29.1% 73216/251264\n kmalloc-8 100.0% 24576/24576\n kmalloc-16 100.0% 28672/28672\n kmalloc-32 100.0% 94208/94208\n kmalloc-192 100.0% 96768/96768\n kmalloc-128 100.0% 143360/143360\n names_cache 100.0% 163840/163840\n kmalloc-64 100.0% 245760/245760\n kmalloc-256 100.0% 339968/339968\n kmalloc-512 100.0% 350720/350720\n kmalloc-96 100.0% 563520/563520\n kmalloc-8192 100.0% 655360/655360\n kmalloc-1024 100.0% 794624/794624\n kmalloc-4096 100.0% 819200/819200\n kmalloc-2048 100.0% 1257472/1257472\n\n------\nThe patches are broken in several stages of changes:\n\nPrepare and whitelist kmalloc:\n [PATCH 01/31] usercopy: Prepare for usercopy whitelisting\n [PATCH 02/31] usercopy: Enforce slab cache usercopy region boundaries\n [PATCH 03/31] usercopy: Mark kmalloc caches as usercopy caches\n\nUpdate VFS layer for symlinks and other inline storage:\n [PATCH 04/31] dcache: Define usercopy region in dentry_cache slab\n [PATCH 05/31] vfs: Define usercopy region in names_cache slab caches\n [PATCH 06/31] vfs: Copy struct mount.mnt_id to userspace using\n [PATCH 07/31] ext4: Define usercopy region in ext4_inode_cache slab\n [PATCH 08/31] ext2: Define usercopy region in ext2_inode_cache slab\n [PATCH 09/31] jfs: Define usercopy region in jfs_ip slab cache\n [PATCH 10/31] befs: Define usercopy region in befs_inode_cache slab\n [PATCH 11/31] exofs: Define usercopy region in exofs_inode_cache slab\n [PATCH 12/31] orangefs: Define usercopy region in\n [PATCH 13/31] ufs: Define usercopy region in ufs_inode_cache slab\n [PATCH 14/31] vxfs: Define usercopy region in vxfs_inode slab cache\n [PATCH 15/31] xfs: Define usercopy region in xfs_inode slab cache\n [PATCH 16/31] cifs: Define usercopy region in cifs_request slab cache\n\nUpdate scsi layer for inline storage:\n [PATCH 17/31] scsi: Define usercopy region in scsi_sense_cache slab\n\nWhitelist a few network protocol-specific areas of memory:\n [PATCH 18/31] net: Define usercopy region in struct proto slab cache\n [PATCH 19/31] ip: Define usercopy region in IP proto slab cache\n [PATCH 20/31] caif: Define usercopy region in caif proto slab cache\n [PATCH 21/31] sctp: Define usercopy region in SCTP proto slab cache\n [PATCH 22/31] sctp: Copy struct sctp_sock.autoclose to userspace\n [PATCH 23/31] net: Restrict unwhitelisted proto caches to size 0\n\nWhitelist areas of process memory:\n [PATCH 24/31] fork: Define usercopy region in mm_struct slab caches\n [PATCH 25/31] fork: Define usercopy region in thread_stack slab\n\nDeal with per-architecture thread_struct whitelisting:\n [PATCH 26/31] fork: Provide usercopy whitelisting for task_struct\n [PATCH 27/31] x86: Implement thread_struct whitelist for hardened\n [PATCH 28/31] arm64: Implement thread_struct whitelist for hardened\n [PATCH 29/31] arm: Implement thread_struct whitelist for hardened\n\nMake blacklisting the default:\n [PATCH 30/31] usercopy: Restrict non-usercopy caches to size 0\n\nUpdate LKDTM:\n [PATCH 31/31] lkdtm: Update usercopy tests for whitelisting\n\n\nThanks!\n\n-Kees (and David)" }