Received: by 10.192.165.148 with SMTP id m20csp3544694imm; Mon, 7 May 2018 14:16:07 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrOucD/X6jSqTVoBzOGOSEeC8Szt8Op6XYK8+qtj5hmT+ZHyktPwbeb4YUasY3y32i2nmTD X-Received: by 2002:a6b:a712:: with SMTP id q18-v6mr41302833ioe.237.1525727767508; Mon, 07 May 2018 14:16:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525727767; cv=none; d=google.com; s=arc-20160816; b=GID0pWPOwyh8utVjrFs+nT60BOx9C7zPYPIHWdGzbY6RFTluPgczJ2cvJCrWYNTiL3 Kv42TE+AuH6tUpShJAGFzhRnCjS9/jEN6keg1lAH83Qg+o1DxIn5o++3/29OCRSwiDXz UGAYUZBqodNB7Mu9fwj5lI547uYgP8MPPoUU2imTK835edUXzzjKbkcSIu3S3DZ/h+q0 Qk/RcVy20ByFL0Bzqt+6G4NZOO11EizXGeNFgRVw3vAb9oxMy9P3kYaHxIox8cF/i2y6 icyYKNyxhvtUaBhxyl8RqV4q1fRDrVmGLQp1lZnuAEbBk9SjsFyscyD3XMaRfuZb2vPG CbFw== 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=SD3V7/wGQTjd5Zpvzz/tidgHb9iE5HfvEms1GV5VBHc=; b=CflKlhsPGXXw/wngIXU2TrOyJ6PiB0oHaMyEsUYpRUQZCpPWW9R9Hyggg5iFkFqYJK n6S1Lm7mGVlS1+GufuYA94mmRMQRBuBPJR3Fz+oN80h8I2IUgzIR5UPla24FyRR6qYxd +9THSZT0u6diS83d3N2TEftdIpCA0LcI+BGtM848IVP3LMn4U2OAzhlk6kcvhlI1L3cf lzKEk2xCZjN2npE5xxJbjvo3NRkFnuFBoDtvryOaeW4DdB2Z5UXFVPOsDY9ixDXhkBdG 5wjEIlRYiKFn4166edhvdpxv+FYP2SlbPbN89G5PqIYtQQw9H5DObfsy5+q75O4ckeyT UHgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=cORqXLVu; 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 i184-v6si8722296ite.25.2018.05.07.14.15.54; Mon, 07 May 2018 14:16:07 -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=cORqXLVu; 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 S1753416AbeEGVPQ (ORCPT + 99 others); Mon, 7 May 2018 17:15:16 -0400 Received: from mail-vk0-f44.google.com ([209.85.213.44]:43281 "EHLO mail-vk0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753354AbeEGVPO (ORCPT ); Mon, 7 May 2018 17:15:14 -0400 Received: by mail-vk0-f44.google.com with SMTP id x191-v6so5844434vke.10 for ; Mon, 07 May 2018 14:15:14 -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=SD3V7/wGQTjd5Zpvzz/tidgHb9iE5HfvEms1GV5VBHc=; b=cORqXLVukXDEqNtCuHWZOKbFsRtlj8uTnGiJHOutIPtuQvrvb8T2IaHGHzgolMk7bq W6FGWq1C7zHOOSevlSQeZxlelhURVhcdnYtMNsmbgOBAm7Wce0FHV/+yg0QkMar6UeHo aYc6MYKeU1WczP/hy17zZK+5Gz08zHIVhuWzDFlVJ2As4O8NnWI2eJgoMYKH826WrVRo nFjeCa02teU8HChgsXkuuqT0DrXaelZPRGKHlg9T2dqtGssmehQxIUEjrVYPiOhdUVG8 PvBHDa3WfHPACdmP5xFx8ePS8bdU7jvdactIEStk4INTb2smYb5YapRZ8lstcln1STrf aroA== 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=SD3V7/wGQTjd5Zpvzz/tidgHb9iE5HfvEms1GV5VBHc=; b=e5CsnJqrJmu3TiM0zj/3ugQWx/BYiW0Ofph/EczTSatqtiZx4WJmlQ/6M1pe6anbQw fd6kVczt8DkQ8kjWTo08qWL0qmiEIlKbCudck7c5U2/w95B7mrFY1Swo2RPA+j4Q7L9c UzlI+DGqoWNKQzMmHztzU0Gi7soSoxFtYW4dxsd5ncPqgQDCbFnfZ9W7hW+zsym3CL/b nA2/SOymIE8kWP0/N0exv/VtpHG1PxnGaVGLy5N+OSiVu1N7fZlsz6FTviooLp0zCjy9 Lv3C9uKuv3zuKchCKTgI+B85raLOz3XYAiou6fblHMgag7z1gG/FwmNg5gGn8aFzkOf8 PYEQ== X-Gm-Message-State: ALKqPwcE9lCuVh7QNcMxhM18lH1T65tHiSMCaw/86QNeTkuu3viMU1iT qeo60H6AF3E7z+rzLAvt0wnldXqK3PeVXtgdsw5eNA== X-Received: by 2002:a1f:72cf:: with SMTP id n198-v6mr5392688vkc.149.1525727713501; Mon, 07 May 2018 14:15:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.11.209 with HTTP; Mon, 7 May 2018 14:15:12 -0700 (PDT) In-Reply-To: <20180507204911.GC15604@bombadil.infradead.org> References: <20180505034646.GA20495@bombadil.infradead.org> <20180507113902.GC18116@bombadil.infradead.org> <20180507201945.GB15604@bombadil.infradead.org> <20180507204911.GC15604@bombadil.infradead.org> From: Kees Cook Date: Mon, 7 May 2018 14:15:12 -0700 Message-ID: Subject: Re: *alloc API changes To: Matthew Wilcox Cc: John Johansen , 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 1:49 PM, Matthew Wilcox wrote: > On Mon, May 07, 2018 at 01:27:38PM -0700, Kees Cook wrote: >> On Mon, May 7, 2018 at 1:19 PM, Matthew Wilcox wrote: >> > Yes. And today with kvmalloc. However, I proposed to Linus that >> > kvmalloc() shouldn't allow it -- we should have kvmalloc_large() which >> > would, but kvmalloc wouldn't. He liked that idea, so I'm going with it. >> >> How would we handle size calculations for _large? > > I'm not sure we should, at least initially. The very few places which > need a large kvmalloc really are special and can do their own careful > checking. Because, as Linus pointed out, we shouldn't be letting the > user ask us to allocate a terabyte of RAM. We should just fail that. > > let's see how those users pan out, and then see what we can offer in > terms of safety. > >> > There are very, very few places which should need kvmalloc_large. >> > That's one million 8-byte pointers. If you need more than that inside >> > the kernel, you're doing something really damn weird and should do >> > something that looks obviously different. >> >> I'm CCing John since I remember long ago running into problems loading >> the AppArmor DFA with kmalloc and switching it to kvmalloc. John, how >> large can the DFAs for AppArmor get? Would an 8MB limit be a problem? > > Great! Opinions from people who'll use this interface are exceptionally > useful. > >> And do we have any large IO or network buffers >8MB? > > Not that get allocated with kvmalloc ... because you can't DMA map vmalloc > (without doing some unusual contortions). Er, yes, right. I meant for _all_ allocators, though. If 8MB is going to be the new "saturated" value? Maybe I misunderstood? What are you proposing for the code of array_size()? >> > but I thought of another problem with array_size. We already have >> > ARRAY_SIZE and it means "the number of elements in the array". >> > >> > so ... struct_bytes(), array_bytes(), array3_bytes()? >> >> Maybe "calc"? struct_calc(), array_calc(), array3_calc()? This has the >> benefit of actually saying more about what it is doing, rather than >> its return value... In the end, I don't care. :) > > I don't have a strong feeling on this either. I lean ever so slightly towards *_size(). It'll be hard to mix up ARRAY_SIZE() and array_size(), given the parameters. -Kees -- Kees Cook Pixel Security