Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp186946imj; Thu, 14 Feb 2019 18:14:39 -0800 (PST) X-Google-Smtp-Source: AHgI3Iaxztbk8bfXlKu9VCAXLSCDvCDLHsMlLFrRH9lNiqEPQer/cwU2sjm91oqs42D/SYl2oNF3 X-Received: by 2002:a17:902:aa44:: with SMTP id c4mr7480941plr.91.1550196879648; Thu, 14 Feb 2019 18:14:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550196879; cv=none; d=google.com; s=arc-20160816; b=BLVdG2JOyKT2/46crrj+qO+jw+gJQb6GE7XfVUFlCdoAq11Cb9XByDvvSHe1J10tWn UXUCZ9WySrGdXoGTjVMJw0Y2Vl9KBru8FXr/XpCSMmdcfTgJurhOPB4UzKUcsCfrhJKx ntuOivGA2RAraFC7xv8PKFLBdSWpDLs2+Aw/tEzsED11RUvswscRcE1nxiom0NHT2RC9 bqEMWL6GGdP0KVrf5SHom/22ciShV2VeWytqnX/OO1x0Lp3qgHtMIM85KzbpeBkpxhzg mladxMmA3b3EZPL0+tE4YkjGh8ajnJLaERrhsy5wJYC4wAy6ySj0mHb7wuLd/1MjQ2Ip o7CA== 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=UCLVnnyIkJIWvIhkOPIRsD33pAc3xGCaA+qxojDDFcU=; b=oyIHy6TQDGFeNLxWhGnH0hhDLCskJp3iNJ4894L5jXDJPoNNAe1H5n29lidpicoNr8 easymxQPpxO0okG80LxoCaDsjmdeUk5CJf74WuDJG30OYzUNws3+bA2mkrgFUFz4IQ7P aKpVd26GJK32wNMU0HIOEdVavH/ievu6izGWrxT1GAApwOsEksS78cb6VtTJKhOYEql6 NA/399FXm4wlgmjwSdw/U9EN2NeqSDLcDTwap1cuU9SA77j20HlEbXB0pg1VKFSGPb8E nbXApqaw/v1esCHifGJXCoB0oINXCJdWRsMdAczepgodZjRIY00JUcLy6w54ftxBrxUp qs6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=HNweZ4ek; 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 j20si4028296pfe.241.2019.02.14.18.14.24; Thu, 14 Feb 2019 18:14:39 -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=HNweZ4ek; 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 S2503279AbfBNUyK (ORCPT + 99 others); Thu, 14 Feb 2019 15:54:10 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:46763 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2503272AbfBNUyH (ORCPT ); Thu, 14 Feb 2019 15:54:07 -0500 Received: by mail-qt1-f193.google.com with SMTP id y20so8453369qtm.13 for ; Thu, 14 Feb 2019 12:54:06 -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=UCLVnnyIkJIWvIhkOPIRsD33pAc3xGCaA+qxojDDFcU=; b=HNweZ4ekICrK1dMJckkHky0IfhFJG7awGpHHiVA4BQEjj59YzXP8wUeABVurl2oVKY vxsWLEowwv3rcDCJ0lgCttyo+aWohmQyATDEgvLNQ5UcLfAByJw8ppnzJVOa1PcVWHt9 Z0YhdyoL9rcHKbIZAj3zix6AnpDuPTBO3dOs4ebj5k+96Vlt6a+ipsM4dAqKmQ4BZohj rJLliqBxdhq9SEC0nJvYy57Yu+J34xA3+fVwg5ITNPmJpwI8/1XRUyQTJvsij6TwhfFL HZalyUHm4vO7/tmz56+5HPNeMOZ1klG3unwyqCPvZXYPcc02HsAzfAS9ebGfIZQdBToZ xgtA== 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=UCLVnnyIkJIWvIhkOPIRsD33pAc3xGCaA+qxojDDFcU=; b=nSmuHDueDyLy7LpQEZlzlFEiW4JFXmp81W2GPpX87+vYlFbNCtE9FjQ1XSc4Kow65a mF0B6crdTL/MKYQpkPvMmYWkEFvXwh7UCpEHdcvrIbNKRbhGNrPFkiUwvQZY1OyQMrzh QGEdhTNW5CpxURq3ZYmq9ro00lJDSwrkx8A1OBSeMjj+1chySaKDhfxOAOXj2tsKyuuh TkEvnY+qJeyXcxlqs8SkEHew/VM4vygR2ubgpNmu0MKbeh/VPBNAtdwHfkGVZOCoEmCS 95dHXWVkO10ACbXsNYLajDaQlfI8f5n1+lgj4nGOQzesmjHOUNoJHafbtlzlrajoN2EE fpRA== X-Gm-Message-State: AHQUAuYpQoQ9U/1B+UqWei3oZcA3ek2tDnecHqoCMgOBowCOY6nPpV3+ n6VaTdxdKdJf+siN9DC/PoBnUq1zUPszAGTNLhj/7f0nK6c= X-Received: by 2002:ac8:44d3:: with SMTP id b19mr4878279qto.304.1550177645750; Thu, 14 Feb 2019 12:54:05 -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: From: Joel Fernandes Date: Thu, 14 Feb 2019 15:53:54 -0500 Message-ID: Subject: Re: [PATCH v3 1/7] binder: create userspace-to-binder-buffer copy function To: Todd Kjos Cc: Todd Kjos , Greg Kroah-Hartman , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , "open list:ANDROID DRIVERS" , LKML , Martijn Coenen , "Joel Fernandes (Google)" , 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 3:42 PM Todd Kjos wrote: > > On Thu, Feb 14, 2019 at 11:45 AM Joel Fernandes wrote: [snip] > > > + * 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. Got it, thanks. - Joel