On Thu, 9 Apr 2020 at 11:09, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Thu, 9 Apr 2020 at 10:36, Jiri Slaby <jslaby@xxxxxxx> wrote: > > > > On 09. 04. 20, 10:19, Ard Biesheuvel wrote: > > >>>> $ rpm -qlp ~/Downloads/ovmf-202002-1.1.i586.rpm > > >>>> warning: /home/ardbie01/Downloads/ovmf-202002-1.1.i586.rpm: Header V3 > > >>>> RSA/SHA256 Signature, key ID 3dbdc284: NOKEY > > >>>> /usr/share/doc/packages/ovmf > > >>>> /usr/share/doc/packages/ovmf/README > > >>> > > >>> Hmmm, it's weird that OBS doesn't list all derived files. > > >>> Anyway, the ia32 ovmf is available in > > >>> http://download.opensuse.org/tumbleweed/repo/oss/noarch/qemu-ovmf-ia32-202002-1.1.noarch.rpm > > >> > > >> It indeed does: > > >> https://build.opensuse.org/package/binaries/openSUSE:Factory/ovmf/standard > > >> > > >> Note that the ia32 version is noarch, built on i586. > > >> > > > > > > I am not able to reproduce this issue using the linked firmware image > > > and a 5.6 x86_64_defconfig with efivarfs built in. > > > > Yeah, I had to use the distro config too. Not sure what the trigger is. > > Maybe some NUMA configs or something. > > > > > Could anyone share the full log, please, along with the kernel config > > > that was used? > > > > Both uploaded: > > http://decibel.fi.muni.cz/~xslaby/err/ > > > > With the same config, I am still not seeing the issue. > > > > Note that I switched the for-me-necessary =m configs to =y. So that it > > is enough to build bzImage, w/o modules... > > > > Could you please try running it again with CONFIG_EFI_PGT_DUMP=y enabled? > > In the mean time, I will try to install Tumbleweed from scratch. Do > you have any steps I could follow to reproduce your setup? > The faulting code decodes to 2a:* 89 03 mov %eax,(%ebx) <-- trapping instruction 2c: be 05 00 00 80 mov $0x80000005,%esi 31: a1 74 63 31 3d mov 0x3d316374,%eax 36: 83 c0 48 add $0x48,%eax 39: e8 44 d2 ff ff call 0xffffd282 3e: eb 05 jmp 0x45 which looks suspiciously like MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c-2390- } else { MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c-2391- *DataSize = VarDataSize; MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c:2392: Status = EFI_BUFFER_TOO_SMALL; MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c-2393- goto Done; MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c-2394- } in EDK2, so it seems like the GetVariable() is being called with a datasize pointer that resides in r/o memory It would be very helpful if we could get the memory dump that CONFIG_EFI_PGT_DUMP=y provides, as well as some idea of the call stack that performs get GetVariable() call at this point. The mixed mode code just passes the address it gets, but it does translate it to a physical address, which means it accesses the memory via a different mapping.
