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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 7302DC433E0 for ; Tue, 5 Jan 2021 20:22:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C4E1A22D5A for ; Tue, 5 Jan 2021 20:22:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C4E1A22D5A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=alum.mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id ED5298D00B0; Tue, 5 Jan 2021 15:22:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E853E8D006E; Tue, 5 Jan 2021 15:22:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D26428D00B0; Tue, 5 Jan 2021 15:22:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id BBD338D006E for ; Tue, 5 Jan 2021 15:22:27 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7FE90362C for ; Tue, 5 Jan 2021 20:22:27 +0000 (UTC) X-FDA: 77672843934.26.noise04_1d0d603274db Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 529531804B66A for ; Tue, 5 Jan 2021 20:22:27 +0000 (UTC) X-HE-Tag: noise04_1d0d603274db X-Filterd-Recvd-Size: 5950 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 Jan 2021 20:22:26 +0000 (UTC) Received: by mail-qt1-f177.google.com with SMTP id u21so627565qtw.11 for ; Tue, 05 Jan 2021 12:22:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=SRfCUh4MRhybAEQ9/+GMU/8+t4gXrLcq9Kpvuz0GiVQ=; b=M7Nmn5jW8bYjWhttNtTEgslGyI+UnqFTO6qbYf96CtDwO9qHaGM4j0zGynQEXJWTi6 smwtiLfPDppAXsMKeP6maWCDVg41d7HQ002s8reSyFO1A+4deVC/NLs8Qo3FRDaICqby j7cUSxm0626VSD+3mg86bWJrGyGrhsrl/aNkjaJ06pFe0eONvmRyPY8bnRDxWoUEfGmt Axy19we7YvpduLlml8YWtz42is//PDwdIwvEMRLqOyI60cpqYfeJdfUVOkfmoKjrY6+e ouTdOSNXNSH/DyTPkUfBJw8J6R1vqgvuxReeORr+0Zg6r7kC/szsBi0yLjKKVXevJCRM vFSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=SRfCUh4MRhybAEQ9/+GMU/8+t4gXrLcq9Kpvuz0GiVQ=; b=GT1NVhSFoT9q63x6dsDGXStsTDAHicLXuI6m2LgWBxmXghpjOetQQxDHEjgQpT6MUR 4owUD5P5XLDQSd5VT3t/5WeFgw7QqZWIQoDoJCkn2ox6I8KV+xMbu+LForubKZsKc8ZY wwD7Wp1lMw3crkZvpxWAa613O9vhlw2Hra2ZRteO7e1ZFDGLNhaYgk3d8AFKBgqvIZrm T1ZYmY4SpoHyEay5qaPFZgUa9iBHE/cX1cXdGTQkqGP8CKhMyRpejuqkDtA4o3Z8kmMZ 6NDGTE5dyg6xT6IFKVNNurQNFVBd2hYr1r/b853G3ZN3rkGvtMYupx4FzdqQIBfCEe3F hqMA== X-Gm-Message-State: AOAM532aVKeFoARylNHilkPDOEqXB2rUeAEKKshj0vw2TpODab5e1/6c 93JhOlfqyqZVujDNh37SmaU= X-Google-Smtp-Source: ABdhPJw8tHKmQz3IKI2oNdEouBDR+n9F6E4NvF7TwgksuOFPpGoV2m3k6fN5sWhnDl0gsKwzDGYxKQ== X-Received: by 2002:aed:2123:: with SMTP id 32mr1162365qtc.325.1609878146142; Tue, 05 Jan 2021 12:22:26 -0800 (PST) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id t5sm129936qte.20.2021.01.05.12.22.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Jan 2021 12:22:25 -0800 (PST) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Tue, 5 Jan 2021 15:22:23 -0500 To: Pan Zhang Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, nivedita@alum.mit.edu, keescook@chromium.org, jroedel@suse.de, hushiyuan@huawei.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/kaslr: support separate multiple memmaps parameter parsing Message-ID: References: <20201222113124.35367-1-zhangpan26@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201222113124.35367-1-zhangpan26@huawei.com> Content-Transfer-Encoding: quoted-printable 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 Tue, Dec 22, 2020 at 07:31:24PM +0800, Pan Zhang wrote: > When the kernel is loading, > the load address of the kernel needs to be calculated firstly. >=20 > If the kernel address space layout randomization(`kaslr`) is enabled, > the memory range reserved by the memmap parameter will be excluded > to avoid loading the kernel address into the memmap reserved area. >=20 > Currently, this is what the manual says: > `memmap =3D nn [KMG] @ss [KMG] > [KNL] Force usage of a specific region of memory. > =C2=A0=C2=A0=C2=A0=C2=A0 Region of memory to be used is from ss to ss += nn. > =C2=A0=C2=A0=C2=A0 If @ss [KMG] is omitted, it is equivalent to mem =3D= nn [KMG], > =C2=A0=C2=A0=C2=A0=C2=A0 which limits max address to nn [KMG]. > Multiple different regions can be specified, > comma delimited. > Example: > memmap=3D100M@2G, 100M#3G, 1G!1024G > ` >=20 > Can we relax the use of memmap? > In our production environment we see many people who use it like this: > Separate multiple memmaps parameters to reserve memory, > memmap=3Dxx\$xxx memmap=3Dxx\$xxx memmap=3Dxx\$xxx memmap=3Dxx\$xxx mem= map=3Dxx\$xxx >=20 > If this format is used, and the reserved memory segment is greater than= 4, > there is no way to parse the 5th and subsequent memmaps and the kaslr c= annot be disabled by `memmap_too_large` > so the kernel loading address may fall within the memmap range > (reserved memory area from memmap after fourth segment), > which will have bad consequences for use of reserved memory. >=20 > Signed-off-by: Pan Zhang > --- > arch/x86/boot/compressed/kaslr.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) >=20 > diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compresse= d/kaslr.c > index d7408af..24a2778 100644 > --- a/arch/x86/boot/compressed/kaslr.c > +++ b/arch/x86/boot/compressed/kaslr.c > @@ -203,9 +203,6 @@ static void mem_avoid_memmap(enum parse_mode mode, = char *str) > { > static int i; > =20 > - if (i >=3D MAX_MEMMAP_REGIONS) > - return; > - > while (str && (i < MAX_MEMMAP_REGIONS)) { > int rc; > unsigned long long start, size; > @@ -233,7 +230,7 @@ static void mem_avoid_memmap(enum parse_mode mode, = char *str) > } > =20 > /* More than 4 memmaps, fail kaslr */ > - if ((i >=3D MAX_MEMMAP_REGIONS) && str) > + if ((i >=3D MAX_MEMMAP_REGIONS) && !memmap_too_large) I think this should stay the way it was, otherwise KASLR will be disabled even if exactly MAX_MEMMAP_REGIONS were specified. Removing the early return as you did above should be enough to cause the flag to be set if a 5th memmap is specified in a separate parameter, right? > memmap_too_large =3D true; > } > =20 > --=20 > 2.7.4 >=20