From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by sourceware.org (Postfix) with ESMTPS id C97E0385842A for ; Tue, 29 Nov 2022 20:21:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C97E0385842A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-qk1-x731.google.com with SMTP id p18so10736188qkg.2 for ; Tue, 29 Nov 2022 12:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; 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=DvAzS5kGyrLnX6q1e6NL6cWbiqmxki0GQLIwJ0tBpRg=; b=dVw0ilbD5v9MyHU6G8wsmG4e7bS0H/eR0BTSODqkGlVqnAu5jAG9YkQ4bn5dQC7oSt Rdf/66YxC5yAqmDzQXmx9uKLKE6qLwm+GDcvPWaimTYwmLa2Y8jspaIaKSECPA28petC PoG5NnRnYDKK3AuPuzwce+4iKa61Uf0SF0V/Q3PdtGhscPCpz402GIMxNPMFfK3Tisth k9dAQVypUmOWezsZcQB/OiayAQT4clOvOCttowowVqBPih6q0B5JZj3kcYmKcbRs3O4F Jmakq3/J3MxfS06B1F3OW6d68zgjAiFnklJSm3480PHN67zKuoamTsv24ZADx9a5fW2y 4fXQ== 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=DvAzS5kGyrLnX6q1e6NL6cWbiqmxki0GQLIwJ0tBpRg=; b=CKCjaIAzUJr7K9oszV6NF9TldUcJPl/MkFs9oHBF+H8D6cWsUZd3zu8EsxbvSiyDed 6Fgowis0rpcGJARyAye7rorFeFmbc7JVE+hw9MMFgKCyhlxeGLlrxCTrwUlcrs9KO1so MvhGykk/jBx/0DI1bSu91fjAJxOXMrzICbni+oJVUPKsiBxug2eMYKkHr0Q9UD619Ril ayVVl/KHtcBNZVWc8uun7xfyXYubULkRWHyQ0WyQXl9D/J8GfW0di/QxUTDmdt13ficP T8/quH6OjkMdQ1ezaHUKkTTiKMyU5GkzlR9wWHfgqxNf9Y9pXNrvzz3uaGEB5JQ1H/yU hpmg== X-Gm-Message-State: ANoB5pnLZ1baXbudheti5pj8Z1rDP7sg7Bi05n0et3VtOidy7tZxske7 TDD5nUtTQPOXeahRf2o8WS5MvvCRJGGt2a9IL98iOfR4QPlXcSZ9csYHlotvGVYaB4lsooqhmc0 ltag/+ZehV7BgNKtVaEqvMO3AwYmi2x5m4N9doJX9XGpYGA0yRN7szran0XX53v++2m6+ X-Google-Smtp-Source: AA0mqf54f5ym+Z1Vp56eWx1YdxapzgC3ueBECgwfpCejqJ0ZsOCShXx5aGzj+MF+8gbqJ7KLBHPRiQ== X-Received: by 2002:a05:620a:16b1:b0:6fa:34ba:ec48 with SMTP id s17-20020a05620a16b100b006fa34baec48mr51320241qkj.321.1669753302786; Tue, 29 Nov 2022 12:21:42 -0800 (PST) Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com. [209.85.128.175]) by smtp.gmail.com with ESMTPSA id bs15-20020ac86f0f000000b00398ed306034sm9152114qtb.81.2022.11.29.12.21.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Nov 2022 12:21:42 -0800 (PST) Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-3691e040abaso150618077b3.9 for ; Tue, 29 Nov 2022 12:21:42 -0800 (PST) X-Received: by 2002:a81:5592:0:b0:3ce:b4a4:8804 with SMTP id j140-20020a815592000000b003ceb4a48804mr5914553ywb.85.1669753302053; Tue, 29 Nov 2022 12:21:42 -0800 (PST) MIME-Version: 1.0 References: <4386F399-2862-4161-B303-8080EBEEA374@jrtc27.com> In-Reply-To: <4386F399-2862-4161-B303-8080EBEEA374@jrtc27.com> From: Andrew Waterman Date: Tue, 29 Nov 2022 12:21:31 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [QUERY]: Adding support for a platform To: Jessica Clarke Cc: "Lad, Prabhakar" , Palmer Dabbelt , binutils@sourceware.org, linux-riscv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.0 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 Tue, Nov 29, 2022 at 12:12 PM Jessica Clarke wrote: > > On 29 Nov 2022, at 19:28, Lad, Prabhakar wro= te: > > > > Hi Palmer, > > > > Oops I should have included linux-riscv to the CC list here (doing it n= ow) > > > > On Tue, Nov 29, 2022 at 7:20 PM Palmer Dabbelt wro= te: > >> > >> On Tue, 29 Nov 2022 11:16:29 PST (-0800), binutils@sourceware.org wrot= e: > >>> Hi All, > >>> > >>> If this is not the right place to ask this question please let me kno= w. > >>> > >>> 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_S= TART_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 cau= se > >> 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 would > > 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 0x000000000001000= 0 > > 0x0000000000059b48 0x0000000000059b48 R E 0x1000 > > LOAD 0x0000000000059b60 0x000000000006ab60 0x000000000006ab6= 0 > > 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/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). > > > > 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 0x000000000005000= 0 > > 0x0000000000057dc8 0x0000000000057dc8 R E 0x1000 > > LOAD 0x00000000000585b8 0x00000000000a95b8 0x00000000000a95b= 8 > > 0x0000000000004ee0 0x00000000000064b0 RW 0x1000 > > NOTE 0x0000000000000158 0x0000000000050158 0x000000000005015= 8 > > 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. > 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 >