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=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 62C4DC63777 for ; Thu, 3 Dec 2020 12:02:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BF94F20872 for ; Thu, 3 Dec 2020 12:02:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF94F20872 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3BFF36B0070; Thu, 3 Dec 2020 07:02:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 36E378D0002; Thu, 3 Dec 2020 07:02:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 283AF8D0001; Thu, 3 Dec 2020 07:02:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 0F99B6B0070 for ; Thu, 3 Dec 2020 07:02:29 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C3358363F for ; Thu, 3 Dec 2020 12:02:28 +0000 (UTC) X-FDA: 77551833576.27.hall98_6315091273bb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 9ED103D669 for ; Thu, 3 Dec 2020 12:02:28 +0000 (UTC) X-HE-Tag: hall98_6315091273bb X-Filterd-Recvd-Size: 5639 Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Dec 2020 12:02:28 +0000 (UTC) Received: by mail-lj1-f171.google.com with SMTP id t22so2273176ljk.0 for ; Thu, 03 Dec 2020 04:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=IaH1Ay2WDIAxMFtXzoOalR9PJQnL9IHu/7OpcWmCb60=; b=GqwPxheJDKpMMqbf8GKtCQsRNdkZ9ty6yZMmX6GnvUKlV8uPMeTHJAWdu0SBMriDtz t/lSst+rrTVjLuyRcEtwSE+uQGscgLF5LcBHrqxErP3K/8K0mc5blLZcS/IpnyfADSq/ 7B5vQViuH30s4qz6gP6RqkB/NGf59Fv42R/uVzopGsPW8tSqVRjstXsgx0XVmWIdyQNU +sehwVV5DSpWBdFXfjmCr+hPaIveMTNvIi+gpim6bOo/njHtZZZusWOxX0nGW0h6BiQr SNB0hrrz25XEhG6Qgw70P0FBtrfsmskcFnm7j0vAzrhS2czUcX1UQEV1aXV9qUMnEY3t zrAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IaH1Ay2WDIAxMFtXzoOalR9PJQnL9IHu/7OpcWmCb60=; b=F+LsUyK5Emig2JIL75WnJ67/uINdYsFP/+KzfXwJiEA3pMvpity4hoPomCUmm2lDV+ Z4AfF7AI1VP1xmgGTmxUwTXvUEDAub2n7L60/w+y1xBQx1bKLAndU/N+KoDDei2rJLzn br/6+8hJL5dIVq8Yf6t2ibQX0UdfXWo/dCFQuhZmzFcH6dzerG38ABOfTU1xEVZQLxlD Ty9R7vh+d/boD5KXuymoectjkc7tCLkrNjF2YEyciV83flb+hMqCa/EsqRv4yaGBmNtt 0G21WIvtXe3AGVhytPTeryxotrhZ0GLmqX5a+jHXDZb1RAMQFaYEVGPbHFQs88IKkXLC GZ/A== X-Gm-Message-State: AOAM530v/Mm6rbAx5cl4JcBPp11dVyXg3ah9QFUAe4i8n6YR5764Xlln PoFC4tTtWFQhHxBViQC6KgU= X-Google-Smtp-Source: ABdhPJyCzognIJDPh7B1KJBBA0Nm3ojFxr32mjSG1N0v0D144se4CngiUAVcQ5T5T5QBJYTOlu8EUA== X-Received: by 2002:a2e:9550:: with SMTP id t16mr1098917ljh.117.1606996946693; Thu, 03 Dec 2020 04:02:26 -0800 (PST) Received: from [192.168.1.40] (88-114-216-158.elisa-laajakaista.fi. [88.114.216.158]) by smtp.gmail.com with ESMTPSA id h23sm443031lfk.148.2020.12.03.04.02.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Dec 2020 04:02:26 -0800 (PST) Subject: Re: [PATCH v5] mm: Optional full ASLR for mmap(), mremap(), vdso and stack To: Florian Weimer Cc: 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 References: <20201129211517.2208-1-toiwoton@gmail.com> <87im9j2pbs.fsf@oldenburg2.str.redhat.com> From: Topi Miettinen Message-ID: Date: Thu, 3 Dec 2020 14:02:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <87im9j2pbs.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 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). Restricting randomization would reduce the address space layout randomization and make this less useful. There's 48 or 56 bits, which translate to 128TB and 64PB of VM for user applications. Is it really possible to build today (or in near future) a system, which would contain so much RAM that such fragmentation could realistically happen? Perhaps also in a special case where lots of 1GB huge pages are necessary? Maybe in those cases you shouldn't use randomize_va_space=3. Or perhaps there could be randomize_va_space=3 which does something, and randomize_va_space=4 for those who want maximum randomization. >> + 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? Yes, I only know x86_64. Actually it could have 5 level page tables. I'll fix this in next version. -Topi