From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web12.9749.1615387937207312607 for ; Wed, 10 Mar 2021 06:52:17 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YlAwJq+R; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615387936; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S45B94KUR7i0WKA3wWduirzLntlAoIu/RTz905QVaMA=; b=YlAwJq+RCnOBigeUlfhUpBikYYz/7oQTYFJL/+K7xrA2vgjBPFsP2kfQMo+GOaJv5txWLl pQIOac7h7DbcBAnijRjL/b90bjqqTZ+iSDbmwAVtJWmypI6d2RBqAEcGk4/WVnWEzJ7BZs pj/CFBKrMuO8z4KiVpi1HLqYUk/EXBU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-184-O2788erEOOGEb0x-6a3j8Q-1; Wed, 10 Mar 2021 09:52:14 -0500 X-MC-Unique: O2788erEOOGEb0x-6a3j8Q-1 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id B01CB19200C3; Wed, 10 Mar 2021 14:52:13 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-138.ams2.redhat.com [10.36.115.138]) by smtp.corp.redhat.com (Postfix) with ESMTP id 186805D6D7; Wed, 10 Mar 2021 14:52:12 +0000 (UTC) Subject: Re: [edk2-devel] Conflicting virtual addresses causing Runtime Services issues To: devel@edk2.groups.io, jon@solid-run.com References: From: "Laszlo Ersek" Message-ID: <5363bdf0-afac-73bf-d001-77949916f511@redhat.com> Date: Wed, 10 Mar 2021 15:52:12 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 03/10/21 09:04, Jon Nettleton wrote: > I am debugging a failure that I am seeing while using the HoneyComb's > spi-nor flash for runtime variable storage. I am hoping someone on > the list can give me some insight as what may be the problem. > > The problem showed up when we switched the MMIO region for the fspi > flash device to be marked as non executable. reading variables is > fine, however writes began throwing an error. > > [ 556.709828] Unable to handle kernel execute from non-executable > memory at virtual address 00000000206a3968 > > I have patched the kernel and removed the X86 requirement and enabled > the sysfs runtime mappings kernel config so I can get an easy view of > the mappings the kernel carries for runtime services. I then track > that virtual address to the MMIO region of nor flash, which makes > sense that region is marked as non executable. The question is why is > code being executed from this address range > > attribute > :::::::::::::: > 0x8000000000000001 > :::::::::::::: > num_pages > :::::::::::::: > 0x40 > :::::::::::::: > phys_addr > :::::::::::::: > 0x20500000 > :::::::::::::: > type > :::::::::::::: > 0xb > :::::::::::::: > virt_addr > :::::::::::::: > 0x20680000 > > So then I patched the PL011 serial driver to be able to log to the > console in runtime and I track down the access to Status = > Fvb->GetPhysicalAddress(Fvb, &FvVolHdr); in UpdateVariableStore(). > What I don't understand is why EfiConvertPointer is mapping that > pointer into the Virtual address space occupied by the runtime mmio of > the flash. The pointer is being properly remapped. Here are the > pointer addresses in EFI and Kernel Runtime > > EFI: > UpdateVariableStore:156 ECE33968 > FvbGetPhysicalAddress(BaseAddress=0x20000000) > > KERNEL: > UpdateVariableStore:156 206A3968 > [ 556.709828] Unable to handle kernel execute from non-executable > memory at virtual address 00000000206a3968 > > Any insight that anyone could provide would be much appreciated. Your platform appears misconfigured -- the flash MMIO range appears to overlap runtime services code even before SetVirtualAddressMap. The virtual address conflict is likely the result of the original physical address conflict. After the virtual address updates, the EfiMemoryMappedIO (0xb) type range is mapped at virtual address range [0x20680000, 0x206C0000). The GetPhysicalAddress function seems to be located at offset 0x23968 in that range (with 0x1C698 bytes to go in the range). That's inexplicable. What is the physical base address of the flash? What are the PCDs used in "ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvb.c"? Laszlo