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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79AE4CF34D0 for ; Thu, 3 Oct 2024 22:54:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECFD56B0136; Thu, 3 Oct 2024 18:54:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E7F786B013A; Thu, 3 Oct 2024 18:54:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF9A96B013C; Thu, 3 Oct 2024 18:54:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A76136B0136 for ; Thu, 3 Oct 2024 18:54:24 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 26DE6140CEB for ; Thu, 3 Oct 2024 22:54:24 +0000 (UTC) X-FDA: 82633796448.02.44375A8 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by imf27.hostedemail.com (Postfix) with ESMTP id 62EBB40002 for ; Thu, 3 Oct 2024 22:54:21 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=TSRb4+f2; spf=none (imf27.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=rdunlap@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727995932; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jJZr/c0oAgH8cdTeE/0r4dud+17iSiVhMtQZx6SScGk=; b=mzraDy1tm8OQia8bGYpjK0sx1W6Cvo480AMNCb5FhxHEw8wc719a72VuluNhOdcKv7R/9q l5445phGckXpIXGH78fmSZ6WmRQVmu+jycH0ueEmBTQelca8pRVATu3+/l+fOQkt4l87ea HanBQTCUNXqUR8s5MTxlLFyg8/BXOdU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727995932; a=rsa-sha256; cv=none; b=yaT/wp/DKRoCD3YQoj5RSHdXTtYNppogdWpOe58xps2a5cIyDWJ0QR8L3sTxUC11leiS8z 6HTz2KFFt/B0MaCTfZ082epnKTT/sTXycjYRw/7ES9JHEW+0uoCrRLiRw8YayFjmuk4jXm AEq/xLQ2ATJaKFbUpGp644lDGLfF4oc= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=TSRb4+f2; spf=none (imf27.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=rdunlap@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:Content-Type :In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID: Sender:Reply-To:Content-ID:Content-Description; bh=jJZr/c0oAgH8cdTeE/0r4dud+17iSiVhMtQZx6SScGk=; b=TSRb4+f2T4iLevWIHxEDuwgwDF hV3hNnq0LsjVb5nZv1lnFH/ax03pWWyZLW2lxTQmDT19pCeGlNWKmcls3A+NAAqxEbAt0Km2aF1Ag 5mamssqul1MLUX9xplfynbW4SngUUCkUJJJCA3mtbGhwshD4wK6ouc0R+PLpVZj/QTbhu860w7yBD T5AeUKUtuHU5GWg4yYaYuF+Ih8pWmd6tTdISSi9D1/05FE+6IyWcXjGyluIs4DVMoD6WWcXkpQx8R K7LTlenKBc5xzAfusXIgp9PY/o6DcJT7X5uKLtP4lOTXQAi4eMPNMISQOSjN+SjEOqS7YMX4PRo5p Xy3pcT7A==; Received: from [50.53.2.24] (helo=[192.168.254.17]) by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1swUhv-00000003kjU-3EXJ; Thu, 03 Oct 2024 22:54:11 +0000 Message-ID: <4544a4b3-d5b6-4f6b-b3d5-6c309eb8fa9d@infradead.org> Date: Thu, 3 Oct 2024 15:53:54 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] mseal: update mseal.rst To: jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, corbet@lwn.net Cc: jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jannh@google.com, sroettger@google.com, pedro.falcato@gmail.com, linux-hardening@vger.kernel.org, willy@infradead.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, deraadt@openbsd.org, usama.anjum@collabora.com, surenb@google.com, merimus@google.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, enh@google.com References: <20241001002628.2239032-1-jeffxu@chromium.org> <20241001002628.2239032-2-jeffxu@chromium.org> Content-Language: en-US From: Randy Dunlap In-Reply-To: <20241001002628.2239032-2-jeffxu@chromium.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 62EBB40002 X-Stat-Signature: z5s9jegot6si5b3ezw5he6ox5ahx8z73 X-HE-Tag: 1727996061-8216 X-HE-Meta: U2FsdGVkX19Ut5AkZQ3SWuHo8CVwM8iru2IChq5ocSLEM4uThcmLxgE6GT4SqMhe6lR/dAou5qAo21S2z56rOy364om+qdq0xqfaXMqDod5uTsi+hovTamvVCTQmqaJxvT7/uP7gxUzZODkeonvuEqntKm1GaZRjHLfqL4tHzOjJIbPw6Km1qOT1PwhC4tktXJwKdh22MjZ8v3ZSN5inVFkhkf1jxatpCN9Bm7PusMSFKW941Pq6+I0JxKp4C6U2dbroSPCsytEuhP4jhSuhI+CHP47Pzh/QJJOTty1CYEmyOh/tEubfdzGZ8jaCWgvi7w29m04cl56aAbA+ojmf3cNtCctdLKmibetBQp3O0goN+L7SXYvfmAtqpy/+jt3od8TUmNKMOgLKz+gxqBA8Ecx6L7kSU+YAWrelyTszYfkVmB6tOXlaZlUjNlHctVkAynDeCFK7IRF9GO1J55A1PiHw3Mrh8etnsIWKTwIPcF9ZN/qgyYDISvwklCoEQqY+rmSKQzmDwXDdsIObwLJiwUZBQ0Vq70h5pLwiLX6sosQQEoMfRRBIIX3N/5rWJFjceZHUZwgOn9mQG1NlXJgPY0jQyOTEWyPe7uXhqky5ohRnT1vSj+6NdDctv2V4ofw12VWNGFyQZ1CNRTg9yeLc0olPFhq4BSnMM0uPv+P7ZScQxtiLsHwlD5FxE+ZU5/S96JTn8kijjnS9Xbe2BZaHxiFhRsrlyAPI86ecbOuDuDHHJOH9WEwlrlqlaELfsKhlssd1uxMVQ/bE7LccI9fyPUnO2hqQKV5vfSKnQj0nF2+mBHq27hWid2WKdV4sImiEWUPJqk3tZtdcN1fuwoq8tTDpnoqI0N8NvPnoMxRiz5GAB4dMpLI/NJH951qcWWNFULX1J4/aNwSvOHYmfM3aBMrlk+NXsJ8wbkWxBut40o6yoPfHqbxA2nc8OJwj5b1kBXX9KdDZQTN743tzzT2 Be3Ublfu nU9wvhzDOUYGsxslNvobXM3kmv0K7uQCvdb4K/1YRf3Bdi+dEpMciL7Z8Qp85VulWSgltUqF6nG9Grq693VV0V0MExKxQw9edeTJ3T0E/D2x29EAXALiV47nln9kUL787JG9m9gf4onOIM1OfUn7hYedkX9gZbq6+Xoii734NEWjnphkd17JaGUK1bqwSb7gefloBjRPlbsuNOMzt+zVTrQ//KlELvhG+rB0sRE4Cr1mvQyiuWIbNUajEJgkWK4hxBzGBgDxyVmvUErnsJ4owkWDEZBGHc0XkLzYJsrufFSXkxrsvdOxj2zrP2iKRTZFsSGVkjqs6XV5P0dTz/IZBXbczCPWow9mTC3FXYIV458xZkCLpTYRLl+cYPdkc3bJIlyu5n/l0EATwjfZs43fG52YDu3Vo2CC++Fo2/A0NLmQPz2j70la5BXXWjNYd8oYBKc1N6Wf0/KzI1/VSn+NpI+vaZQNnWo5igTRXr7LcvWujGcSpvOQs2ncv6SJwGd8V0/D+1ZJ94NY/01m3GsEKC2WYYv/shjxxDpons2VnCXjcq/aiOSelOL3aCoShf7pyephn3VuAXccv4cIllghpXLXG7e4I3wTBLt09lDI0298A4zf93LF+dd0UwOG75v4s/vC4 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: List-Subscribe: List-Unsubscribe: Hi Jeff, Sorry for the delay. Thanks for your v2 updates. On 9/30/24 5:26 PM, jeffxu@chromium.org wrote: > From: Jeff Xu > > Update doc after in-loop change: mprotect/madvise can have > partially updated and munmap is atomic. > > Fix indentation and clarify some sections to improve readability. > > Signed-off-by: Jeff Xu > Fixes: df2a7df9a9aa ("mm/munmap: replace can_modify_mm with can_modify_vma") > Fixes: 4a2dd02b0916 ("mm/mprotect: replace can_modify_mm with can_modify_vma") > Fixes: 38075679b5f1 ("mm/mremap: replace can_modify_mm with can_modify_vma") > Fixes: 23c57d1fa2b9 ("mseal: replace can_modify_mm_madv with a vma variant") > --- > Documentation/userspace-api/mseal.rst | 304 ++++++++++++-------------- > 1 file changed, 144 insertions(+), 160 deletions(-) > > diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst > index 4132eec995a3..04d34b5adb8f 100644 > --- a/Documentation/userspace-api/mseal.rst > +++ b/Documentation/userspace-api/mseal.rst > @@ -23,177 +23,161 @@ applications can additionally seal security critical data at runtime. > A similar feature already exists in the XNU kernel with the > VM_FLAGS_PERMANENT flag [1] and on OpenBSD with the mimmutable syscall [2]. > > -User API > -======== > -mseal() > ------------ > -The mseal() syscall has the following signature: > - > -``int mseal(void addr, size_t len, unsigned long flags)`` > - > -**addr/len**: virtual memory address range. > - > -The address range set by ``addr``/``len`` must meet: > - - The start address must be in an allocated VMA. > - - The start address must be page aligned. > - - The end address (``addr`` + ``len``) must be in an allocated VMA. > - - no gap (unallocated memory) between start and end address. > - > -The ``len`` will be paged aligned implicitly by the kernel. > - > -**flags**: reserved for future use. > - > -**return values**: > - > -- ``0``: Success. > - > -- ``-EINVAL``: > - - Invalid input ``flags``. > - - The start address (``addr``) is not page aligned. > - - Address range (``addr`` + ``len``) overflow. > - > -- ``-ENOMEM``: > - - The start address (``addr``) is not allocated. > - - The end address (``addr`` + ``len``) is not allocated. > - - A gap (unallocated memory) between start and end address. > - > -- ``-EPERM``: > - - sealing is supported only on 64-bit CPUs, 32-bit is not supported. > - > -- For above error cases, users can expect the given memory range is > - unmodified, i.e. no partial update. > - > -- There might be other internal errors/cases not listed here, e.g. > - error during merging/splitting VMAs, or the process reaching the max > - number of supported VMAs. In those cases, partial updates to the given > - memory range could happen. However, those cases should be rare. > - > -**Blocked operations after sealing**: > - Unmapping, moving to another location, and shrinking the size, > - via munmap() and mremap(), can leave an empty space, therefore > - can be replaced with a VMA with a new set of attributes. > - > - Moving or expanding a different VMA into the current location, > - via mremap(). > - > - Modifying a VMA via mmap(MAP_FIXED). > - > - Size expansion, via mremap(), does not appear to pose any > - specific risks to sealed VMAs. It is included anyway because > - the use case is unclear. In any case, users can rely on > - merging to expand a sealed VMA. > - > - mprotect() and pkey_mprotect(). > - > - Some destructive madvice() behaviors (e.g. MADV_DONTNEED) > - for anonymous memory, when users don't have write permission to the > - memory. Those behaviors can alter region contents by discarding pages, > - effectively a memset(0) for anonymous memory. > - > - Kernel will return -EPERM for blocked operations. > - > - For blocked operations, one can expect the given address is unmodified, > - i.e. no partial update. Note, this is different from existing mm > - system call behaviors, where partial updates are made till an error is > - found and returned to userspace. To give an example: > - > - Assume following code sequence: > - > - - ptr = mmap(null, 8192, PROT_NONE); > - - munmap(ptr + 4096, 4096); > - - ret1 = mprotect(ptr, 8192, PROT_READ); > - - mseal(ptr, 4096); > - - ret2 = mprotect(ptr, 8192, PROT_NONE); > - > - ret1 will be -ENOMEM, the page from ptr is updated to PROT_READ. > - > - ret2 will be -EPERM, the page remains to be PROT_READ. > - > -**Note**: > - > -- mseal() only works on 64-bit CPUs, not 32-bit CPU. > - > -- users can call mseal() multiple times, mseal() on an already sealed memory > - is a no-action (not error). > - > -- munseal() is not supported. > - > -Use cases: > -========== > +SYSCALL > +======= > +mseal syscall signature > +----------------------- > + ``int mseal(void \* addr, size_t len, unsigned long flags)`` > + > + **addr**/**len**: virtual memory address range. > + The address range set by **addr**/**len** must meet: > + - The start address must be in an allocated VMA. > + - The start address must be page aligned. > + - The end address (**addr** + **len**) must be in an allocated VMA. > + - no gap (unallocated memory) between start and end address. > + > + The ``len`` will be paged aligned implicitly by the kernel. > + > + **flags**: reserved for future use. > + > + **Return values**: > + - **0**: Success. > + - **-EINVAL**: > + * Invalid input ``flags``. > + * The start address (``addr``) is not page aligned. > + * Address range (``addr`` + ``len``) overflow. > + - **-ENOMEM**: > + * The start address (``addr``) is not allocated. > + * The end address (``addr`` + ``len``) is not allocated. > + * A gap (unallocated memory) between start and end address. > + - **-EPERM**: > + * sealing is supported only on 64-bit CPUs, 32-bit is not supported. > + > + **Note about error return**: > + - For above error cases, users can expect the given memory range is > + unmodified, i.e. no partial update. > + - There might be other internal errors/cases not listed here, e.g. > + error during merging/splitting VMAs, or the process reaching the max maximum > + number of supported VMAs. In those cases, partial updates to the given > + memory range could happen. However, those cases should be rare. > + > + **Architecture support**: > + mseal only works on 64-bit CPUs, not 32-bit CPUs. > + > + **Idempotent**: > + users can call mseal multiple times. mseal on an already sealed memory > + is a no-action (not error). > + > + **no munseal** > + Once mapping is sealed, it can't be unsealed. kernel should never The kernel > + have munseal, this is consistent with other sealing feature, e.g. > + F_SEAL_SEAL for file. > + > +Blocked mm syscall for sealed mapping > +------------------------------------- > + It might be important to note: **once the mapping is sealed, it will > + stay in the process's memory until the process terminates**. > + > + Example:: > + > + *ptr = mmap(0, 4096, PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, 0, 0); > + rc = mseal(ptr, 4096, 0); > + /* munmap will fail */ > + rc = munmap(ptr, 4096); > + assert(rc < 0); > + > + Blocked mm syscall: > + - munmap > + - mmap > + - mremap > + - mprotect and pkey_mprotect > + - some destructive madvise behaviors: MADV_DONTNEED, MADV_FREE, > + MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, MADV_WIPEONFORK > + > + The first set of syscall to block is munmap, mremap, mmap. They can syscalls > + either leave an empty space in the address space, therefore allow allowing > + replacement with a new mapping with new set of attributes, or can > + overwrite the existing mapping with another mapping. > + > + mprotect and pkey_mprotect are blocked because they changes the > + protection bits (RWX) of the mapping. > + > + Some destructive madvise behaviors (MADV_DONTNEED, MADV_FREE,> + MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, MADV_WIPEONFORK) > + for anonymous memory, when users don't have write permission to the > + memory. Those behaviors can alter region contents by discarding pages, above is not a sentence but I don't know how to fix it. > + effectively a memset(0) for anonymous memory. > + > + Kernel will return -EPERM for blocked syscalls. > + > + When blocked syscall return -EPERM due to sealing, the memory regions may or may not be changed, depends on the syscall being blocked: a blocked syscall returns depending on and split that line into 2 lines. > + - munmap: munmap is atomic. If one of VMAs in the given range is > + sealed, none of VMAs are updated. > + - mprotect, pkey_mprotect, madvise: partial update might happen, e.g. > + when mprotect over multiple VMAs, mprotect might update the beginning > + VMAs before reaching the sealed VMA and return -EPERM. > + - mmap and mremap: undefined behavior. > + > +Use cases > +========= > - glibc: > The dynamic linker, during loading ELF executables, can apply sealing to > - non-writable memory segments. > - > -- Chrome browser: protect some security sensitive data-structures. > + mapping segments. > > -Notes on which memory to seal: > -============================== > +- Chrome browser: protect some security sensitive data structures. > > -It might be important to note that sealing changes the lifetime of a mapping, > -i.e. the sealed mapping won’t be unmapped till the process terminates or the > -exec system call is invoked. Applications can apply sealing to any virtual > -memory region from userspace, but it is crucial to thoroughly analyze the > -mapping's lifetime prior to apply the sealing. > +When not to use mseal > +===================== > +Applications can apply sealing to any virtual memory region from userspace, > +but it is *crucial to thoroughly analyze the mapping's lifetime* prior to > +apply the sealing. This is because the sealed mapping *won’t be unmapped* > +until the process terminates or the exec system call is invoked. > > For example: > + - aio/shm > + aio/shm can call mmap and munmap on behalf of userspace, e.g. > + ksys_shmdt() in shm.c. The lifetimes of those mapping are not tied to > + the lifetime of the process. If those memories are sealed from userspace, > + then munmap will fail, causing leaks in VMA address space during the > + lifetime of the process. > + > + - ptr allocated by malloc (heap) > + Don't use mseal on the memory ptr return from malloc(). > + malloc() is implemented by allocator, e.g. by glibc. Heap manager might > + allocate a ptr from brk or mapping created by mmap. > + If an app calls mseal on a ptr returned from malloc(), this can affect > + the heap manager's ability to manage the mappings; the outcome is > + non-deterministic. > + > + Example:: > + > + ptr = malloc(size); > + /* don't call mseal on ptr return from malloc. */ > + mseal(ptr, size); > + /* free will success, allocator can't shrink heap lower than ptr */ > + free(ptr); > + > +mseal doesn't block > +=================== > +In a nutshell, mseal blocks certain mm syscall from modifying some of VMA's > +attributes, such as protection bits (RWX). Sealed mappings doesn't mean the > +memory is immutable. > > -- aio/shm > - > - aio/shm can call mmap()/munmap() on behalf of userspace, e.g. ksys_shmdt() in > - shm.c. The lifetime of those mapping are not tied to the lifetime of the > - process. If those memories are sealed from userspace, then munmap() will fail, > - causing leaks in VMA address space during the lifetime of the process. > - > -- Brk (heap) > - > - Currently, userspace applications can seal parts of the heap by calling > - malloc() and mseal(). > - let's assume following calls from user space: > - > - - ptr = malloc(size); > - - mprotect(ptr, size, RO); > - - mseal(ptr, size); > - - free(ptr); > - > - Technically, before mseal() is added, the user can change the protection of > - the heap by calling mprotect(RO). As long as the user changes the protection > - back to RW before free(), the memory range can be reused. > - > - Adding mseal() into the picture, however, the heap is then sealed partially, > - the user can still free it, but the memory remains to be RO. If the address > - is re-used by the heap manager for another malloc, the process might crash > - soon after. Therefore, it is important not to apply sealing to any memory > - that might get recycled. > - > - Furthermore, even if the application never calls the free() for the ptr, > - the heap manager may invoke the brk system call to shrink the size of the > - heap. In the kernel, the brk-shrink will call munmap(). Consequently, > - depending on the location of the ptr, the outcome of brk-shrink is > - nondeterministic. > - > - > -Additional notes: > -================= > As Jann Horn pointed out in [3], there are still a few ways to write > -to RO memory, which is, in a way, by design. Those cases are not covered > -by mseal(). If applications want to block such cases, sandbox tools (such as > -seccomp, LSM, etc) might be considered. > +to RO memory, which is, in a way, by design. And those could be blocked > +by different security measures. > > Those cases are: > - > -- Write to read-only memory through /proc/self/mem interface. > -- Write to read-only memory through ptrace (such as PTRACE_POKETEXT). > -- userfaultfd. > + - Write to read-only memory through /proc/self/mem interface (FOLL_FORCE). > + - Write to read-only memory through ptrace (such as PTRACE_POKETEXT). > + - userfaultfd. > > The idea that inspired this patch comes from Stephen Röttger’s work in V8 > CFI [4]. Chrome browser in ChromeOS will be the first user of this API. > > -Reference: > -========== > -[1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274 > - > -[2] https://man.openbsd.org/mimmutable.2 > - > -[3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.com > - > -[4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc > +Reference > +========= > +- [1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274 > +- [2] https://man.openbsd.org/mimmutable.2 > +- [3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.com > +- [4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc With those few changes: Reviewed-by: Randy Dunlap -- ~Randy