From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 5618C38582B7 for ; Tue, 29 Nov 2022 21:41:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5618C38582B7 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x533.google.com with SMTP id e13so21594287edj.7 for ; Tue, 29 Nov 2022 13:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+1ZOpRUq9IKTjBd+YMI41bw1D4YMKvGEKqmuWoLlIuY=; b=Ma/SbJwfjdc7DuTaZrMz9WtA2d0mQ8sgJpg23zxb6R64MMXNnSUZ/EyLqeqW2wtMi9 GZk+d/BdgMs1ribCdHrAbS+u0mMpfVE3DlipKxX3E4k9620i+b83CJMFnQ6MGW1iCJ5z 9KZyaqTx6ztGgKUBqyUam6T2A8z+kmuz4JI7NjgIoJLRGqj5s8BgQX4hA07tzy0kinwO CBoLoQz1doyKrhD5mLuC16kul2cmUFjnIhs5x8s0+qyCw2IqjGAxviq1Cb81VjH5wFJO xZ3VNZcKJoD4CjihtobWGoqoPDXvE2tWr3Oflgs5lvwXBUPjxBUDZJQzy5Yy4UtAAx+R tUmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+1ZOpRUq9IKTjBd+YMI41bw1D4YMKvGEKqmuWoLlIuY=; b=Ui9lK7ZfPa1OqBGm6gkbcmZacSlC+uyHCkTKbEaTTZ2EOk9O1dwK3bj8NA93S7RA8x L4dJ1uAk3ZLMFFfbwMZtpcFsXKxlH8dwHQBh20wp751FkOG0OOoHXbZHc7pMsC/+chT4 QOfIQtkfwjIt1ClGeLF0lH3TdkJpRfzSssUmRihNviWV7ZVFodh3RRbPjEtX7h4WKnW2 qfZiR6SUUnhiEJz7Xf4/sltbHq68b4jlGXYxEK6xgOrB2usSPhxfzrG8RDAbCU3VP3TX gDeb0fDwv550lTDS7vD1uccuAD1mFaPuWQ2KxzGkzE/RxiIumf25wPaVn5eb+nU+b2zu 1pLQ== X-Gm-Message-State: ANoB5pkQCGFvDX6UwGomIGd7rDsGrUN9mGa+NA3D/0qkAUdAOEHVn6// V12sn7yw7AxCK+n74Dz2MC/D0P/USNPawhfXCSc= X-Google-Smtp-Source: AA0mqf4wKnPJM24VqvjCZZQ3vgKw+3yJfwPmoNUTQov8gflJsz3bLz+QQlQBqbTNA0n3bMVGegkM1mR9fIZHYAur70Q= X-Received: by 2002:a05:6402:2b8b:b0:468:cae8:f5a6 with SMTP id fj11-20020a0564022b8b00b00468cae8f5a6mr54887328edb.263.1669758080034; Tue, 29 Nov 2022 13:41:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Lad, Prabhakar" Date: Tue, 29 Nov 2022 21:40:53 +0000 Message-ID: Subject: Re: [QUERY]: Adding support for a platform To: Palmer Dabbelt Cc: Andrew Waterman , jrtc27@jrtc27.com, binutils@sourceware.org, linux-riscv@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Palmer, On Tue, Nov 29, 2022 at 8:57 PM Palmer Dabbelt wrote: > > On Tue, 29 Nov 2022 12:21:31 PST (-0800), Andrew Waterman wrote: > > On Tue, Nov 29, 2022 at 12:12 PM Jessica Clarke wro= te: > >> > >> On 29 Nov 2022, at 19:28, Lad, Prabhakar = wrote: > >> > > >> > Hi Palmer, > >> > > >> > Oops I should have included linux-riscv to the CC list here (doing i= t now) > >> > > >> > On Tue, Nov 29, 2022 at 7:20 PM Palmer Dabbelt = wrote: > >> >> > >> >> On Tue, 29 Nov 2022 11:16:29 PST (-0800), binutils@sourceware.org w= rote: > >> >>> Hi All, > >> >>> > >> >>> If this is not the right place to ask this question please let me = know. > >> >>> > >> >>> So we have a RISCV platform (Renesas RZ/Five) for which we need to > >> >>> adjust the TEXT_START_ADDR. So below are my queries: > >> >>> * What is the procedure for upstreaming? > >> >>> * Are patches accepted for individual platforms (for adjusting TEX= T_START_ADDR)? > >> >> > >> >> Is this still related to that bug with the static binaries you'd > >> >> mentioned before? I think we'd really need to figure out the root = cause > >> >> before we can make a reasoned decision here, my guess would be that > >> >> changing TEXT_START_ADDR just works around the real bug. > >> >> > >> > Below is the root cause and the solution: > >> > > >> > TEXT_START_ADDR is the start of the text segment of an application. > >> > This is being set to 0x10000 for RISCV platforms. > >> > > >> > So when an application is compiled with the static flag the load wou= ld > >> > start from 0x10000 - xyz (depending on size of the application) > >> > > >> > Entry point 0x101c0 > >> > There are 5 program headers, starting at offset 64Program Headers: > >> > Type Offset VirtAddr PhysAddr > >> > FileSiz MemSiz Flags Align > >> > LOAD 0x0000000000000000 0x0000000000010000 0x000000000001= 0000 > >> > 0x0000000000059b48 0x0000000000059b48 R E 0x1000 > >> > LOAD 0x0000000000059b60 0x000000000006ab60 0x000000000006= ab60 > >> > 0x0000000000001f68 0x0000000000003528 RW 0x1000 > >> > > >> > So for the above application which is compiled statically we can see > >> > the entry point is 0x101c0 and load 0x0000000000010000. > >> > > >> > Andes AX45MP cores have local memory ILM and DLM that are mapped in > >> > the region H=E2=80=990_0003_0000 - H=E2=80=990_0004_FFFF on the RZ/F= ive SoC. When the > >> > virtual address falls in this range the MMU doesn't trigger a page > >> > fault and assumes the virtual address as physical address and hence > >> > the application fails to run (panics somewhere). > >> > > >> > So to avoid this issue we set the TEXT_START_ADDR to 0x50000 so that > >> > the virtual address of any statically compiled application does not > >> > fall in the range of H=E2=80=990_0003_0000 - H=E2=80=990_0004_FFFF. > >> > > >> > Elf file type is EXEC (Executable file) > >> > Entry point 0x504e4 > >> > There are 5 program headers, starting at offset 64 > >> > > >> > Program Headers: > >> > Type Offset VirtAddr PhysAddr > >> > FileSiz MemSiz Flags Align > >> > LOAD 0x0000000000000000 0x0000000000050000 0x000000000005= 0000 > >> > 0x0000000000057dc8 0x0000000000057dc8 R E 0x1000 > >> > LOAD 0x00000000000585b8 0x00000000000a95b8 0x00000000000a= 95b8 > >> > 0x0000000000004ee0 0x00000000000064b0 RW 0x1000 > >> > NOTE 0x0000000000000158 0x0000000000050158 0x000000000005= 0158 > >> > 0x0000000000000044 0x0000000000000044 R 0x4 > >> > > >> > So now with the fix for statically compiled applications we can see > >> > its offsetted and entry point is 0x504e4 and load is at > >> > 0x0000000000050000. So with this we are for sure the MMU will always > >> > trigger a page fault. > >> > >> Well that=E2=80=99s just a blatant violation of the spec. > > > > Right - this isn't a platform quirk; it's a violation of the ISA. > > Unless this behavior is engaged by a custom mode bit, that is, in > > which case, it should just be disabled by default and none of this > > would be a problem. If the behavior is unconditionally enabled, this > > should be treated as an erratum. > > I don't see this as any different than the T-Head page table attributes, > where it was made abundantly clear that vendors self-certify their > implementations and thus anything goes. It doesn't really matter if we > called it an errata, bug, surprise feature, vendor extension, whatever; > it's RISC-V so we've got to live with it. > phew that's a relief. > >> What happens if a > >> malicious (or buggy) userspace binary goes and accesses unmapped memor= y > >> in that range? Does it actually get access to this ILM/DLM? If so > >> that=E2=80=99s a gaping side channel. > > IIUC that's the case, but that's just from reading this post. > > There's nothing we can do to prevent vendors from building hardware with > side channels. In this case I suppose we could swap out the memory > region on context switches, from a quick look at the datasheet these are > single-core so that'd be safe. My guess is it'd be too slow for users > to want that on by default, but I don't have any use case for this HW so > I'm not sure. > Enabling the local memory (ILM/DLM) on the core is a specification option and is enabled on RZ/Five SoC. I'm checking with Andes if this can be forcefully disabled. The only use case would be to speed up things for some slower block (but said that its user application specific) Cheers, Prabhakar