From owner-svn-src-all@freebsd.org Wed Jan 24 21:40:38 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1FD7EC7817; Wed, 24 Jan 2018 21:40:37 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DC6F79A00; Wed, 24 Jan 2018 21:40:37 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f46.google.com with SMTP id 196so6900024iti.5; Wed, 24 Jan 2018 13:40:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=Rt0KD1gJTRC+DGWepIrt1HQpqhxoQR7rqzg8thCA80g=; b=rDJbdVVPkWwu/wLy1bR6KSTKrlvDymYVVgFY6TV6bFrjgbumdaQ2tvYt96exJBLL/W 02fMCGce1U9KpCvvRAY9MpdFHoTE5A+702Dv+pS2EuTdeq4Io2VDIkPrf2UPgjIZdhwU hyVO91RPBviCAoBxrT9Xfo32rCDocVrCgQdu3BIPHK+JBCMlWW4P+evLl6itGHqAaBYM L2bwNZqbeQrB6HOzkmsIeB2no23ehw2JF65mALSxqKjSvnF1eU3dzBl9fg6r+tKoXfZR WFgm3rmFKWhK9wggNVku+xx9Xgbtj+7SCbj3ZZYtW30Z650/+lrl2jKRSHe6HXieBBB8 d8nQ== X-Gm-Message-State: AKwxyte7UHX/j4p/EGmqGGkH5K6MK2Hld6cS8mvoeSMDqEI1vhTTu8Qs v4jmL8N8UiU/IvsFB5jjMXY3wHFO X-Google-Smtp-Source: AH8x226MUrYaC65EcBXIUNfB3u4ROmbEcG+a9WvNWAwrsLdmrMxE/Yiqjfi7TP8dQQ+Mx1+xqFgssQ== X-Received: by 10.36.64.136 with SMTP id n130mr10921827ita.105.1516830036572; Wed, 24 Jan 2018 13:40:36 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id e185sm637144itb.27.2018.01.24.13.40.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 13:40:36 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id f4so6400479ioh.8; Wed, 24 Jan 2018 13:40:36 -0800 (PST) X-Received: by 10.107.15.89 with SMTP id x86mr10530315ioi.38.1516830035813; Wed, 24 Jan 2018 13:40:35 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.95.152 with HTTP; Wed, 24 Jan 2018 13:40:35 -0800 (PST) In-Reply-To: References: <201801211542.w0LFgbsp005980@repo.freebsd.org> <51ff8aef-5660-7857-e4d5-12cdc77bc071@FreeBSD.org> <20180124182548.X1063@besplex.bde.org> <1516817048.42536.182.camel@freebsd.org> <2aa48cbd-247a-66cd-b486-02ee77ec2e96@selasky.org> From: Conrad Meyer Date: Wed, 24 Jan 2018 13:40:35 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r328218 - in head/sys: amd64/amd64 arm/xscale/ixp425 arm64/arm64 cam cam/ctl compat/ndis dev/aacraid dev/advansys dev/ath dev/beri/virtio dev/bnxt dev/bwn dev/ciss dev/cxgbe/crypto dev/... To: Warner Losh Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 21:40:38 -0000 On Wed, Jan 24, 2018 at 1:13 PM, Warner Losh wrote: > mallocarray should be the last line of defense, not the only line of > defense. Agreed. > most of the time, it's more correct to say > > if (WOULD_OVERFLOW(a,b)) > return EINVAL; > ptr = mallocarray(a,b...); Disagree -- the right check to have outside is much more constrained than just "will this overflow?" A 10GB allocation request is still insane on amd64, just for a different reason than on i386. I think BDE said something along the lines of max 32 kB for most allocations, and I don't really disagree with that. Picking a specific number for mallocarray itself (other than overflow) restricts the generality, though. > since an error return, assuming it's handled correctly is preferable to a > panic. Agreed. > I thought this was more true for NOWAIT than for WAITOK cases, but I've > realized it's more true always. Yeah, I think it's equally true of M_WAITOK and M_NOWAIT. > And that's why I have such a problem with mallocarray: it's only useful when > people are lazy and haven't checked, It's useful as a seatbelt. Empirically, people are not perfect at doing the checking. I can understand that it feels like admitting laziness to accept that we need a final seatbelt check at all, but I don't think having the seatbelt hurts. > and then it creates a DoS path for > things that don't check. No, again; it doesn't "create" a DoS. Any DoS path was already present as a heap corruption path. The DoS is strictly an improvement. > We'll change it now and think we're safe, when we > still have issues, just different issues than before. Don't think that, then? We have replaced some classes of heap corruption with a DoS. That's it; nothing more. I don't think anyone promoting mallocarray is overrepresenting what it does or claims to do. > It may be a necessary > change, but it certainly isn't sufficient. I don't disagree. Best, Conrad