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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 F2738C433DB for ; Tue, 16 Feb 2021 14:36:25 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AFD1464E04 for ; Tue, 16 Feb 2021 14:36:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AFD1464E04 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=soleen.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=DX025HOaYAW1mMVRVv0nbVgP1jJaY/DwcRRKklbFNMQ=; b=w/AciQZesznr9m41uWhu2a3D9 l6UpwFrYLkL2r4xZvkJIFipLvNhq6Nrox/u2h2or38ZDjV62wRxkm0R9gedtnXKnS8q2ZOtYU6szv Kbb0IdgCukDx8HUNlbu+hVJZZ1mf2rnB0ZpC734Cr0fDofcIEnLCYkY7WMnfx0//Q72dx9KSRJ1u9 LQhNXiDFG2eJxZ9aC+6J1mJGyLzNYChMwHd/5I08xNzeYnWFp959RX7Ph/Nq8GUr9gxJHw4p9r4oA aoxFrHyY/k//QhRjJTCi0CoOysPyC63HDN+LVBAof97ip5IIy68WW9mce3K1HjTdi3IXw5V+HymR4 eg5fIkSHQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lC1RA-0002MD-Eu; Tue, 16 Feb 2021 14:34:48 +0000 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lC1R6-0002L9-W6 for linux-arm-kernel@lists.infradead.org; Tue, 16 Feb 2021 14:34:46 +0000 Received: by mail-ej1-x631.google.com with SMTP id f14so16881387ejc.8 for ; Tue, 16 Feb 2021 06:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LXRiNtgUJwndRsbowN5g0iH/tQxeuxW4thto5ZiApR0=; b=I6FNoD27ClHApeRICS8igOg6GXBDMvQQOUo0JtWmU9cfbZ1VwK9cjTUWbH/UitP80T 3r9frClCF7vjAQVCLpPZNR4AMKEGkdUpLp0AVn0uc5KHkZ4pWqmSvvCyS6dYSTTeOyuH 3tNgwCN+E7GLYB9nsr2N9JgMXJL9ArV6z9WlBLe/f0w+1MLFzSHGvQf9dVB2fQ2gLIko 4jSlIKCKh5npaKdy0yqMahIzfe/cE7E92xBe9h6poDXyBgilOPfNAy/Du9WUCHy9CdKN Hm1gKYzTwB/Ur0SZltsm2oMh5nJKkBzua4h98S/UHeW/5tk9lyVy5nrzjASJtHKDCwpz YRCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LXRiNtgUJwndRsbowN5g0iH/tQxeuxW4thto5ZiApR0=; b=VlJzwT1AqrYZrUf/mhlc/UTu6+IKpm1ytydA8o+PooDrSpCLv8tQ/Y/yQmEsIB7bGq q1p7tGrN6p7HfUCcCmwixKJU87jxXG5A8LIv0dm/A+fzSPml5VJAS27EK2mGtJ52lY5g 7c/bBsKvaoU1juKPVFTVQ0zHY5L6jcS/KI/O89QW5Bv7WVyEL5hBXR+IkLLoIVfALizP wEYxcj3FWnvPnN0lP/+B7v5Kf6rWkcSPUhZXzxjutjMPjRHHP210ObUy6oTz0ZabCsMj Ii1S7ByVc17ZbHMMF0UOOSIFmxcVWu71pjnmuTIM0CgqoW+b9Xciv8n5UgtBhUI2+C2k Zvjw== X-Gm-Message-State: AOAM530r0M6U78vJnpGzQU8LGInVPIJrPIsg6uPn93ZjGuZb04k0dCtd aCQFvzJQeyHB0yAohXDZ8VOxb3Ox/Ms2Jwr02SwNTg== X-Google-Smtp-Source: ABdhPJxe3JZquTx8iHbeMFUWrLTUhi6f8WF2y20pflxVUJtnIevMkkDU3HlZTBVF9ifTC1Q1+s3IRsO+xfX1eg1R3hY= X-Received: by 2002:a17:906:28cc:: with SMTP id p12mr437289ejd.426.1613486080796; Tue, 16 Feb 2021 06:34:40 -0800 (PST) MIME-Version: 1.0 References: <20210215192237.362706-1-pasha.tatashin@soleen.com> <20210215192237.362706-2-pasha.tatashin@soleen.com> <1790afff-eebd-1eda-a1b4-0062908f1f32@arm.com> In-Reply-To: From: Pavel Tatashin Date: Tue, 16 Feb 2021 09:34:04 -0500 Message-ID: Subject: Re: [PATCH v2 1/1] arm64: mm: correct the inside linear map boundaries during hotplug check To: Ard Biesheuvel X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210216_093445_456109_99EFDD6D X-CRM114-Status: GOOD ( 32.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Anshuman Khandual , Catalin Marinas , James Morris , Linux Kernel Mailing List , Logan Gunthorpe , Tyler Hicks , Linux ARM , Andrew Morton , Will Deacon , Mike Rapoport Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Feb 16, 2021 at 2:36 AM Ard Biesheuvel wrote: > > On Tue, 16 Feb 2021 at 04:12, Anshuman Khandual > wrote: > > > > > > > > On 2/16/21 1:21 AM, Pavel Tatashin wrote: > > > On Mon, Feb 15, 2021 at 2:34 PM Ard Biesheuvel wrote: > > >> > > >> On Mon, 15 Feb 2021 at 20:30, Pavel Tatashin wrote: > > >>> > > >>>> Can't we simply use signed arithmetic here? This expression works fine > > >>>> if the quantities are all interpreted as s64 instead of u64 > > >>> > > >>> I was thinking about that, but I do not like the idea of using sign > > >>> arithmetics for physical addresses. Also, I am worried that someone in > > >>> the future will unknowingly change it to unsigns or to phys_addr_t. It > > >>> is safer to have start explicitly set to 0 in case of wrap. > > >> > > >> memstart_addr is already a s64 for this exact reason. > > > > > > memstart_addr is basically an offset and it must be negative. For > > > example, this would not work if it was not signed: > > > #define vmemmap ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT)) > > > > > > However, on powerpc it is phys_addr_t type. > > > > > >> > > >> Btw, the KASLR check is incorrect: memstart_addr could also be > > >> negative when running the 52-bit VA kernel on hardware that is only > > >> 48-bit VA capable. > > > > > > Good point! > > > > > > if (IS_ENABLED(CONFIG_ARM64_VA_BITS_52) && (vabits_actual != 52)) > > > memstart_addr -= _PAGE_OFFSET(48) - _PAGE_OFFSET(52); > > > > > > So, I will remove IS_ENABLED(CONFIG_RANDOMIZE_BASE) again. > > > > > > I am OK to change start_linear_pa, end_linear_pa to signed, but IMO > > > what I have now is actually safer to make sure that does not break > > > again in the future. > > An explicit check for the flip over and providing two different start > > addresses points would be required in order to use the new framework. > > I don't think so. We no longer randomize over the same range, but take > the support PA range into account. (97d6786e0669d) > > This should ensure that __pa(_PAGE_OFFSET(vabits_actual)) never > assumes a negative value. And to Pavel's point re 48/52 bit VAs: the > fact that vabits_actual appears in this expression means that it > already takes this into account, so you are correct that we don't have > to care about that here. > > So even if memstart_addr could be negative, this expression should > never produce a negative value. And with the patch above applied, it > should never do so when running under KASLR either. > > So question to Pavel and Tyler: could you please check whether you > have that patch, and whether it fixes the issue? It was introduced in > v5.11, and hasn't been backported yet (it wasn't marked for -stable) 97d6786e0669d arm64: mm: account for hotplug memory when randomizing the linear region Does not address the problem that is described in this bug. It only addresses the problem of adding extra PA space to the linear map which is indeed needed (btw is it possible that hot plug is going to add below memblock_start_of_DRAM(), because that is not currently accounted) , but not the fact that a linear map can start from high addresses because of randomization. I have verified that in QEMU, and Tyler verified it on real hardware backporting it to 5.10, the problem that this patch fixes is still there. Pasha _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel