From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 0BC1C3858D1E for ; Tue, 29 Nov 2022 20:12:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0BC1C3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jrtc27.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jrtc27.com Received: by mail-wr1-x433.google.com with SMTP id y16so4131328wrm.2 for ; Tue, 29 Nov 2022 12:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jrtc27.com; s=gmail.jrtc27.user; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jJycOauFyZwNNkHDpmb5bRTzGfzIc/uEFnDgjjtmSqg=; b=JtVTIPkFidXoYMZIYy6ZCTnvIxeoibz9mFkKieaL/7WWATuGTXYIxwCcfV+0o0jRZ9 HJNFwd10qdZwfAeZY5VXAnhTDt/tCns29Z9Scc/tp+628w5nFmLn61mo9B62gWXMxGrM mJzUSf2tZPv9QPsVutHBHK9HFO4/wofE2c4HRIeSZptEnkd23a1eVMXdeOhNtzGTSnnn osZ3S2qwK5TTyHZtZhUm4qyJmS0mKPCOZ9pD3YTwRXUs5fYFKccJJulehpd2kLlufxCu 1TqOKdSEEepjz1xXnZqWvfdDlng6tMja0jC7otUWMar6zciLOSIFG0W5XNKf90GWTBpL /QGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jJycOauFyZwNNkHDpmb5bRTzGfzIc/uEFnDgjjtmSqg=; b=O+UhABFZtCdUuPwGXwDLC3fM9IzMh148En/8Zo2nCWN7k3etbHqFJIV/d6peeScnEG DpTV9jlmC9OLwgxnsUcI6zwXkx5vXa7QhDkT7stfCw4GyZe3VjpOP+kdX17ygotcgt+l PImIzGb5hIe571SOuoZkGOWC5gnMNoWh7xF29vE+oQfRpw0SediWyWYLAMZvIuhGSXGl /hZNuhoI7eOpedYwg/dTJzc8v0TCfQtbfkPPr7jaKggN53zuazf+WdvntqtuHyc5DsP8 cqiSxw+bCPp6qdWHjAvH0yxwLtjLw1AQA055kKzfxc60cX3V4Rjmd6LlpS+e+l1G6ZoH 0LxQ== X-Gm-Message-State: ANoB5plH+3HcZayf179w0R1EvYSMfb9HWjVkz/N0TU+JK7DoQVtjMPTT ac9cGmAyBYcBLAlyWqnp3/0gr0kHZ0cdZA== X-Google-Smtp-Source: AA0mqf7cNyk5FdI45IztkswkGYEhDuNk+i5jNaCKp6pu0tDgKWGVjx2bvRX9V3EtyjFkPlLL5KRvhg== X-Received: by 2002:a5d:6741:0:b0:242:1dbd:2b19 with SMTP id l1-20020a5d6741000000b002421dbd2b19mr5595087wrw.431.1669752746859; Tue, 29 Nov 2022 12:12:26 -0800 (PST) Received: from smtpclient.apple (global-5-141.n-2.net.cam.ac.uk. [131.111.5.141]) by smtp.gmail.com with ESMTPSA id c12-20020adfed8c000000b00236b2804d79sm14469697wro.2.2022.11.29.12.12.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2022 12:12:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [QUERY]: Adding support for a platform From: Jessica Clarke In-Reply-To: Date: Tue, 29 Nov 2022 20:12:25 +0000 Cc: Palmer Dabbelt , binutils@sourceware.org, linux-riscv Content-Transfer-Encoding: quoted-printable Message-Id: <4386F399-2862-4161-B303-8080EBEEA374@jrtc27.com> References: To: "Lad, Prabhakar" X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: On 29 Nov 2022, at 19:28, Lad, Prabhakar = wrote: >=20 > Hi Palmer, >=20 > Oops I should have included linux-riscv to the CC list here (doing it = now) >=20 > On Tue, Nov 29, 2022 at 7:20 PM Palmer Dabbelt = wrote: >>=20 >> On Tue, 29 Nov 2022 11:16:29 PST (-0800), binutils@sourceware.org = wrote: >>> Hi All, >>>=20 >>> If this is not the right place to ask this question please let me = know. >>>=20 >>> 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 = TEXT_START_ADDR)? >>=20 >> 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. >>=20 > Below is the root cause and the solution: >=20 > TEXT_START_ADDR is the start of the text segment of an application. > This is being set to 0x10000 for RISCV platforms. >=20 > So when an application is compiled with the static flag the load would > start from 0x10000 - xyz (depending on size of the application) >=20 > Entry point 0x101c0 > There are 5 program headers, starting at offset 64Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > LOAD 0x0000000000000000 0x0000000000010000 = 0x0000000000010000 > 0x0000000000059b48 0x0000000000059b48 R E 0x1000 > LOAD 0x0000000000059b60 0x000000000006ab60 = 0x000000000006ab60 > 0x0000000000001f68 0x0000000000003528 RW 0x1000 >=20 > So for the above application which is compiled statically we can see > the entry point is 0x101c0 and load 0x0000000000010000. >=20 > 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/Five 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). >=20 > 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. >=20 > Elf file type is EXEC (Executable file) > Entry point 0x504e4 > There are 5 program headers, starting at offset 64 >=20 > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > LOAD 0x0000000000000000 0x0000000000050000 = 0x0000000000050000 > 0x0000000000057dc8 0x0000000000057dc8 R E 0x1000 > LOAD 0x00000000000585b8 0x00000000000a95b8 = 0x00000000000a95b8 > 0x0000000000004ee0 0x00000000000064b0 RW 0x1000 > NOTE 0x0000000000000158 0x0000000000050158 = 0x0000000000050158 > 0x0000000000000044 0x0000000000000044 R 0x4 >=20 > 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. What happens = if a malicious (or buggy) userspace binary goes and accesses unmapped memory in that range? Does it actually get access to this ILM/DLM? If so that=E2=80=99s a gaping side channel. Jess