Received: by 10.192.165.148 with SMTP id m20csp3250468imm; Mon, 7 May 2018 09:04:37 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq3I0QeV7n0MBaO7s7BvPE1OsP3e4ox4zEFTAF9GkdCPUWraoOFhTLC2x3T9/oxvB2itNUo X-Received: by 2002:aca:af4e:: with SMTP id y75-v6mr22684621oie.223.1525709077563; Mon, 07 May 2018 09:04:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525709077; cv=none; d=google.com; s=arc-20160816; b=CnvoCEdAOXTwS2dZEQBBhlcv6F/FWlSMke/yPHXh3Ftc2lMashT5s6XQtDjHMyprwy 5X7URf0l/7WgLZYSZUSip7BYapQkG6FXNmGM9gbynJLeMvb0Nn+0D16WOXNUTemTa4OU 0RXYiW8JxgB0BmXa5FtMVcrQi30w8zEXB7zkBln8ODbrj1UgM8HblmkeEbZvgMc+kOLr 4l35It7FQBgYr5Xwy08ET6TqNc6zlLNDnXwIqDsLEMZfY+RZ5DNxHBtAGcrussUboCgn jQ/Dcw04XSLDv/BwGFiIc5nM7fMnOmVx2pW20b3vbRENdxUfqjOitHoQ6GNR+FAifS9R tdiw== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=An0fw2Rs4qQXnhXI/7LIq3uB24ugsPZdFiaGJM3bejI=; b=xm4+sfDf0alVajlmyLNRCa1411zMMaZCIer8DELTRQE0LG7IOd0F1mhTKRx7IHNaA1 dj4YrgVVtam6LTEUHFmd4rKNnSHLiOYvKktUqGLiD+ZOHtTj48KXz5gshW3ujwrDEToo T5wLZFPKjpIuo0U0G/zxfDmwhfAjZNRAnsLtr7Jhng2t2gYiJBnYXCJ0er+QUMKgtiVZ mAMSNqh/p2MpKNFZtqLGONOFebcX8AK8kVzyCjNh76vVYbEtwF6Yjv+8auDWUjZbOGok wV1YY/t/j2BNiqw75Cs4cOV+TJLcGU07uC4JFmG9FQ+UhDKlDlEIs90v1VrKlYSvseZf qNTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ja2HFze7; 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 j3-v6si4886572itc.9.2018.05.07.09.04.22; Mon, 07 May 2018 09:04:37 -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=pass header.i=@google.com header.s=20161025 header.b=ja2HFze7; 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 S1752640AbeEGQD5 (ORCPT + 99 others); Mon, 7 May 2018 12:03:57 -0400 Received: from mail-vk0-f46.google.com ([209.85.213.46]:44889 "EHLO mail-vk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752360AbeEGQDz (ORCPT ); Mon, 7 May 2018 12:03:55 -0400 Received: by mail-vk0-f46.google.com with SMTP id x66-v6so13202181vka.11 for ; Mon, 07 May 2018 09:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=An0fw2Rs4qQXnhXI/7LIq3uB24ugsPZdFiaGJM3bejI=; b=ja2HFze7VyXOIsVx21de29sQQXFVMnZgrxwaUMSl3wGIlyKKfJsCjbsyAWTujQjONj IwzAxQ8kd+hO+EY1YEzEQ956NA4nIarfkguuleVa1fhnXLHXdQw8hoTH1EqbM7PO4b3f deNr2tx6GLCbBDIE928gNIqAJvuOeN1Zklp9bFoB5v3vh5YxKa9jD85W1JFY6oXBFR49 4wqvX6YxaiqM4YFxEvf64rYwxrO2G1rEC20vS3x2zmdb2NX2NRlHERX/i49H88RiFEC8 JYYw2JBBTVYsa5vGr+DhbPFv7OpoYq6aPwy85GAnYt1lgCVrV3HAxPRE61ZeRbF1Sdtc ta0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=An0fw2Rs4qQXnhXI/7LIq3uB24ugsPZdFiaGJM3bejI=; b=FibiTxQydlItRes2ptBzJL1pl5BbSCehSsMq72f8na3eAXdn/RuL8kp42iKqkEmT/8 GgWormSTyqZHWUDCrH3WFx3rsBfoSDjXlKQyPkdjuBbzm6TdshLSwBEBD83itHJv5Aw/ BkL+n+cTidHVpVszlVmV3oDCQVpYtvuTno0jVB3Sgw2+37a16RYH3qB0DyD8zn//2c15 X0tXPoDFBvGqExgYMTDBehXV0VY9fy1gryhXqQhxgpEHfzWzRL3xU5aYp4X0TVfjRjtu 2k9dK4GD+/mdA8pmPXC8xYZerK6oWjUPSzP72zEtPdpoeZo3lQ5gUY43cvb6AdX+aRnG qhQw== X-Gm-Message-State: ALKqPwfSae1nTsOQF9EWBUiQe/9bhWQq2zXN5lFqFtAhzpN9Q9hm0LaX IkaxtEvhHw+1kmwUuh95X8Dk7zg6rq3RNGwRy1lHdQ== X-Received: by 2002:a1f:72cf:: with SMTP id n198-v6mr4630432vkc.149.1525709034732; Mon, 07 May 2018 09:03:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.11.209 with HTTP; Mon, 7 May 2018 09:03:54 -0700 (PDT) In-Reply-To: <20180507113902.GC18116@bombadil.infradead.org> References: <20180505034646.GA20495@bombadil.infradead.org> <20180507113902.GC18116@bombadil.infradead.org> From: Kees Cook Date: Mon, 7 May 2018 09:03:54 -0700 Message-ID: Subject: Re: *alloc API changes To: Matthew Wilcox Cc: Matthew Wilcox , Linux-MM , LKML , Rasmus Villemoes 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 Mon, May 7, 2018 at 4:39 AM, Matthew Wilcox wrote: > On Fri, May 04, 2018 at 09:24:56PM -0700, Kees Cook wrote: >> On Fri, May 4, 2018 at 8:46 PM, Matthew Wilcox wrote: >> The only fear I have with the saturating helpers is that we'll end up >> using them in places that don't recognize SIZE_MAX. Like, say: >> >> size = mul(a, b) + 1; >> >> then *poof* size == 0. Now, I'd hope that code would use add(mul(a, >> b), 1), but still... it makes me nervous. > > That's reasonable. So let's add: > > #define ALLOC_TOO_BIG (PAGE_SIZE << MAX_ORDER) > > (there's a presumably somewhat obsolete CONFIG_FORCE_MAX_ZONEORDER on some > architectures which allows people to configure MAX_ORDER all the way up > to 64. That config option needs to go away, or at least be limited to > a much lower value). > > On x86, that's 4k << 11 = 8MB. On PPC, that might be 64k << 9 == 32MB. > Those values should be relatively immune to further arithmetic causing > an additional overflow. But we can do larger than 8MB allocations with vmalloc, can't we? > I don't think it should go in the callers though ... where it goes in > the allocator is up to the allocator maintainers ;-) We need a self-test regardless, so checking that each allocator returns NULL with the saturated value can be done. >> > I'd rather have a mul_ab(), mul_abc(), mul_ab_add_c(), etc. than nest >> > calls to mult(). >> >> Agreed. I think having exactly those would cover almost everything, >> and the two places where a 4-factor product is needed could just nest >> them. (bikeshed: the very common mul_ab() should just be mul(), IMO.) >> >> > Nono, Linus had the better proposal, struct_size(p, member, n). >> >> Oh, yes! I totally missed that in the threads. > > so we're agreed on struct_size(). I think rather than the explicit 'mul', > perhaps we should have array_size() and array3_size(). I do like the symmetry there. My earlier "what if someone does +1" continues to scratch at my brain, though I think it's likely unimportant: there's no indication (in the name) that these calls saturate. Will someone ever do something crazy like: array_size(a, b) / array_size(c, d) and they can, effectively, a truncated value (if "a, b" saturated and "c, d" didn't...)? >> Right, no. I think if we can ditch *calloc() and _array() by using >> saturating helpers, we'll have the API in a much better form: >> >> kmalloc(foo * bar, GFP_KERNEL); >> into >> kmalloc_array(foo, bar, GFP_KERNEL); >> into >> kmalloc(mul(foo, bar), GFP_KERNEL); > > kmalloc(array_size(foo, bar), GFP_KERNEL); I can't come up with a better name. :P When it was "mul()" I was thinking "smul()" for "saturating multiply". sarray_size() seems ... bonkers. > I think we're broadly in agreement here! Do we want addition helpers? (And division and subtraction?) -Kees -- Kees Cook Pixel Security