Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9980835ybi; Wed, 24 Jul 2019 13:28:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqxvwyfTkoVdtUJUfIiaphdrHCotU1CaViN1qDcZeScncgAJHynOFPkDET0Fk4SUzTRFbhdO X-Received: by 2002:a17:90a:1ae2:: with SMTP id p89mr84576854pjp.26.1564000117339; Wed, 24 Jul 2019 13:28:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564000117; cv=none; d=google.com; s=arc-20160816; b=R4sI1A1dudoAG20rDcReybSYSHaG4IJCrW3TTCAUyUiTjP+OYekgRpRb5kz1xT8q6/ SFCJnUFBmmALR8eyIwRet0oGv/rQwRPNBlcv4iKpxfkXjPYZuo09KyCRplVeeZ80FvKS mUrEWwU99sYzJM73RUrC8yoJU8eA+rFNxjw930AE4LAnQVESk8HOTKscLUHjlQQ5nt/W oVyDza4NpMy9ylblhgNRkNKeTSHwhFTlu9jWc+49gkXRWlR3mwsIgHwgRMIxna0XSN+P rzcAEl2sKtjpgcjhiqnljNUKqVx0n/BeTaYuR8Tzd6GCf2G/lcNppS/0fYc9Zq74htPe wZ2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject; bh=Z7pnaGuYc9LFLbT5aUxNfUlnE7ek1gcnJ4zW5L3HylM=; b=b/DoRpEDNKvvkDK/8A17YHAcXUW6qwznzZSR5kkGaw9rkeJTJkbVS0TKf0HbUNnl3h XPQejXll1DOJ9yJdunAmtFAqHTuVpC04pb/sp1i8y+vFY2jhUspAIDERoLQzdShiv5Zd q3Z9ZAMG1WB/lkvCqUMybveDjiCJMx9kR04CZ3ZOkaiAdw9wDuv4r0mip9Oy98pTseX3 28U3vQmSFrG1rtEabOk8gi7D0u3tGDp4tpVodwrFTbGEaSKpFHuVdk/QLqsKmZGzhIA1 HmmwkRzbb7V/k2L/iT0eP7qJsOfWJOLb8EUHl6bEmoRG+oTCXaTdegCU4RM/kUA+CSG4 kUEA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j5si15487892pjf.60.2019.07.24.13.28.22; Wed, 24 Jul 2019 13:28: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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389849AbfGXU0k (ORCPT + 99 others); Wed, 24 Jul 2019 16:26:40 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:41335 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389369AbfGXThA (ORCPT ); Wed, 24 Jul 2019 15:37:00 -0400 Received: by mail-qt1-f196.google.com with SMTP id d17so46612799qtj.8 for ; Wed, 24 Jul 2019 12:36:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Z7pnaGuYc9LFLbT5aUxNfUlnE7ek1gcnJ4zW5L3HylM=; b=AJa24WOUq6QNmfM7o3lefePyApLJXuhnHzamOGyebk6ymmpiolLwxmEuGo5tezWLSx ig6YpsdAxKT6H60lVG9DQ2ec8WehibgI8QLPAa/Y84/QedB5FRiiSUS+5aVEF+MZ1i26 p14SMIxISzs+2sjoC+OsIYIaLVtmG4isG2H5Is2DAMWtcow4siohVOIPSStq13IyMCQt I1ES7Dz/kAtl/GdZcTj/G1mpEssieeywF+NLIWweTl5YxjC28KKVXRDcyIStIWNtiYhP NBOXj1zDmtGF/EU8ibDau+HULhL8X1S5oxL0nAZ4YXUKcbWC+9hol9KI2Iczo3tSBrs2 aG8Q== X-Gm-Message-State: APjAAAV27pGpphHefrD08+ghm1u/wxw2djID6EtPDXGxHB68VSwbIzZr Qc9CEVO3iTlPTtSwdqejOLUolg== X-Received: by 2002:ac8:1887:: with SMTP id s7mr59031081qtj.220.1563997018800; Wed, 24 Jul 2019 12:36:58 -0700 (PDT) Received: from [192.168.1.157] (pool-96-235-39-235.pitbpa.fios.verizon.net. [96.235.39.235]) by smtp.gmail.com with ESMTPSA id q17sm16672031qtl.13.2019.07.24.12.36.57 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 12:36:58 -0700 (PDT) Subject: Re: Limits for ION Memory Allocator To: alex.popov@linux.com, Sumit Semwal , Greg Kroah-Hartman , arve@android.com, Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Riley Andrews , devel@driverdev.osuosl.org, linaro-mm-sig@lists.linaro.org, linux-arm-kernel , dri-devel@lists.freedesktop.org, LKML , Brian Starkey , Daniel Vetter , Mark Brown , Benjamin Gaignard , Linux-MM , Dmitry Vyukov , Andrey Konovalov , syzkaller@googlegroups.com, John Stultz References: <3b922aa4-c6d4-e4a4-766d-f324ff77f7b5@linux.com> From: Laura Abbott Message-ID: <40f8b7d8-fafa-ad99-34fb-9c63e34917e2@redhat.com> Date: Wed, 24 Jul 2019 15:36:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <3b922aa4-c6d4-e4a4-766d-f324ff77f7b5@linux.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/17/19 12:31 PM, Alexander Popov wrote: > Hello! > > The syzkaller [1] has a trouble with fuzzing the Linux kernel with ION Memory > Allocator. > > Syzkaller uses several methods [2] to limit memory consumption of the userspace > processes calling the syscalls for testing the kernel: > - setrlimit(), > - cgroups, > - various sysctl. > But these methods don't work for ION Memory Allocator, so any userspace process > that has access to /dev/ion can bring the system to the out-of-memory state. > > An example of a program doing that: > > > #include > #include > #include > #include > #include > #include > > #define ION_IOC_MAGIC 'I' > #define ION_IOC_ALLOC _IOWR(ION_IOC_MAGIC, 0, \ > struct ion_allocation_data) > > struct ion_allocation_data { > __u64 len; > __u32 heap_id_mask; > __u32 flags; > __u32 fd; > __u32 unused; > }; > > int main(void) > { > unsigned long i = 0; > int fd = -1; > struct ion_allocation_data data = { > .len = 0x13f65d8c, > .heap_id_mask = 1, > .flags = 0, > .fd = -1, > .unused = 0 > }; > > fd = open("/dev/ion", 0); > if (fd == -1) { > perror("[-] open /dev/ion"); > return 1; > } > > while (1) { > printf("iter %lu\n", i); > ioctl(fd, ION_IOC_ALLOC, &data); > i++; > } > > return 0; > } > > > I looked through the code of ion_alloc() and didn't find any limit checks. > Is it currently possible to limit ION kernel allocations for some process? > > If not, is it a right idea to do that? > Thanks! > Yes, I do think that's the right approach. We're working on moving Ion out of staging and this is something I mentioned to John Stultz. I don't think we've thought too hard about how to do the actual limiting so suggestions are welcome. Thanks, Laura > Best regards, > Alexander > > > [1]: https://github.com/google/syzkaller > [2]: https://github.com/google/syzkaller/blob/master/executor/common_linux.h >