From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48B19C76196 for ; Thu, 6 Apr 2023 04:24:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C25296B0075; Thu, 6 Apr 2023 00:24:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD4346B0078; Thu, 6 Apr 2023 00:24:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC3F26B007B; Thu, 6 Apr 2023 00:24:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9EE736B0075 for ; Thu, 6 Apr 2023 00:24:31 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6DEE9120EE7 for ; Thu, 6 Apr 2023 04:24:31 +0000 (UTC) X-FDA: 80649674742.22.B9536E8 Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by imf10.hostedemail.com (Postfix) with ESMTP id 8FA29C000A for ; Thu, 6 Apr 2023 04:24:29 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=srUDOS28; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of jstultz@google.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=jstultz@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680755069; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=puK3a92VIcFR8DZUjfLY5Zthlc/h1NJaguZIqRU5ZbY=; b=mC/K5j2cn63AGJ7gdXpffcyBROPxGJyN1SK7wiDtDSG7vyiJEsoFNYsZV6yOOKwoXaFfPn pgQnGyWSzryXFK7pP8KOO0QzN8Zaq4ZxB/5bM0is3V2Dy/6sSYYS1ECqPWdlXqarc3d/+0 IjvEBy8yqbFs7HzzNvznbTD4SJ7vpc4= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=srUDOS28; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of jstultz@google.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=jstultz@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680755069; a=rsa-sha256; cv=none; b=eXIa/tb+Qic8lC1VhEEioPZYuX4oLZ57Gsq1tPoOpT/ROiavQRsLoOkuESItzMUXfkxI0v cwPLRhYu9Fp1uvtDrEn26dYONwuyMOATuRlYXmpfOvZnNDPcVm20WR+hfub7BnDbBxhl0l ma5c7pPDUCkSsKHeNEN8zYsiBZbb8Jk= Received: by mail-yb1-f174.google.com with SMTP id j7so44971752ybg.4 for ; Wed, 05 Apr 2023 21:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680755068; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=puK3a92VIcFR8DZUjfLY5Zthlc/h1NJaguZIqRU5ZbY=; b=srUDOS282koby+W1c0YzjdnoDWiEEWYMzkc/fjye5dgJk54gJ/v/y7E8z/k6z3P99d 1glIIM0OoCKuZ9gwIDMAlaywSn6mhTVPfLXvB6oRdgyTjYQKiYX4BGnq7YdBX1BrSzd5 ckNqpBmXr1+/uFkONj5Wou+ecdZPSVRNq8gXK8oNb2C9WqzkJMWFmp6Mim+PfPTCQR3X crPRmuuyPa3QDOAFdU56qHmllr3aR4s6wp1MjcBfu2p90QvIPK0eyhYWO+6aOy16pr0I Wg4JGwWR6uV8CcQypeRIEHZCOwiGvu8Y5oCXJlJ3lpTkrsHOdxo7PwU2rJK+ymoOpuxI YDaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680755068; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=puK3a92VIcFR8DZUjfLY5Zthlc/h1NJaguZIqRU5ZbY=; b=K1WjW2CKyNGJlYd8Ro4U+hj/VZUKUbndOGe3r/yGAqYErrbhyBbUfaDDIDFEP0pYLV 3G6elTMSS3XjnyyICWUVgRfOlfeT0V7Fz1iVWlC/0B4CYTFk2c9eGmGp/IItxcsvyeeS V0lS8pXf00+lp67NR9a+4jhsIk3KmsYanzInbIlGGAeBcP3tF/1cevkWYr2ahgYJYeea ATAIlXrgkv+8NKF5uBqW1mZUU3NgoafxxvjPxXrfQQ14Rw4bdUbZEZgj1CT5u2XTLYvk 3THStwJnIggAJJMMnXXwH25QVIk1gMnpU/b5uxpopuqgiAGE8htGXBfwf8Ykrs3r2aVt JlLA== X-Gm-Message-State: AAQBX9e0PYipKz701g4npl7AXBfnZze45Ml+bqZl3Ygd1hVJBvD9kn0n q3OnLuso1Xhs9+ooK+ZW3kSMsMxSzAvtc7l2qBXd X-Google-Smtp-Source: AKy350YtLXFfQ6EkwnXCDrgRQ7fIlVpSETrEO79HYvdZzc/YmdZp9lagOsgoajysFV+BmlG7zUAiGU4T0y3VYN74whQ= X-Received: by 2002:a25:ccc4:0:b0:b73:caa7:f06f with SMTP id l187-20020a25ccc4000000b00b73caa7f06fmr1203173ybf.5.1680755068599; Wed, 05 Apr 2023 21:24:28 -0700 (PDT) MIME-Version: 1.0 References: <20230405185650.239f9721f066aa480e83d543@linux-foundation.org> <20230405172524.e25b62e1c548a95564b1d324@linux-foundation.org> <20230406000854.25764-1-jaewon31.kim@samsung.com> <20230406014419epcms1p3f285b6e3fdbb1457db1bcbaab9e863be@epcms1p3> <20230406021712epcms1p216f274040d25d18380668ffbfa809c48@epcms1p2> <20230405200923.9b0dca2165ef3335a0f6b112@linux-foundation.org> In-Reply-To: <20230405200923.9b0dca2165ef3335a0f6b112@linux-foundation.org> From: John Stultz Date: Wed, 5 Apr 2023 21:24:17 -0700 Message-ID: Subject: Re: [PATCH v2] dma-buf/heaps: system_heap: Avoid DoS by limiting single allocations to half of all memory To: Andrew Morton Cc: jaewon31.kim@samsung.com, "tjmercier@google.com" , "sumit.semwal@linaro.org" , "daniel.vetter@ffwll.ch" , "hannes@cmpxchg.org" , "mhocko@kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "jaewon31.kim@gmail.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 8FA29C000A X-Stat-Signature: iw9bhmiyn9jo5ioxct3zdpfk6etzi9ms X-HE-Tag: 1680755069-652512 X-HE-Meta: U2FsdGVkX1/7olXp66NNkQZNWBaZOjeG2GGF5IPaRMAUAwY1FA8SrTltjCse76iUtBuSSm66bHQQn2d1yDOJjJiLKU8ozRoj2Lm9jI0ZFt4oEHW3Ny1PqrHbmqXdSew3N/7FI6qbRyyByzX6BzooCilQ4tNS1xFQAZqBq54KHSbZu81v/zG2IC5iahLBKGCcYAJwS/RszcxjBnHxAFB/JHlkFotpdmDRqKsLb3sYQGwGxZBnnOUKRgP+gTIR9tvBVw/gBQWlEIVClEW5da5ESU+kT2adEuThUmAaGVM4XHBsb9zkaUY7Te6kW93Sqa4t/FBk6XpqScZQtZHIozzpZuUPxT0sgMTGWmZm6nCj5qfkqFYEt6jCsuIaq/L2fnAI/d0yy0v8I+JfqdDaYMFLaCwLOo7aBQAFJI5hkIRM7e3NXekxoYzJ7ASKJjgs4yfdaLzQeHrJXdtEGjaQSOyhdSDazjYFsVKo5i9cREwIfjOIi/OlEuYFRz5s+hT6Cx8PocH/bAsgCSH1lGRMuJVIS6XfjeKDXLbf68j1c467wHM4To/yvjU5pHYUXsejNTdmp5IKpkzU9kriQTJ4Xr5e/Fj3gD3vDdrkXyU8lnYsjS0WIbvKwMIs+jyctRI2uYL6Pk90K5OSf2vnGDxPWLmED5l3SPAX4jOa0KXKnBhnHsQ4U909oPiAbGxmcM2CLQ7A4x/8JcdKXeJdJvuzKTWEbrV07CWZBFjyP6ehlO88ftmplAEvH/C+pwHskL7/SuWUwX0y1kjeZANJXw4nKDLHqC9WTiLqiGcy1xMt4VGq5l/fmt40XTZk0pxGHiPMrXiTQLf7m4mgpCYV++hvl8SoO3uZ7dPjmBnF2Ix74tQLyj86nQZU/driudTwApbhjnX6z71cSkSjgxgL47dVboGu0UQGixSFXCU+HYcFm82fN5GgpUSxl9MHBXa5GuhKMYXddlnMm0cYYdeuO9gEj9l P19DLH+J fw4anzPfTVVtGjGtfliXFO0wYlzH1qoDg7GXYZ1tPN4sTZNgIKLPqCgdKcJ5n0EKtponYCDwlmwp1oa7xSOYexxGOMG6yCHojD8L7j6vQJas563zNRt2ZKp193Q8OxGRC52dQjbWf9n8d9mAZIFcnJOCLUFiFWVEtKI37Dg7UeHATBv4OMbjSb0mrRANmj5kwdt+1m2EclcQcHO7rXzm+VCoSOgw1uDjwl3+ghzBWNIJqfPxuVMVkm3/FwMljRoG7hAh/4mitU8n6jkgReJs7qTU26/MfByBl+GknkOVJ+t4L4pDcQXbRYXOQgn/QQ1dxCx9OFdU6JJlYQGqY9hzAPpL4yFGiIWS38BWvSaiyvV53zoP9KK1KKBMSlup7Zy0X6sK6zH1P42akj2G+uaL9vlWqTtMmPXCDq57LiedOa6KZzsBA4tpCoiGW6+zuHu0OP3EVows2di0aSQEbli5GIbIIJe/U9B+0ANYtBm8lZ7HADgD90/knHufiC261JxfRQ49xrg1hs9n0qDXieZoSZ2/1xaS9EWH5qk1b X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Apr 5, 2023 at 8:09=E2=80=AFPM Andrew Morton wrote: > On Thu, 06 Apr 2023 11:17:12 +0900 Jaewon Kim = wrote: > > > >> + if (len / PAGE_SIZE > totalram_pages()) > > >> + return ERR_PTR(-ENOMEM); > > > > > >We're catering for a buggy caller here, aren't we? Are such large > > >requests ever reasonable? > > > > > >How about we decide what's the largest reasonable size and do a > > >WARN_ON(larger-than-that), so the buggy caller gets fixed? > > > > Yes we're considering a buggy caller. I thought even totalram_pages() /= 2 in > > the old ion system is also unreasonable. To avoid the /2, I changed it = to > > totalram_pages() though. > > > > Because userspace can request that size repeately, I think WARN_ON() ma= y be > > called to too often, so that it would fill the kernel log buffer. > > Oh geeze. I trust that userspace needs elevated privileges of some form? > > If so, then spamming dmesg isn't an issue - root can do much worse than > that. > > > Even we think WARN_ON_ONCE rather than WARN_ON, the buggy point is not = kernel > > layer. Unlike page fault mechanism, this dma-buf system heap gets the s= ize from > > userspace, and it is allowing unlimited size. I think we can't fix the = buggy > > user space with the kernel warning log. So I think warning is not enoug= h, > > and we need a safeguard in kernel layer. > > I really dislike that ram/2 thing - it's so arbitrary, hence is surely > wrong for all cases. Is there something more thoughtful we can do? Just for context, here's the old commit that added this to ION: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit= /?id=3Dc9e8440eca61298ecccbb27f53036124a7a3c6c8 I think the consideration was that allocations larger than half of memory are likely due to erroneously "negative" size values. My memory is foggy on any discussions from that time, but I imagine the thinking was treating the value as if it were signed and error out immediately on negative values, but rather than just capping at 2gb on 32bit systems, one could scale it to half of the system memory size, as that seemed an appropriate border of "obviously wrong". And the reason why I think folks wanted to avoid just warning and continuing with the allocation, is that these large allocations would bog the system down badly before it failed, so failing quickly was a benefit as the system was still responsive and able to be used to collect logs and debug the issue. When you say "decide what's the largest reasonable size", I think it is difficult as with the variety of RAM sizes and buffer sizes I don't think there's a fixed limit. Systems with more ram will use larger buffers for image/video capture buffers. And yes, you're right that ram/2-1 in a single allocation is just as broken, but I'm not sure how to establish a better guard rail. thanks -john