From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1mn0DR-0006om-Ax for mharc-grub-devel@gnu.org; Tue, 16 Nov 2021 10:17:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mn0DQ-0006kW-74 for grub-devel@gnu.org; Tue, 16 Nov 2021 10:17:44 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:23668) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mn0DA-0002TT-LX for grub-devel@gnu.org; Tue, 16 Nov 2021 10:17:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637075847; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4Q5T7KrViTOcGby9ismsXeb7hnVJ39oEZyOln5EGmoo=; b=FlKRReyZRV3Q/GG2EoWoKZPtf2zOiM98RTj32E6jkcSj+euRqFBpFOoLCF6Vh3ScO6bJlC 1YVGOdGdQdGaRw3/NDawjBMPtE0ljt5x+9wl9tnF6r2msebWTbErUTwjVswt3oZd8ARx0Y J4T/JdElDHh1Wh/7+nC2P8Gb7tG1zxs= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-403-TJ26OEKpMQyyILA8lVPOHg-1; Tue, 16 Nov 2021 10:17:26 -0500 X-MC-Unique: TJ26OEKpMQyyILA8lVPOHg-1 Received: by mail-qk1-f200.google.com with SMTP id bm9-20020a05620a198900b004629c6f44c4so13804793qkb.21 for ; Tue, 16 Nov 2021 07:17:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=4hgx6C7zJFGLXicrcQOtP1WgY8TCQFpziDD44ncUHKo=; b=w+GU3aZCzMxE8j4aWe6V2mGIUj6rNIA6PKUZ8d8xGOubUcv04W4yq+JzrEIYmEes8a v90w8TdbqZWKS2dWnvDqd3ca8DBSLrkaTMI5dAebnzL8UjoqxyidpBqMLshbk7lW8ZCs gbL9CZT9vs0ygCUB5tCNLwTyNkmINUkfw8EQucGwUEJDd4P8JykxNWwnfvJ3z/Bnjd76 mRR5utPFBRPvUsHtV+Oyf1yoRrpXIdBpp+6pr3SA3ampde8CCFe7HmEGaPuY9DW9C+dm rixchA6oIbts2rtLNsY1IdgPaAI6YmT53Gj6z1eyy8xKsFAVk3QiWc2Ezpg2V1l5qwie 5ytQ== X-Gm-Message-State: AOAM531Hxv77aJtiuBYgCwEMKrWo0jJOPBXCIU13Xvi9MLzLxMM8bnb0 9bn/EKOKo/pSpj73eQDLM3o75NnhKpm1A0U84/rGhelPytKDqIqTuIa+9OLny4czb40XDs0m0Vo 675vFae84vQQ= X-Received: by 2002:ac8:7d8a:: with SMTP id c10mr8268775qtd.415.1637075845136; Tue, 16 Nov 2021 07:17:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJyEMDOJDA4UqvOsZNFlSAfu8RdL6/Ohc8xwwzsZBMrYmyfvJ+otv429JXGyWqpr2L6JlGkeLg== X-Received: by 2002:ac8:7d8a:: with SMTP id c10mr8268695qtd.415.1637075844524; Tue, 16 Nov 2021 07:17:24 -0800 (PST) Received: from localhost ([2601:184:4181:74c0:862e:5809:ed9e:e10e]) by smtp.gmail.com with ESMTPSA id m4sm9178423qtu.87.2021.11.16.07.17.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 07:17:23 -0800 (PST) From: Robbie Harwood To: Daniel Axtens , grub-devel@gnu.org Cc: Daniel Axtens Subject: Re: [PATCH 1/2] powerpc-ieee1275: load grub at 8MB, not 2MB In-Reply-To: <20211116034205.463101-2-dja@axtens.net> References: <20211116034205.463101-1-dja@axtens.net> <20211116034205.463101-2-dja@axtens.net> Date: Tue, 16 Nov 2021 10:17:20 -0500 Message-ID: MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=rharwood@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=216.205.24.124; envelope-from=rharwood@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 15:17:44 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Axtens writes: > RHEL9.0 builds were failing to boot with bizzare errors about module > licensing. > > This was first reported under PFW but reproduces under SLOF. > > What is going wrong? > -------------------- > > Much debugging later, it turned out that this was because their image was > greater than 2MB - 16KB in size: > > - The core.elf was 2126152 =3D 0x207148 bytes in size with the following > program headers (per readelf): > > Entry point 0x200000 > There are 4 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x000160 0x00200000 0x00200000 0x21f98 0x2971c RWE 0x8 > GNU_STACK 0x0220f8 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 > LOAD 0x0220f8 0x00232000 0x00232000 0x1e4e50 0x1e4e50 RWE 0x4 > NOTE 0x206f48 0x00000000 0x00000000 0x00200 0x00000 R 0x4 > > - SLOF places the ELF file at 0x4000 (after the reserved space for > interrupt handlers etc.) upwards. The image was 2126152 =3D 0x207148 > bytes in size, so it runs from 0x4000 - 0x20b148. We'll call 0x4000 th= e > load address. > > 0x0 0x4000 0x20b148 > |----------|--------------| > | reserved | ELF contents | > > - SLOF then copies the first LOAD program header (for .text). That runs > for 0x21f98 bytes. It runs from > (load addr + 0x160) to (load addr + 0x160 + 0x21f98) > =3D 0x4160 to 0x260f8 > and we copy it to 0x200000 to 0x221f98. This overwrites the end of the > image: > > 0x0 0x4000 0x200000 0x221f98 > |----------|------------|---------------| > | reserved | ELF cont.. | .text section | > > - SLOF zeros the bss up to PhysAddr + MemSize =3D 0x22971c > > 0x0 0x4000 0x200000 0x221f98 0x22971c > |----------|------------|---------------|--------| > | reserved | ELF cont.. | .text section | bss 0s | > > - SLOF then goes to fulfil the next LOAD header (for mods), which is > for 0x1e4e50 bytes. We copy from > (load addr + 0x220f8) to (load addr + 0x220f8 + 0x1e4e50) > =3D 0x260f8 to 0x20af48 > and we copy it to 0x232000 to 0x416e50: > > 0x0 0x4000 0x200000 0x221f98 0x22971c > |----------|------------|---------------|--------| > | reserved | ELF cont.. | .text section | bss 0s | > |-------------| > | copied area | > 0x260f8 0x20af48 > > This goes poorly: > > 0x0 0x4000 0x200000 0x221f98 0x22971c 0x232000 0x40bf08 = 0x416e50 > |----------|------------|---------------|--------|-----|-----------|----= ---------| > | reserved | ELF cont.. | .text section | bss 0s | pad | some mods | .te= xt start | > > This matches the observations on the running system - 0x40bf08 was where > the contents of memory no longer matched the contents of the ELF file. > > This was reported as a license verification failure on SLOF as the > last module's .module_license section fell past where the corruption > began. > > load-base > --------- > > From LoPAR: > > B.10.1 Load Address > > The client=E2=80=99s load address is specified by the value of the load= -base > Configuration Variable. The value of load-base defines the default > load address for client programs when using the load > method. Load-base shall be a real address in real mode or a virtual > address in virtual mode. Note that this address represents the area, > within the first LMB, into which the client program file will be > read by load; it does not correspond to the addresses at which the > program will be executed. All of physical memory from load-base to > either the start of OF physical memory or the end of physical > memory, whichever comes first, shall be available for loading the > client program. > > Note: The load-base address represents the area into which the > client program will be read by load and does not correspond > to the address at which the program will be executed. > > We can specify load-base via setting a configuration variable, via > CAS, or via an 1275 PowerPC Note. > > We can indeed override load-base and successfully load such a binary > in SLOF. Drop to the OF shell and run: > > 0 > a000000 to load-base-override > 0 > boot > > Sadly, asking people to drop to OF is not a super practical > solution. SLOF ignores the 1275 PowerPC Note, which is the only thing > we can (sanely) set in grub rather than in OF. > > PFW's load-base also defaults to 0x4000 but will honour the note. (The > PFW team has been asking me to get grub to include the note and set > appropriate values. See the next patch.) > > Fixing this > ----------- > > Unless I'm mistaken, if we want backwards compat with SLOF, we will > need to change grub so that we ask the linker instruct the loader to > load the program data somewhere else, giving us more headroom for the > ELF image. > > This is fairly straight-forward to do. I've picked 8MB as that's a > fairly common size for the PReP partition. We could potentially pick > 4MB, I think I've seen some partitions that size too. > > The tests with powerpc32 using the OpenBIOS OF implementation seem to > still work. I have no 32-bit Apple hardware to test on. > > Signed-off-by: Daniel Axtens Shipping this one already. Reviewed-by: Robbie Harwood Be well, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJIBAEBCgAyFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAmGTy4AUHHJoYXJ3b29k QHJlZGhhdC5jb20ACgkQJTL5F2qVpEJBTQ//VI3iUgHuU6MBB6dWTp5OBfuZv5LH REk6iJpRPFmAsBjSqIn2hAHvmlitgGYayOosLReKDeuMY2ZaSwEEzRi3CjiPzcJu 5nPY6IrPXNltIfMtEMWXHsDhI9M0fm9lhG0SWR5EJnDmwfGbB4uZPvk0oXLN81tB PGKAlfFr5CaXDQEIO2sbc/pM4N62DQDPsfeFP4+lqauM++8qRzqTgwQ9tYcvojhq 21pgxWf5fQ5fN7n7X8c4XEtUWkb9Mr8swELXPUzzGUggA4vpwPE3M4iTs325km/7 YVbe42+TtnqD+zIOc0OYJOM4m31aymc77IArkLR6Zc6Zcnx5RNiNzOGBlkFbB6qT mORr6xXIvT9nhNvbtbcpLK2YsE4qKqEKeUOELXNoXVqKAR+WJDR3tURQxH+y7N/i JGEGhd3VqlbhLbtdt1iw9FYFLWbhotEwf8I7WOqgTJxuwm60b+qTp7Ev8NW/sHye yfc1e132UN4Wjz1cOMVvwzsiOkWIXbwWY6p1YBlNaoe/IzURCSirWG3vi3uoOxT1 imc+15BsPO9bTNTC1lc7Wge+OuZ5eqHTLOWiy6HpjJoX0OPD0c0ZPJzWhCwuUUr1 ReUUD/AZ5fjIqMOYWp5Qh9zMZs42xhWLJH0u8pQ03SzGrPklUjHMMa6xcZSmuPEg 31J6g+HbEKuexzY= =BW4G -----END PGP SIGNATURE----- --=-=-=--