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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3072FC433FE for ; Thu, 3 Dec 2020 17:10:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 70CBC207A4 for ; Thu, 3 Dec 2020 17:10:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 70CBC207A4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amacapital.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DB08C6B0036; Thu, 3 Dec 2020 12:10:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D604D6B005C; Thu, 3 Dec 2020 12:10:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9E648D0001; Thu, 3 Dec 2020 12:10:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id B4CA26B0036 for ; Thu, 3 Dec 2020 12:10:36 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7D137181AEF39 for ; Thu, 3 Dec 2020 17:10:36 +0000 (UTC) X-FDA: 77552610072.28.tent77_3608dd4273bd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 4E6276C17 for ; Thu, 3 Dec 2020 17:10:36 +0000 (UTC) X-HE-Tag: tent77_3608dd4273bd X-Filterd-Recvd-Size: 6385 Received: from mail-pj1-f68.google.com (mail-pj1-f68.google.com [209.85.216.68]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Dec 2020 17:10:35 +0000 (UTC) Received: by mail-pj1-f68.google.com with SMTP id e5so1446495pjt.0 for ; Thu, 03 Dec 2020 09:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=4wqJAr+3mpm/N6KJzqVQL+ect217rAtwLlAfBe3bNfU=; b=RUpr5VZUHli+Ntwv2HIrEYZtLYBEEv6FNALrE6RP7YH8Rp64IWqY/Vt5nTVO9/Iym8 6UXCb8g35dfhhQFS8+DQ2eKMD8FGry9BPw9O3lYqILTj64tncHFMp5EcV8SaG6aFz49l byMvlQXxbusISO7b71ScAE29NClhYK7CA122Q4v/QVVsMt4NR12xG8+4gZ/emDJmzaix kFj4kUN38sJx0N5x4piMmqy3Yonk+pjZRyfppCtCkyz/ikxSHPNQYrE+RYDgsVSvQlaz DtCKsv6LIBK9eiWignxuAGpCEiTdoaRqh3MejdDxZ4Z536dfz3uJIM/ldSdwQsO2RNcd VaWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=4wqJAr+3mpm/N6KJzqVQL+ect217rAtwLlAfBe3bNfU=; b=Rjh0cr0Xvevh8C2Kv8NPm5Sfxv+1Haadlb7vGfipbDhRhG+ehUgS8o+kfcUMdYwRPo SLfAGWqe4dqP9tua2/TKivpOC6Xfe6eXX0Oi+03wXj8cR4SY/5vG4aZME1gvx38wMuxx xayrSvWJc39RgsYNqh5t7ioa45HZrLIoFSO9F5i1iyeZH9+B2em+oMoSHuNnOZWheZ8t rgG+Rgj4tkR/iy8/FnA5DMy0eXI4LTSKb5KOQSD6cAlwLW19oEK+rIXPLhGq8Sm4sUri H9WbpysEnvpDgvvdmcD/zF13Ahlj+vXDcMma40IwV9FayNNDmu2NMypDBeb9wQOBcM// Nu+A== X-Gm-Message-State: AOAM532A2AMc/K/Z+iKV0tcCkJCMkTY+Kz6VwGgFSIN+2aCt3uAl8g0e LoLK3HvogoDQZhZsvtsIuPIo2w== X-Google-Smtp-Source: ABdhPJzZH2GWI6Hb1FX9L3mqyG6e5XSBr1WrgxKkqVdZE4ZdV1mmD4gMFvPc+9loGtWXO9plcLzfHA== X-Received: by 2002:a17:90b:117:: with SMTP id p23mr71511pjz.111.1607015434516; Thu, 03 Dec 2020 09:10:34 -0800 (PST) Received: from ?IPv6:2600:1010:b02c:6432:59d6:b4ed:32aa:4315? ([2600:1010:b02c:6432:59d6:b4ed:32aa:4315]) by smtp.gmail.com with ESMTPSA id n127sm2369930pfd.143.2020.12.03.09.10.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Dec 2020 09:10:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v5] mm: Optional full ASLR for mmap(), mremap(), vdso and stack Date: Thu, 3 Dec 2020 09:10:32 -0800 Message-Id: <05D72EA3-4862-4D80-82F5-9369834C3461@amacapital.net> References: Cc: Florian Weimer , linux-hardening@vger.kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jann Horn , Kees Cook , Matthew Wilcox , Mike Rapoport , Linux API In-Reply-To: To: Topi Miettinen X-Mailer: iPhone Mail (18B121) 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 Dec 3, 2020, at 4:06 AM, Topi Miettinen wrote: >=20 > =EF=BB=BFOn 3.12.2020 11.47, Florian Weimer wrote: >> * Topi Miettinen: >>> +3 Additionally enable full randomization of memory mappings created >>> + with mmap(NULL, ...). With 2, the base of the VMA used for such >>> + mappings is random, but the mappings are created in predictable >>> + places within the VMA and in sequential order. With 3, new VMAs >>> + are created to fully randomize the mappings. >>> + >>> + Also mremap(..., MREMAP_MAYMOVE) will move the mappings even if >>> + not necessary and the location of stack and vdso are also >>> + randomized. >>> + >>> + On 32 bit systems this may cause problems due to increased VM >>> + fragmentation if the address space gets crowded. >> Isn't this a bit of an understatement? I think you'll have to restrict >> this randomization to a subregion of the entire address space, otherwise >> the reduction in maximum mapping size due to fragmentation will be a >> problem on 64-bit architectures as well (which generally do not support >> the full 64 bits for user-space addresses). >=20 > Restricting randomization would reduce the address space layout randomizat= ion and make this less useful. There's 48 or 56 bits, which translate to 128= TB and 64PB of VM for user applications. Is it really possible to build toda= y (or in near future) a system, which would contain so much RAM that such fr= agmentation could realistically happen? Perhaps also in a special case where= lots of 1GB huge pages are necessary? Maybe in those cases you shouldn't us= e randomize_va_space=3D3. Or perhaps there could be randomize_va_space=3D3 w= hich does something, and randomize_va_space=3D4 for those who want maximum r= andomization. If you want a 4GB allocation to succeed, you can only divide the address spa= ce into 32k fragments. Or, a little more precisely, if you want a randomly s= elected 4GB region to be empty, any other allocation has a 1/32k chance of b= eing in the way. (Rough numbers =E2=80=94 I=E2=80=99m ignoring effects of t= he beginning and end of the address space, and I=E2=80=99m ignoring the size= of a potential conflicting allocation.). This sounds good, except that a pr= ogram could easily make a whole bunch of tiny allocations that get merged in= current kernels but wouldn=E2=80=99t with your scheme. So maybe this is okay, but it=E2=80=99s not likely to be a good default. >=20 >>> + On all systems, it will reduce performance and increase memory >>> + usage due to less efficient use of page tables and inability to >>> + merge adjacent VMAs with compatible attributes. In the worst case, >>> + additional page table entries of up to 4 pages are created for >>> + each mapping, so with small mappings there's considerable penalty. >> The number 4 is architecture-specific, right? >=20 > Yes, I only know x86_64. Actually it could have 5 level page tables. I'll f= ix this in next version. >=20 > -Topi