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 2AE53C76196 for ; Thu, 6 Apr 2023 03:46:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B3F16B0071; Wed, 5 Apr 2023 23:46:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5638E6B0074; Wed, 5 Apr 2023 23:46:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 452916B0075; Wed, 5 Apr 2023 23:46:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3210B6B0071 for ; Wed, 5 Apr 2023 23:46:33 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DB095120E5A for ; Thu, 6 Apr 2023 03:46:32 +0000 (UTC) X-FDA: 80649579024.21.44913EB Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) by imf18.hostedemail.com (Postfix) with ESMTP id 2D99D1C000D for ; Thu, 6 Apr 2023 03:46:28 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=S63a4TP0; spf=pass (imf18.hostedemail.com: domain of jaewon31.kim@samsung.com designates 203.254.224.34 as permitted sender) smtp.mailfrom=jaewon31.kim@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680752790; h=from:from:sender:sender:reply-to: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=F6TnWqpipLif1YaNPe5q/YfeK/PMuczMZeivqyAT7qg=; b=ppmmsxluyv9M0lkEDSIB4QIuK+wZwDwSirG7xFFndhyD+iThTPUHlrqHfE5RBDPfAfPUWa uyUumqxdAHTVbEGZ5TET74+obWlub+g+sV84M3N0+IYrbeC+uq8GSAioch5cITMgCWyl6T DoajlpKsMUmCbgqtCpZvluqno7zSNGU= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=S63a4TP0; spf=pass (imf18.hostedemail.com: domain of jaewon31.kim@samsung.com designates 203.254.224.34 as permitted sender) smtp.mailfrom=jaewon31.kim@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680752790; a=rsa-sha256; cv=none; b=zVgBb9I3oXRZBmd8K5Y00uAOdxsZLfp7K10J3OH7y8BVr+jDYvRKo4za9rAMNuCASUmtb5 l5AKOpIOXizdyu3+SwJbcUG3Qbmz7ErR+m4Cg2JjGuiZ2zMkV348eTf24fmTkETVGp+mi8 hcsu/jB+Z23l1dWSF7njAqOBk0tMTYk= Received: from epcas1p4.samsung.com (unknown [182.195.41.48]) by mailout4.samsung.com (KnoxPortal) with ESMTP id 20230406034625epoutp04cb9ddf672af9f935ff9445e6cc770843~TO8DdTytf1445214452epoutp04L for ; Thu, 6 Apr 2023 03:46:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout4.samsung.com 20230406034625epoutp04cb9ddf672af9f935ff9445e6cc770843~TO8DdTytf1445214452epoutp04L DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1680752785; bh=F6TnWqpipLif1YaNPe5q/YfeK/PMuczMZeivqyAT7qg=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=S63a4TP0P3OvwygpAMCi7f3vFyRm0eCOGAvDPVYNSrBoUYojSCxooJiBnNpV8snzE C8BuROHxfayeTE689nf5ZCMBAU8YmsNkXVsEFwq+PkKZCzI4bof9mH4OU52jKKjEiq NAOBPEWkvJWJxc4/1iSYa6Drd1QbMUQSV7DzZv54= Received: from epsnrtp1.localdomain (unknown [182.195.42.162]) by epcas1p4.samsung.com (KnoxPortal) with ESMTP id 20230406034624epcas1p431bbd58d390d872c94473b800d7ff1f0~TO8C9Lnqd2190321903epcas1p4P; Thu, 6 Apr 2023 03:46:24 +0000 (GMT) Received: from epsmges1p4.samsung.com (unknown [182.195.36.222]) by epsnrtp1.localdomain (Postfix) with ESMTP id 4PsS8w41Wsz4x9Py; Thu, 6 Apr 2023 03:46:24 +0000 (GMT) X-AuditID: b6c32a38-5fbfa70000029402-0e-642e40903842 Received: from epcas1p2.samsung.com ( [182.195.41.46]) by epsmges1p4.samsung.com (Symantec Messaging Gateway) with SMTP id 38.EE.37890.0904E246; Thu, 6 Apr 2023 12:46:24 +0900 (KST) Mime-Version: 1.0 Subject: RE: [PATCH v2] dma-buf/heaps: system_heap: Avoid DoS by limiting single allocations to half of all memory Reply-To: jaewon31.kim@samsung.com From: =?UTF-8?B?6rmA7J6s7JuQ?= To: Andrew Morton CC: "jstultz@google.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" X-Priority: 3 X-Content-Kind-Code: NORMAL In-Reply-To: <20230405200923.9b0dca2165ef3335a0f6b112@linux-foundation.org> X-Drm-Type: N,general X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <20230406034624epcms1p3c132d43833c9eee0bd3c470fe16cd7c3@epcms1p3> Date: Thu, 06 Apr 2023 12:46:24 +0900 X-CMS-MailID: 20230406034624epcms1p3c132d43833c9eee0bd3c470fe16cd7c3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Sendblock-Type: SVC_REQ_APPROVE CMS-TYPE: 101P X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAJsWRmVeSWpSXmKPExsWy7bCmnu4EB70Ug2//ZC3mrF/DZrHw4V1m i9WbfC26N89ktOh9/4rJ4s+JjWwWl3fNYbO4t+Y/q8Xrb8uYLU7d/cxu8W79FzYHbo/Db94z e+z9toDFY+esu+weCzaVemxa1cnmsenTJHaPO9f2sHmcmPGbxaNvyypGj8+b5AK4orJtMlIT U1KLFFLzkvNTMvPSbZW8g+Od403NDAx1DS0tzJUU8hJzU22VXHwCdN0yc4AuVlIoS8wpBQoF JBYXK+nb2RTll5akKmTkF5fYKqUWpOQUmBXoFSfmFpfmpevlpZZYGRoYGJkCFSZkZ7R/38hU MFG04tXCtAbGdwJdjBwcEgImEqenFnUxcnEICexglNjwdhYzSJxXQFDi7w5hEFNYoERi8m6F LkZOoBIlibM/rrCD2MIC1hL7F81gArHZBCwltt+cyAhiiwjoSqx6vosZZCSzwEFmiZPXJoMV SQjwSsxof8oCYUtLbF++FayBU8Bb4sXF2cwQcVGJm6vfssPY74/NZ4SwRSRa752FqhGUePBz NyPMnD/Hn7NB2MUSyzofQO2qkVhxbhVU3Fyi4e1KMJtXwFfiw8pOsBtYBFQlml5/Y4WocZGY +vYi2HxmAXmJ7W/ngIOBWUBTYv0ufYgSRYmdv+cyQpTwSbz72sMK89aOeU+g1qpJtDz7ChWX kfj77xmU7SHx6eReJkgwX2CW2LmljWUCo8IsREjPQrJ5FsLmBYzMqxjFUguKc9NTiw0LTOBR m5yfu4kRnHS1LHYwzn37Qe8QIxMH4yFGCQ5mJRFe1S6tFCHelMTKqtSi/Pii0pzU4kOMpkA/ T2SWEk3OB6b9vJJ4QxNLAxMzIxMLY0tjMyVx3i9PtVOEBNITS1KzU1MLUotg+pg4OKUamOY7 Wgl4dM35v5btKJdTYDtT5e8Mqxl7b+WazVmx5a/wXadrbkc3m6ZLzDX9V/hhG+ODx08/RoT6 f2dSPnciomRGbky5ls+7d486Jy9l2SraeSnIbGrLhfsvZULOxU4q/WLCzNVb/ypBfW6NcI1b 67sTyYqvd/suUl8+y0+jI/dUaqh70+v/bs/5mRZqx32xfvVJrvlUSpbP6y2qTNuNRaac/6/5 61e6ubfLnKblNatns8odEWfc/Jv5WvXp/ijWB7KOy4UzTlxN/vQn6A3H3dpaoanVtlVatVcv 2cuXu19v+GV1p6PsSSbH7L21L+bIVpy7aWdnY8Dx81zSnZjWKUlbyu1fK7SryqrXLLJgUmIp zkg01GIuKk4EAH+KRW5DBAAA DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20230406000841epcas1p3630010a770682be0f1d540a448f3e00e References: <20230405200923.9b0dca2165ef3335a0f6b112@linux-foundation.org> <20230405185650.239f9721f066aa480e83d543@linux-foundation.org> <20230405172524.e25b62e1c548a95564b1d324@linux-foundation.org> <20230406000854.25764-1-jaewon31.kim@samsung.com> <20230406014419epcms1p3f285b6e3fdbb1457db1bcbaab9e863be@epcms1p3> <20230406021712epcms1p216f274040d25d18380668ffbfa809c48@epcms1p2> X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 9qa7zpdhzd9yarymuk3wk83hj6bwrqsj X-Rspamd-Queue-Id: 2D99D1C000D X-HE-Tag: 1680752788-155443 X-HE-Meta: U2FsdGVkX18vsRylPI6u6JU6PhwMSIBV3sZdf9I4AypoAvDEvFnTLNlKV6thWCPoHEi99VzULQ3QMdU4P+6CRz9sJnADEkVtwWxYxOq1MpN9hiEpqdWN/T5hmVxYwpbvumttHsNWgnN3JTH0TC3iXt1CIhUAHGB49vZTnp7mWZ6ZJrK3dSWfy0/FutJLtU7qVEv5rSrv6LqR/Sbm3dRbhXrUauVAjIJtmehjQH8jNf4n6YQu42pr7BchQu9GTfZ+VqCuVDYsB9b12KG85hG8N7aRpYWOl96XBlMbKK2rPggFnwKCAMO3JYoPkhOQRQZixpQ9Erqzo0Ols5tWHF/SZzwWAaiv+4/a07rzljAVMZ9n2+U/snsxgzotdoRz47R/AHBrSqJyi3dgQ4ekRQJhi3r1j43CEYcNFANgRNb3RqFqP8Dw7Uq+2xcvhVQbJi5EZZyzxDgN6rM2uvTL6OiLea85OuiwS1bxjlnspSsLpygKwgsePFdvYNPgsi2M1yl9p2n3Bh1JJc6MgBdLDqQHx9stofDPMyI+tse+kGnlEkG07fJSXaktNNRN1qV2VrRRQM4BhE2/Hel4agJhQzpbc/Ig9wYMlRKJCfsQecmRkM6NMbE4bsbgGEd8B2xJpsUttmrHAa9w9AmYS8FLjF4uRE48cO7Khj22vy0F0arywzD0f0sC7H2WQJHgpx9KqBfrwpRTA9UNUSHQq/GtVmrmSH+b7j5qqqb+MwoVQ4CRQSgySPTlJVs8ghiTgZDGCEeKsmmF6Wd+JXLIarRePn7ad/yjUoP6xfhuc+MtjpC5WaVodD2TWqG5A6JuAIKQcj4v7CLbWP0WrFnvAPtYajuD+hzpSGQnW4GqO5YHFhzHdc9gPrMtaMCWawKgS49rBh1X1Qa+YInI6FIEotq9VjN0QXJBUG/KJznwItKLgeNoYxJlvcmKM/U60ZL2jwOJ6DhfDot47vWJO4zQGA3mZiz 8Ms9fooe rlmqjCRbsgpTkYwD2MUtxTB9baVTC0efFA7s4mYmgjuRc97bL5HpkL1b8eBzZFE+B3O8PBHOkjUEr6XK4+vLiJRMqqX1o73PxVRdwGHCPt01AAUVbbg/7kjB5qT64D6D/bQa3DhD3Ky+ISCuY37u7wo3znjmZwcvxKJpbGZ3nVXvc7PBNQidpK+tnbUu6zLoF/F/L+HM8Ey3xq329hfWfWof7weRgEBXE/+MyKBhcxZw5EnPcCcUGhoGRsGrvfXb8O30sAF7ns6PFrTz1SltfSrv10MlBoblo23tgcYy6Ei9xl3SGbtiuySlNUH+QMJVOnPPFTOvvHepxuMlQ/klm8U8rpFOomRbFDFy751BGcDENkNQB6zWYrWD9OgzEddUw2X3OS6c7QEPy13I= 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 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() may 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? > I'm sorry I don't know the whole Android dma-buf allocation process. AFAIK Android apps do not allocate itself, they request dma-buf memory to the Android system process named of Allocator. Then the Allocator seems to have privileges to use the dma-buf heap. So normal Android apps do NOT need the privileges. >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 size 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 enough, >> 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? > >I mean, top priority here is to inform userspace that it's buggy so >that it gets fixed (assuming this requires elevated privileges). And >userspace which requests (totalram_pages()/2 - 1) bytes is still buggy, >but we did nothing to get the bug fixed. That ram/2 seems to be arbitrary, but I thought just ram, not ram/2, is reasonble as a safeguard in kernel side even after the userspace process or common library check the abnormal size. I thought the userspace context would get -ENOMEM either in ram case or in __GFP_RETRY_MAYFAIL case. And -ENOMEM is enough to inform. The usespace may not fully recognize that it is buggy though. I'm not sure that all the userspace context use the Android libdmabufheap library and there is no other route directly using kernel dma-buf heap ioctl. Anyway do you think size checking code should be added to the libdmabufheap rather than kernel side?