Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp186319imj; Thu, 14 Feb 2019 18:13:49 -0800 (PST) X-Google-Smtp-Source: AHgI3IbaXZpmZlZubXadnOCIq6NDvTZMLVvF7/ZK/F1EUxhf4IQM2f2rsd6BlxWz/9pGtOK33wij X-Received: by 2002:a17:902:b60e:: with SMTP id b14mr7298707pls.301.1550196829278; Thu, 14 Feb 2019 18:13:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550196829; cv=none; d=google.com; s=arc-20160816; b=iaQawVR+fQ/JaO85SmO2dgjqE7Ne3mSIDMPGyvdkrLrVqyx1o1jG1V27xO44fwOa1l DOWS70USdb4Xmo15Ynzv1Kut+5A3c9noF/4wfNdbx1ZF78jNNn6+8KLAD4aPmPlSTOeC an6ji1P6UId7nIQeQeqD6umXl9vdLG/6rGtN8iKEvZfezcC61vyYWtJjl3h+/pfa3aN5 +KwrklNNlMYdr+UuM3fCLiaU0F/XrbVCbxpw0f9G/b+pSG4oAgsAbd8evvA4KFORx0V4 x1Lcrj9c0f1GyGJ4NvQQrXlxGdff+feoZmr3SmHkkZTxbNR85MPnryeexvz+OJWEJpuA sRog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=9tdPfvjucDJWmTxVIS5xUUyl1y3h6VQ7HyjoqYFGpRU=; b=SqcmRYEJcWOSz/D+Bl99o949XL+zFISYsPrT4+NCc1RA5S9bI5fm2fdQzC8LTY0naC A3loEEMobJNrrkGwqmxSLxh+BXa1QvwYOF2LW3tff3BdXpuNdG7wYCJNfIJb4AyHh5Nb YbTb558YRR7BLJFHYWkKYJqalRwRo9yahDXKMcLGE4QHpsXtTnuml4asX6r7CYp1t75O TnFnqkdyLsL09g0bW6rU3mtySOTwIBLqCTTO2cia4ZUaOeLJzjlevUyTi1X3R1CM2oGP O4UDA1SIBoE/2HYg4hZzNmfFyM6F6zSkUMmCZ/d9K463Ns8LFdrHiVW9+G0f0hG+fu/l PU1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mYYeAnj4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w8si4626968pgm.467.2019.02.14.18.13.33; Thu, 14 Feb 2019 18:13:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mYYeAnj4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2440044AbfBNUmm (ORCPT + 99 others); Thu, 14 Feb 2019 15:42:42 -0500 Received: from mail-qk1-f195.google.com ([209.85.222.195]:45436 "EHLO mail-qk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2503031AbfBNUmk (ORCPT ); Thu, 14 Feb 2019 15:42:40 -0500 Received: by mail-qk1-f195.google.com with SMTP id y195so4414234qka.12 for ; Thu, 14 Feb 2019 12:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9tdPfvjucDJWmTxVIS5xUUyl1y3h6VQ7HyjoqYFGpRU=; b=mYYeAnj4iFKjHqIwjEZqFQ2zp4nez6K3XLzEPtux8rA1kZe8FkvanKP2ueAIhDK6PP duxaBMSNl7c6cbTnNRSKutNrMNWyjWvx1g6MbjtUtLHk40L3JHUIlG/X66+RbANV2ww4 MPqIIQz3r8sahFuZ6RAGGkIHtJqt6vGNqiYKsX0k52KbkuqJC+VHjJHYvyxUQxxjS2yD QXCjaNXZoxqJWJDC62lbo1nSJDvpk8kq6LDidEACwxmv34/6TlCsXZbw++94V4itb0rR i0YNPssflLkNrvpAfWGSrzDizd5wockL1EcH1HVr/Zr95y+tyUyI67EkBTWZT1Z4a5cB uXdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9tdPfvjucDJWmTxVIS5xUUyl1y3h6VQ7HyjoqYFGpRU=; b=b+KDazn1upNSfddmsghjpVxTO5CGWGrbquMDsSM2B7jjqWw7wVObOJ96eGl+vedxIg o8CFTCWm1C00LCbrGrKBLNNnBvLurAiyCzHV0s/Qb7pmTwKxdnyuXLFexXt8tdnN1XRo VKuTsv7AROBaaSv2ojeBi4JvYUt5vLuSQUa9ok1CUoQ7RTL/7V8xtOi74ZJABxSvzPL5 Ct4w2IRsKEHMjjB0LV72kaflXmy3P30XG5TU9lzVNCZGMrmupZE0SA9kqI8OSl6O3zDB vutPTECNFCVlbf1mo65HsgQv4w97iOpjOBG+vrCB+2w7S/brTFBTtXK8ILhWUS9duyeH yvhA== X-Gm-Message-State: AHQUAuZiwP9zEYu8sBtvbaszGbFvR3Vm3zcAXuXxITMU00xfyFTCdIfl b2ychrLk1p3YGklZuoBQis95fobCAMGHlXWrtP66Ag== X-Received: by 2002:a37:cf56:: with SMTP id e83mr4529242qkj.101.1550176958663; Thu, 14 Feb 2019 12:42:38 -0800 (PST) MIME-Version: 1.0 References: <20190208183520.30886-1-tkjos@google.com> <20190208183520.30886-2-tkjos@google.com> <20190214194540.GA185075@google.com> In-Reply-To: <20190214194540.GA185075@google.com> From: Todd Kjos Date: Thu, 14 Feb 2019 12:42:27 -0800 Message-ID: Subject: Re: [PATCH v3 1/7] binder: create userspace-to-binder-buffer copy function To: Joel Fernandes Cc: Todd Kjos , Greg Kroah-Hartman , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , "open list:ANDROID DRIVERS" , LKML , Martijn Coenen , joel@joelfernandes.org, Android Kernel Team Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 14, 2019 at 11:45 AM Joel Fernandes wrote: > > Hi Todd, > > One quick question: > > On Fri, Feb 08, 2019 at 10:35:14AM -0800, Todd Kjos wrote: > > The binder driver uses a vm_area to map the per-process > > binder buffer space. For 32-bit android devices, this is > > now taking too much vmalloc space. This patch removes > > the use of vm_area when copying the transaction data > > from the sender to the buffer space. Instead of using > > copy_from_user() for multi-page copies, it now uses > > binder_alloc_copy_user_to_buffer() which uses kmap() > > and kunmap() to map each page, and uses copy_from_user() > > for copying to that page. > > > > Signed-off-by: Todd Kjos > > --- > > v2: remove casts as suggested by Dan Carpenter > > > > drivers/android/binder.c | 29 +++++++-- > > drivers/android/binder_alloc.c | 113 +++++++++++++++++++++++++++++++++ > > drivers/android/binder_alloc.h | 8 +++ > > 3 files changed, 143 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c > > index 5f6ef5e63b91e..ab0b3eec363bc 100644 > > --- a/drivers/android/binder.c > > +++ b/drivers/android/binder.c > > @@ -3078,8 +3078,12 @@ static void binder_transaction(struct binder_proc *proc, > > ALIGN(tr->data_size, sizeof(void *))); > > offp = off_start; > > > > - if (copy_from_user(t->buffer->data, (const void __user *)(uintptr_t) > > - tr->data.ptr.buffer, tr->data_size)) { > > + if (binder_alloc_copy_user_to_buffer( > > + &target_proc->alloc, > > + t->buffer, 0, > > + (const void __user *) > > + (uintptr_t)tr->data.ptr.buffer, > > + tr->data_size)) { > > binder_user_error("%d:%d got transaction with invalid data ptr\n", > > proc->pid, thread->pid); > > return_error = BR_FAILED_REPLY; > > @@ -3087,8 +3091,13 @@ static void binder_transaction(struct binder_proc *proc, > > return_error_line = __LINE__; > > goto err_copy_data_failed; > > } > > - if (copy_from_user(offp, (const void __user *)(uintptr_t) > > - tr->data.ptr.offsets, tr->offsets_size)) { > > + if (binder_alloc_copy_user_to_buffer( > > + &target_proc->alloc, > > + t->buffer, > > + ALIGN(tr->data_size, sizeof(void *)), > > + (const void __user *) > > + (uintptr_t)tr->data.ptr.offsets, > > + tr->offsets_size)) { > > binder_user_error("%d:%d got transaction with invalid offsets ptr\n", > > proc->pid, thread->pid); > > return_error = BR_FAILED_REPLY; > > @@ -3217,6 +3226,8 @@ static void binder_transaction(struct binder_proc *proc, > > struct binder_buffer_object *bp = > > to_binder_buffer_object(hdr); > > size_t buf_left = sg_buf_end - sg_bufp; > > + binder_size_t sg_buf_offset = (uintptr_t)sg_bufp - > > + (uintptr_t)t->buffer->data; > > > > if (bp->length > buf_left) { > > binder_user_error("%d:%d got transaction with too large buffer\n", > > @@ -3226,9 +3237,13 @@ static void binder_transaction(struct binder_proc *proc, > > return_error_line = __LINE__; > > goto err_bad_offset; > > } > > - if (copy_from_user(sg_bufp, > > - (const void __user *)(uintptr_t) > > - bp->buffer, bp->length)) { > > + if (binder_alloc_copy_user_to_buffer( > > + &target_proc->alloc, > > + t->buffer, > > + sg_buf_offset, > > + (const void __user *) > > + (uintptr_t)bp->buffer, > > + bp->length)) { > > binder_user_error("%d:%d got transaction with invalid offsets ptr\n", > > proc->pid, thread->pid); > > return_error_param = -EFAULT; > > diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c > > index 022cd80e80cc3..94c0d85c4e75b 100644 > > --- a/drivers/android/binder_alloc.c > > +++ b/drivers/android/binder_alloc.c > > @@ -29,6 +29,8 @@ > > #include > > #include > > #include > > +#include > > +#include > > #include "binder_alloc.h" > > #include "binder_trace.h" > > > > @@ -1053,3 +1055,114 @@ int binder_alloc_shrinker_init(void) > > } > > return ret; > > } > > + > > +/** > > + * check_buffer() - verify that buffer/offset is safe to access > > + * @alloc: binder_alloc for this proc > > + * @buffer: binder buffer to be accessed > > + * @offset: offset into @buffer data > > + * @bytes: bytes to access from offset > > + * > > + * Check that the @offset/@bytes are within the size of the given > > + * @buffer and that the buffer is currently active and not freeable. > > + * Offsets must also be multiples of sizeof(u32). The kernel is > > In all callers of binder_alloc_copy_user_to_buffer, the alignment of offsets > is set to sizeof(void *). Then shouldn't this function check for sizeof(void *) > alignment instead of u32? But there are other callers of check_buffer() later in the series that don't require pointer-size alignment. u32 alignment is consistent with the alignment requirements of the binder driver before this change. The copy functions don't actually need to insist on alignment, but these binder buffer objects have always used u32 alignment which has been checked in the driver. If user code misaligned it, then errors are returned. The alignment checks are really to be consistent with previous binder driver behavior. -Todd > > thanks, > > - Joel >