Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp998151ybe; Wed, 4 Sep 2019 10:55:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqwUMDDqzBlMf2c/2BeNeSj5CnXgzuWn0Oal8NTfYKMLxdwRt11QCWDtCJBSXRUhtXqDsWtT X-Received: by 2002:a65:6259:: with SMTP id q25mr3294718pgv.145.1567619740479; Wed, 04 Sep 2019 10:55:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567619740; cv=none; d=google.com; s=arc-20160816; b=tpwIgu+954vuH/M3jumlgjNyQuMDTsouST5zl7DhT2GT/qx+FzjSc78C6DY7xNHeoZ 9C81VWrsjP9g5RDcCJcRQCYnSK/FwXpjPZVJ3SzNqE/kbfuUv0V+UB5yBtkBZAsuuPRg z4CRlHAh4DDpbJh52+K47RZhVg64uR6suR8AxADvqTdDZ1PtuwAVJTi35U0Fn/0MW52c odpo8LbyYkQfMpsM/9LTB4zzIfgO+Eji99+UgqqrRp05Ljd8HxVxk64P04FHYxK3jeSW 06pWNrml6elSKTzTZWx/+9oO6fxIK630VWyicjWcBfWAQ9kz/6woiG9+GR7V2S1lYVdo ln9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ZqXCk5KX1lKBB5KfBUnA9fP6d+VfeiwpyxR9UeQIid0=; b=F1cbqC8KJArWNpuIcfTUwMqSO5r+PI2augRxDY0qO+xJEm4QhZimT1Sagptk1aZ+JA KCSzTJYb0TU5PONFYLfv1UpXUP0JJF7XOxGyUQLBnfrz2fjVYlp2pgIBIiPA57rz5J8F lfp3f1WP5dbG2FDlwusEgvKP+ZeKzKyh9mwGFHECvaZ1BC1P9I1HGj/3MmIznD4NBwxT rhC1IIuX7dIS6zdRvbbMvze0bO2+BpY4IFeX0A8njXEQKp9hB47uNFdlPZ/v/rAZa2pL NtYy06++dYmJykil5MJZdWd1vXW7ZQKxu4u0PEEoZ1VnmPOAVwc5AJCMYWTvYRdT5c/1 q4Rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=C17cXKGl; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x6si18263244pgq.473.2019.09.04.10.55.25; Wed, 04 Sep 2019 10:55:40 -0700 (PDT) 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=fail header.i=@gmail.com header.s=20161025 header.b=C17cXKGl; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732496AbfIDRyC (ORCPT + 99 others); Wed, 4 Sep 2019 13:54:02 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:35715 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731633AbfIDRyC (ORCPT ); Wed, 4 Sep 2019 13:54:02 -0400 Received: by mail-wr1-f67.google.com with SMTP id g7so22269674wrx.2 for ; Wed, 04 Sep 2019 10:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ZqXCk5KX1lKBB5KfBUnA9fP6d+VfeiwpyxR9UeQIid0=; b=C17cXKGlO2CS3202OtJVhSRM0yivbeK5q8wrudl5l2p7PRLWO6t02XaKPSgn+/NKy/ 2VdLclCJorKzweIVxEsz4QM9a93P0K0d9HIPfFKX4U9fEpb4sy5KOLHmBvsh1FLBU5RS Qv9OkBq6z5LOcj6JIJoXVS3Kc7poANRTPgE+sEusHkhp34GL0W524vf4V7NQHWkDFeey IWm/6Uw3qXNll05tOM1iPHpbt0LXWYDvfsCro5Hd2Rmc1vGeg9WMM5PS9g1NrOTuytwM xlOgFpDmc+R6DqNfcg2bPCQbnfN7+tbX7/rIQaWK7y74OkSO+KyOWjtApXoIotYGP21u SYiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=ZqXCk5KX1lKBB5KfBUnA9fP6d+VfeiwpyxR9UeQIid0=; b=RcgQNc2paIgmWLoGG+dmAA++/P8MM9TLYAFoS3hma3fHHQNowP6Yvne/+0IWbGQT8K JgLz248iKg2ZBdDr0ZOnBYTGGGitcR04a3Gx+ZOFu6wlTl//jaxKR+CbzpGQH/bzsh4K MBYfZdDfxGGeyMHV4CQ2mDyX1QBTJfk3cD3P4eL8jc74K2UCIdDycSbB5mchsQXlnHIr +QWbaugCZ+HMkinJ3+DbChXplu/mui5rPCi5cb1VvBSaNQDZMPoWZy5IxiWY9Udkx9/T gdYCryM1XTXg5VZunxIeXSkiZCyH/VeJtiscrPnjQfqUzZegrAMGB6QwKBL0G+xD1o9n OWHw== X-Gm-Message-State: APjAAAXiXudSl4yjnM6BIPq0ULRcwCPwC1uy8lSXtkQbFUjlJyctEBQE J0F+gYfUxA+lhpgKEXaI8vLz53MK X-Received: by 2002:adf:e68a:: with SMTP id r10mr3213270wrm.63.1567619640531; Wed, 04 Sep 2019 10:54:00 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id q192sm4812978wme.23.2019.09.04.10.53.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2019 10:53:59 -0700 (PDT) Date: Wed, 4 Sep 2019 19:53:57 +0200 From: Ingo Molnar To: Thadeu Lima de Souza Cascardo Cc: Dietmar Eggemann , linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Patrick Bellasi , Thomas Gleixner , Arnaldo Carvalho de Melo , Linus Torvalds , Jiri Olsa Subject: Re: [PATCH v3] sched/core: Fix uclamp ABI bug, clean up and robustify sched_read_attr() ABI logic and code Message-ID: <20190904175357.GA110926@gmail.com> References: <20190903171645.28090-1-cascardo@canonical.com> <20190903171645.28090-2-cascardo@canonical.com> <20190904075532.GA26751@gmail.com> <20190904084934.GA117671@gmail.com> <20190904085519.GA127156@gmail.com> <20190904103925.GA60962@gmail.com> <20190904131932.GG4101@calabresa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190904131932.GG4101@calabresa> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Thadeu Lima de Souza Cascardo wrote: > There is one odd behaviour now, which is whenever size is set between > VER0 and VER1, we will have a partial struct filled up, instead of > getting E2BIG or EINVAL. Well, that's pretty much by design: user-space is asking for 'usize' bytes of information, and the kernel provides it if it can. This way the kernel can keep backwards compatibility indefinitely, without new kernels having to be aware of the zillions of prior ABI versions that were due to slow expansion of the ABI. (This actually happened to the perf ABI, which was expanded dozens of times already.) > > +static int > > +sched_attr_copy_to_user(struct sched_attr __user *uattr, > > + struct sched_attr *kattr, > > + unsigned int usize) > > { > > - int ret; > > + unsigned int ksize = sizeof(*kattr); > > > > - if (!access_ok(uattr, usize)) > > + if (!access_ok(uattr, ksize)) > > return -EFAULT; > > > > I believe this should be either usize or kattr->size and moved below > (or just reuse min(usize,ksize)). > > Otherwise, an old binary that uses the old ABI (that is, VER0 as size) > may get EFAULT here. This should almost never in practice. I tried, but > I could hardly use an address that would fail access_ok. But, > theoretically, that still breaks ABI. I agree that this is mostly theoretical, as currently these sizes are limited between VER0 and PAGE_SIZE - and hardly anyone puts these structures near the very end of virtual memory. But checking 'usize' is arguably the more correct value, as that's the size of the user-space buffer. I've done this change in the latest version of the fix. Thanks, Ingo