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,URIBL_BLOCKED,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 7D0BAC433E0 for ; Sat, 6 Mar 2021 05:57:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F1D2365005 for ; Sat, 6 Mar 2021 05:57:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1D2365005 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 278186B0006; Sat, 6 Mar 2021 00:57:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2019B6B006C; Sat, 6 Mar 2021 00:57:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 053896B006E; Sat, 6 Mar 2021 00:57:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0111.hostedemail.com [216.40.44.111]) by kanga.kvack.org (Postfix) with ESMTP id D9D826B0006 for ; Sat, 6 Mar 2021 00:57:23 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 84C538249980 for ; Sat, 6 Mar 2021 05:57:23 +0000 (UTC) X-FDA: 77888391966.13.F0BB4F6 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf12.hostedemail.com (Postfix) with ESMTP id 118D3138 for ; Sat, 6 Mar 2021 05:57:20 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id p21so8742188lfu.11 for ; Fri, 05 Mar 2021 21:57:22 -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=nwjJTyix+U1Kuczayf4pZyIBKt0xdJTJx53NO2UO06c=; b=Wh379e/7Ed68GiFHDd0MHYS8RReUXNt8l6QoYwJZ4ulllg/NPnLGjwBzSyCqVvwlNi TI1FTi3cgGzI0otAhZE7g7bngUVmwdm79W81CycG3OSP9KSiP9PLIzFVQ+9FcaDMvfBH pYdIlCH00pbwmJzU4zuUjIq4qUAd3j+OBP6XL77dph2tZDIhrsQBA1aRlVDEpEpC3fAx q9prNhsNZFr7qDLAB5kBvhAlqpHwCXKkMfazieoD8hq9bvH4DVBh/I5yNNxNkTI2MKtU lHEH1AJz6ClSYLOUfgY+T+ztE9j3owXH0Hhuc8Tvj+5Rs2L0dmCF4phS4+zEu/hNRhGo 15Qw== 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=nwjJTyix+U1Kuczayf4pZyIBKt0xdJTJx53NO2UO06c=; b=QAN6uog1yA0lhyrDh3HnWUVyObtZOCmxLdcO2m0VaMvtRlcPTOx+a4G9Rr1u2sB2CE 2FPadBSefHgJfDUU5kSjfnz7KM7VitHqlC8JY0no0/WeuVnxv90zA/QsZW8LlFIVAGG0 U2Gxe/5P4I2taVOWuFmc+IF2I8J8WDMWVWfi5fD59vJByi2supzsZ6C9ZtdnnfasMJCR CRNd9/a+DJTxjhWa2Qsv4G51nnY7n66EvJVEH6942Yt447pmFK7sA4+FJXYYIsYi5bWx zW7IUQfPYwlO5EagNyaoQXzsNkKjCX6fFaJDT1SkR99FH3jJ1RdwXIEdpoIxnIFEQgOi 1CAQ== X-Gm-Message-State: AOAM531vNBJhlW7A26iszn5DVWrasRkEidPRQ30YxKAnefYqL+poREr5 wobprA7DAjj4A37nfz8t7PE= X-Google-Smtp-Source: ABdhPJzpt9b5bh7+ljfymAumEWonaQN+8hHiD1qqEJGWWdDFZ+Jnopl1X0qUt6VH7zue4OrAPvCNDA== X-Received: by 2002:a19:2402:: with SMTP id k2mr8327660lfk.138.1615010241497; Fri, 05 Mar 2021 21:57:21 -0800 (PST) Received: from [192.168.1.39] (88-114-223-25.elisa-laajakaista.fi. [88.114.223.25]) by smtp.gmail.com with ESMTPSA id o11sm555091lfu.157.2021.03.05.21.57.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Mar 2021 21:57:20 -0800 (PST) Subject: Re: [PATCH v3] mm/vmalloc: randomize vmalloc() allocations To: Andrew Morton Cc: linux-hardening@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andy Lutomirski , Jann Horn , Kees Cook , Linux API , Matthew Wilcox , Mike Rapoport , Vlad Rezki , Cristiano Giuffrida References: <20210215202634.5121-1-toiwoton@gmail.com> <20210305171331.2424b166ed4d2d9da73ac335@linux-foundation.org> From: Topi Miettinen Message-ID: <124b32de-2422-615c-90fe-ca5a6d64d179@gmail.com> Date: Sat, 6 Mar 2021 07:57:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <20210305171331.2424b166ed4d2d9da73ac335@linux-foundation.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 118D3138 X-Stat-Signature: 8h9dkmgj4bhc3p3mtyddo5a8mfdbd3gc Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf12; identity=mailfrom; envelope-from=""; helo=mail-lf1-f47.google.com; client-ip=209.85.167.47 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615010240-315411 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 6.3.2021 3.13, Andrew Morton wrote: > On Mon, 15 Feb 2021 22:26:34 +0200 Topi Miettinen wrote: > >> Memory mappings inside kernel allocated with vmalloc() are in >> predictable order and packed tightly toward the low addresses, except >> for per-cpu areas which start from top of the vmalloc area. With >> new kernel boot parameter 'randomize_vmalloc=1', the entire area is >> used randomly to make the allocations less predictable and harder to >> guess for attackers. Also module and BPF code locations get randomized >> (within their dedicated and rather small area though) and if >> CONFIG_VMAP_STACK is enabled, also kernel thread stack locations. >> >> On 32 bit systems this may cause problems due to increased VM >> fragmentation if the address space gets crowded. >> >> On all systems, it will reduce performance and increase memory and >> cache usage due to less efficient use of page tables and inability to >> merge adjacent VMAs with compatible attributes. On x86_64 with 5 level >> page tables, 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. >> >> ... >> > > How useful is this expected to be? What sort of attack scenarios will > this help to defend against? Since there's a clear trade-off between best performance and additional address space randomization, this will not be useful for those who prefer performance. That's also why this is not the default but has to be enabled with a boot parameter. For those who are willing to pay the price for additional hardening, the purpose is to make attacks against KASLR (similar to TagBleed [1]) more difficult since the targeted memory locations may reside anywhere in the 32 TB vmalloc region and knowing one address does not reveal the others. [1] https://download.vusec.net/papers/tagbleed_eurosp20.pdf -Topi