From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C40C521164883 for ; Tue, 9 Oct 2018 03:49:06 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5383830012DC; Tue, 9 Oct 2018 10:49:06 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-35.rdu2.redhat.com [10.10.120.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id A61135D776; Tue, 9 Oct 2018 10:49:05 +0000 (UTC) To: Hristo Mihaylov , "edk2-devel@lists.01.org" References: <45fadad5-6dce-27c1-6479-f11e8cc5992a@redhat.com> From: Laszlo Ersek Message-ID: Date: Tue, 9 Oct 2018 12:49:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Tue, 09 Oct 2018 10:49:06 +0000 (UTC) Subject: Re: RuntimeDXE unable to save variables to flash X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 10:49:08 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/09/18 12:25, Hristo Mihaylov wrote: > Thanks Laszlo, > >> Accessing invalid MSRs may raise injections. How do you know the MSR 0x1FE is valid (and the Data32 value is valid)? > > I'll investigate this further. > >> That's an Fvb->Write() call. Do you have access to the source of the flash driver (which produces the FVB protocol instance)? > > Yes, I found that the writing is done in a function called SendSpiCmd, here's the signature (I can't disclose the full source). > > ``` > /** > This function sends the programmed SPI command to the slave device. > > @param[in] This Pointer to the PCH_SPI_PROTOCOL instance. > @param[in] SpiRegionType The SPI Region type for flash cycle which is listed in the Descriptor > @param[in] FlashCycleType The Flash SPI cycle type list in HSFC (Hardware Sequencing Flash Control Register) register > @param[in] Address The Flash Linear Address must fall within a region for which BIOS has access permissions. > @param[in] ByteCount Number of bytes in the data portion of the SPI cycle. > @param[in,out] Buffer Pointer to caller-allocated buffer containing the dada received or sent during the SPI cycle. > > @retval EFI_SUCCESS SPI command completes successfully. > @retval EFI_DEVICE_ERROR Device error, the command aborts abnormally. > @retval EFI_ACCESS_DENIED Some unrecognized command encountered in hardware sequencing mode > @retval EFI_INVALID_PARAMETER The parameters specified are not valid. > **/ > EFI_STATUS > SendSpiCmd ( > IN EFI_SPI_PROTOCOL *This, > IN FLASH_REGION_TYPE FlashRegionType, > IN FLASH_CYCLE_TYPE FlashCycleType, > IN UINT32 Address, > IN UINT32 ByteCount, > IN OUT UINT8 *Buffer > ) > ``` > > It fails when it does a sanity check. It checks `if (Address + ByteCount) > FlashRegionSize`. The FlashRegionSize > seems to be estimated correctly, because it's used to write other values to that region, which succeed. > > When I log the sanity check like for the incorrect value I see: `SendSpiCmd: (46334052 + 60 = 46334112) > 20971520` > the address seems to be way off. > > The Address is calculated in FvbGetLbaAddress. Almost a 1 to 1 copy of > https://github.com/tianocore/edk2/blob/75b7aa9528bdd05a7ecf4e64a6beb478d31b402c/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c#L237 > > I thought that the issue is either because of invalid FV block or the size of the flash region is calculated > incorrectly, but this only happens in SMM. Now I'm leaning more towards permissions. > > Any advice? Hmm, not much. Either the blockmap is wrong, as you suggest, or else the Lba input param to FvbGetLbaAddress() is bogus, and FvbGetLbaAddress() returns EFI_INVALID_PARAMETER, when it reaches the terminator blockmap entry (without finding Lba). Does the caller of FvbGetLbaAddress() check the return value? Laszlo