From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.45296.1681927411519239361 for ; Wed, 19 Apr 2023 11:03:31 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=O4ZiMra2; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AFF3763841 for ; Wed, 19 Apr 2023 18:03:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2471BC433A1 for ; Wed, 19 Apr 2023 18:03:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681927410; bh=uG4eAFAKHuyO02Y5FLT3vsWZCqnuw8gqc7br3LnVcyg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=O4ZiMra2yURTRbqXE+VhkgJrclzFQUUEqOEZLb/HZ79ireFDlU6z+hK+wfgdtQ+UB TwcrNzeGYwmurcAs6hc5yu9+HfOhfwTQL9yL7zpe9ytMlSX1ykLVPfmFRVzQdxgCrZ ledlqoT3bt6AGbEXhMrOEAK1XNUI5+ZkgMlilx1/v5gbesstHgWZymccBcPPme5s0U AWObJz5H0aZ/H7/J5LzX1RuNeJ5KJGb3PIm6YhoTWPmYUKs0s3tnb/FNycXXxJbNOY EnPfKhyvjQ55mwKZeIXkjdZj8tRCoZstrpmp1sfHfQ7BNMcCLZleghFIez8PFm9pj6 35em9AsgGhBbw== Received: by mail-lj1-f176.google.com with SMTP id c3so11960661ljf.7 for ; Wed, 19 Apr 2023 11:03:30 -0700 (PDT) X-Gm-Message-State: AAQBX9fQuZUBJ9PUnzOjc7COj7C8c5iNOEzTSbArBNj+IeesFcB5NE6s oHOBNmCfyyzm2bDNxncgffq0pSdeR0g3Rbf81do= X-Google-Smtp-Source: AKy350aYmLOUjBI8LbUwaccHZp00x1h6uXWP7TFGsxLMO2WlNdjedsXU+qewEi7wUoN5PaHThrd8/KKL0AZYhPkOVbU= X-Received: by 2002:a2e:8790:0:b0:2a8:c45f:9fd8 with SMTP id n16-20020a2e8790000000b002a8c45f9fd8mr2515235lji.44.1681927408089; Wed, 19 Apr 2023 11:03:28 -0700 (PDT) MIME-Version: 1.0 References: <46CED01C-BEA6-49F3-9634-051DC63D248C@posteo.de> <696924B3-EF5B-4799-AAD9-E090C97D9AA9@posteo.de> In-Reply-To: <696924B3-EF5B-4799-AAD9-E090C97D9AA9@posteo.de> From: "Ard Biesheuvel" Date: Wed, 19 Apr 2023 20:03:16 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 1/2] ArmPkg/AsmMacroIoLibV8: Introduce ASM_FUNC_ALIGN() To: =?UTF-8?Q?Marvin_H=C3=A4user?= Cc: edk2-devel-groups-io , Leif Lindholm , Ard Biesheuvel , Sami Mujawar , Vitaly Cheptsov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 19 Apr 2023 at 19:45, Marvin H=C3=A4user wrote= : > > > On 19. Apr 2023, at 19:40, Ard Biesheuvel wrote: > > On Wed, 19 Apr 2023 at 19:14, Marvin H=C3=A4user wro= te: > > > Hi all, > > While testing Ard's suggestion for V3, I noticed I got a broken FD where = ArmReplaceLiveTranslationEntry() is misaligned, but does not cross a 4 KB b= oundary. > > > Which platform are you building? > > > ArmVirtPkg / AARCH64 / DEBUG / GCC5 (GCC 12.2.0). > > > To not just hide the issue via this patch, can someone please try to expl= ain the exact requirements this function has (the comments read like 0x200 = was just the lowest value to guarantee staying within a page)? Why would it= be broken if misaligned, but not crossing a page? > > > 0x200 is a log2 upper bound for the size of the function, so it's just > the smallest value that fits that requirement, determined manually > iirc > > And the only reason we have this is that we can cheaply decide whether > or not unmapping a page will unmap this function or not, but we could > actually just use the address and size to decide this. > > In any case, if the FD is constructed in a way that violates the > alignment, there is something wrong with the build tools you are > using. > > > The tools are stock edk2, the only changes made are those in the latest c= ommit of the linked branch. > > > Is there any chance the FD is somehow misaligned in memory, thus shifting= the function across a page in the process? Or is the FD mapped to a fixed = address like with x86? Is code after ArmReplaceLiveTranslationEntry() cross= ing page boundaries the actual issue (and is implicitly fixed by aligning i= t)? > > > If you are building ArmVirtQemu.dsc, the FD is mapped at address 0x0 > and the FV is mapped at 0x1000 > > > Then the function simply is not crossing a page boundary... which means t= he patch did fix a valid bug, but it wasn't what actually caused the corrup= tion. Any help is appreciated. :) > Your branch seems to be missing 16e0969ef775b898ac700f3261d76030b8ab9ef0 "ArmVirtPkg/ArmVirtQemu: Use PEI flavor of ArmMmuLib for all PEIMs"