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=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 D4D36C4338F for ; Sun, 8 Aug 2021 14:55:14 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D703D60560 for ; Sun, 8 Aug 2021 14:55:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D703D60560 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4F1A282BF6; Sun, 8 Aug 2021 16:55:11 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="OORRm9dZ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id AA30482BF7; Sun, 8 Aug 2021 16:55:08 +0200 (CEST) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 2076B82B77 for ; Sun, 8 Aug 2021 16:55:03 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf30.google.com with SMTP id m12so7713987qvt.1 for ; Sun, 08 Aug 2021 07:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=NfjZK41kNQzyTs7H5O6ZZYa4JVpDwEnDylJpHAXgYn0=; b=OORRm9dZsV7R6wgTi3zS508XiYb2v743Fh1i3ZDQMeFs1NgZPMjlKhFIISIfic1zpG AhNhvmLYAwwcCG8ntsnSnA2kmZf8XY6nv2Z/HIywHxUBQ3LoCTEnZdRW2lPPmy9M8khB CMVMEQCqADuMdjEdwoMCqJONuJjI1YoTzYQF0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=NfjZK41kNQzyTs7H5O6ZZYa4JVpDwEnDylJpHAXgYn0=; b=I5bD3nbHiG1b9HW8+fPlixeksfl3L0njFxWLyghV9/Uh6BbrCQKbOdw1p1EfviF1Gx TSPHjm9WAVvU6ng5TcYJ6a8N9I1k4ZP1UjJu6DiLDJ4u8NHaWaZuK83u8fFNz8ThFRJj +P7OX6TX1Y+6Fa4LArafPjxLJZq4oksmuMzjHy30xyCRuSF4Wgxx2zGrTgTgSqnePv2B lM/Tjz0MHxm2XD2FfTNvXB5pkdhoy/YmmWldCH3Sg+nz5opeqRzT+rN1QoXyOYT+oNdx iEQIOLn2uzmtXLueQE7fAmV01hmwXf5m7ITE6Xn9wEJfL+Iz/901NMlIk6ovO48vje4J iVyA== X-Gm-Message-State: AOAM531opTr4M4ENaxVMLOjAaLND5iYwVt0lgDoF26wD2HRNzluMU7nO RNiCygltKLIlzR3vsehb1DzPvg== X-Google-Smtp-Source: ABdhPJxFt28zlf1MggOJ+t8iQPPd4vKfBb3HzKdQQNfZuPioyAAt/2rvxx9NutV+moGkZh/kr0Odrw== X-Received: by 2002:a05:6214:20a2:: with SMTP id 2mr18156944qvd.51.1628434501534; Sun, 08 Aug 2021 07:55:01 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-74d7-5a21-e666-aea2.res6.spectrum.com. [2603:6081:7b01:cbda:74d7:5a21:e666:aea2]) by smtp.gmail.com with ESMTPSA id 37sm157569qtf.33.2021.08.08.07.54.59 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 08 Aug 2021 07:54:59 -0700 (PDT) Date: Sun, 8 Aug 2021 10:54:57 -0400 From: Tom Rini To: Marek Vasut Cc: Jan Kiszka , Wolfgang Denk , U-Boot Mailing List , Hai Pham , Simon Goldschmidt , Stephen Warren , Lokesh Vutla Subject: Re: [PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64" Message-ID: <20210808145457.GI858@bill-the-cat> References: <1971775f-28de-83d0-9459-a4e68c744a18@siemens.com> <20210802212759.GD9379@bill-the-cat> <20210803215144.GW9379@bill-the-cat> <015eed03-b945-8757-e994-17d17de45546@denx.de> <20210806164917.GB858@bill-the-cat> <4aff44db-6a83-bcce-a405-1662187983b2@denx.de> <20210808140010.GH858@bill-the-cat> <03720507-5ea4-0fb9-0549-37df3128be2b@denx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NzlXNccsnmbvA4eK" Content-Disposition: inline In-Reply-To: <03720507-5ea4-0fb9-0549-37df3128be2b@denx.de> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean --NzlXNccsnmbvA4eK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 08, 2021 at 04:28:14PM +0200, Marek Vasut wrote: > On 8/8/21 4:00 PM, Tom Rini wrote: > > On Sun, Aug 08, 2021 at 03:45:30PM +0200, Marek Vasut wrote: > > > On 8/6/21 6:49 PM, Tom Rini wrote: > > > > On Fri, Aug 06, 2021 at 12:22:43AM +0200, Marek Vasut wrote: > > > > > On 8/3/21 11:51 PM, Tom Rini wrote: > > > > > > On Mon, Aug 02, 2021 at 05:27:59PM -0400, Tom Rini wrote: > > > > > > > On Thu, Jul 29, 2021 at 09:22:02AM +0200, Jan Kiszka wrote: > > > > > > >=20 > > > > > > > > From: Jan Kiszka > > > > > > > >=20 > > > > > > > > This reverts commit 2359fa7a87848626bcbd3399e92c657595880cd= 7. > > > > > > > >=20 > > > > > > > > While the goal is valid and there is surely unused memory i= n that area, > > > > > > > > we also have a lot of crucial things still located at the t= op-of-memory > > > > > > > > while running lmb_alloc_base. Such things are the page tabl= e (tlb_addr), > > > > > > > > relocated U-Boot and the active stack. Possibly more. So th= is patch was > > > > > > > > premature, we will need relocations of those things first i= f we want to > > > > > > > > use the range. > > > > > > > >=20 > > > > > > > > Fixes booting on the IOT2050, but likely also on other boar= ds. It got > > > > > > > > stuck on relocating the FDT - over the relocated U-Boot cod= e. > > > > > > > >=20 > > > > > > > > Signed-off-by: Jan Kiszka > > > > > > > > --- > > > > > > > >=20 > > > > > > > > Practically, > > > > > > > >=20 > > > > > > > > void arch_lmb_reserve(struct lmb *lmb) > > > > > > > > { > > > > > > > > lmb_reserve(lmb, gd->relocaddr, gd->ram_top - gd->relocadd= r); > > > > > > > > } > > > > > > > >=20 > > > > > > > > worked as well for me - but it left the stack in danger. > > > > > > >=20 > > > > > > > I want to cycle back up to this practically part. Marek, wou= ld changing > > > > > > > the arch_lmb_reserve (or possibly even making this a more glo= bal thing / > > > > > > > option) still let the area you want exposed on rcar3 (I assum= e) be > > > > > > > exposed ? Or would it be covered again? Part of the problem, > > > > > > > practically speaking, is that we need to ensure that as part = of > > > > > > > (attempting and likely succeeding in) booting the OS we don't= overwrite > > > > > > > ourself and hang. > > > > >=20 > > > > > I think large part of the problem is the purpose of LMB is unclea= r at best. > > > > >=20 > > > > > The arch_lmb_reserve() says this: > > > > >=20 > > > > > 54 void arch_lmb_reserve(struct lmb *lmb) > > > > > [...] > > > > > 59 /* > > > > > 60 * Booting a (Linux) kernel image > > > > > 61 * > > > > > 62 * Allocate space for command line and board info - the > > > > > 63 * address should be as high as possible within the reach of > > > > > 64 * the kernel (see CONFIG_SYS_BOOTMAPSZ settings), but in u= nused > > > > > 65 * memory, which means far enough below the current stack > > > > > 66 * pointer. > > > > > 67 */ > > > > >=20 > > > > > So basically reserve chunk of memory in the right place, which ca= n be safely > > > > > passed to the kernel. > > > >=20 > > > > No. This isn't the case. We reserve chunks of memory away from ot= her > > > > usage by U-Boot. > > >=20 > > > Then I have to wonder, why is this not called in board_init_f or > > > board_init_r , but only after bootm or similar boot command was calle= d ? > >=20 > > I also wonder a little bit. That it does not is why we have the LMB > > checks under fs/ and net/ and doing this sooner would possibly make > > dealing with those CVEs either easier or would also address some other > > classes of them that may exist. >=20 > So, why not move it into the relocation code then ? A further potential clean-up, yes. I don't think that was discussed around CVE-2018-18439 / CVE-2018-18440. > > I expect it was not simply because up > > until rather recently we didn't have any checks for "don't overwrite > > specific areas of memory" other than right before firing off the OS (and > > modify whatever memory you want to modify is a feature not a bug). >=20 > The LMB has been around since forever though ? Yes, LMB has been around since the PowerPC device tree days I suspect (I didn't dig that far back), but only used outside of the "don't overwrite the running U-Boot while we relocate device tree / initrd before booting OS" since 2018 or so. > [...] >=20 > > > > OK, so then there isn't a problem reverting this commit for rcar? > > >=20 > > > The revert will break the use case where the other CPUs are using mem= ory > > > above U-Boot, but have a look at the following branch, it should perm= it me > > > to parametrize the arch_lmb_reserve() better and reserve the right me= mory > > > areas per architecture/mach/board, and even clean the arch_lmb_reserv= e up > > > further: > > > https://source.denx.de/u-boot/custodians/u-boot-sh/-/tree/lmb-v1 > > > So yes, pick the revert and I'll submit the four patches for likely n= ext > > > release. > >=20 > > Thanks for explaining, I'll pick up the revert patch then. > >=20 > > For your LMB tree, I like the initial approach but looking at > > 528915c71762 ("imx: Fix potential lmb memory overwritten by stack") I > > think that shows the general "4K is enough for stack we hope" is wrong, > > and we should do 16K instead for everyone as the default. But we can > > discuss that more too once you post the whole series which again, I > > think is the right direction. >=20 > The IMX thing is odd indeed and raises a bigger question -- what is the > "right" amount of stack to reserve ? It's a good question, yes. And some more details about what exactly the NXP folks were doing to hit that would also be nice. --=20 Tom --NzlXNccsnmbvA4eK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmEP8DcACgkQFHw5/5Y0 tyx0wgv/fMtERotg+iwTsfx6PsivpywQaBxKd6NtI9nYttbkuK7YD3UhRlgSijCA ftczvL3kCJmq5feEkzYWIZnEx5ei5lhaEJ/Fwo2uIYzXgL9PoiKK1dHuomhfq9TC TZBMdhQieTHS+m3SiFz0DrH/kl99iqFnfUG+v1WNtDBNOHIKEPanI/kQD6i0nqeM qN0/Zgs3vCUJgF/A0SNpqc5N9i5dNswBlzBLeiEh1sFlHpwRQLziWPe1LidKSp87 wGMuYRQx1OA4lyxWtLiVUHdvmdYaV8pQBpgeX2M7WcJHU604CAxqkZU/gn6pQC08 SzSH98Hd3TuUlwrbRlxevFpGht0ZehEhc/0l4CteUPYrnUkeOtmuj98X5o8lDJBO s1MjiVuGcqG3jG+94PwhQS8v7j8h7wX66ca+k6acRIJXvFgmtzBtAiuDfELKicj/ eeQbaEz5QeoVK4/SRaXtuqfdbhW6BZDZphDULOHUDgjvb0rP7LqOkdJ3YS1Pvwbe Uzexuen7 =9B+r -----END PGP SIGNATURE----- --NzlXNccsnmbvA4eK--