All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Jiri Slaby <jslaby@suse.cz>
Cc: Gary Lin <glin@suse.com>, linux-efi <linux-efi@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Young <dyoung@redhat.com>,
	Saravana Kannan <saravanak@google.com>
Subject: Re: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode
Date: Thu, 9 Apr 2020 11:45:03 +0200	[thread overview]
Message-ID: <CAMj1kXFBoM03po-nmi+BWXOh6RQRNPmpkxnNFe-bf2bsVNW4Cg@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXG4F+WzJX8_FyRAxQmDwqvbQMzh3Ji1KcpH_eO3Zt3-WQ@mail.gmail.com>

On Thu, 9 Apr 2020 at 11:09, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 9 Apr 2020 at 10:36, Jiri Slaby <jslaby@suse.cz> 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.

  reply	other threads:[~2020-04-09  9:45 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13 17:22 [GIT PULL 00/13] More EFI updates for v5.6 Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 01/13] efi/libstub/x86: use const attribute for efi_is_64bit() Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 02/13] efi/libstub/x86: use mandatory 16-byte stack alignment in mixed mode Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 03/13] efi/libstub/x86: fix unused-variable warning Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 04/13] x86/mm: fix NX bit clearing issue in kernel_map_pages_in_pgd Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode Ard Biesheuvel
2020-04-08 10:42   ` Jiri Slaby
2020-04-08 10:47     ` Ard Biesheuvel
2020-04-08 10:51       ` Jiri Slaby
2020-04-09  7:51         ` Ard Biesheuvel
2020-04-09  8:06           ` Gary Lin
2020-04-09  8:10             ` Jiri Slaby
2020-04-09  8:19               ` Ard Biesheuvel
2020-04-09  8:34                 ` Jiri Slaby
2020-04-09  9:09                   ` Ard Biesheuvel
2020-04-09  9:45                     ` Ard Biesheuvel [this message]
2020-04-09 10:09                     ` Jiri Slaby
2020-04-09 10:45                       ` Ard Biesheuvel
2020-04-09 11:08                         ` Ard Biesheuvel
2020-04-09 11:25                           ` Ard Biesheuvel
2020-04-09 11:32                             ` Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 06/13] efi/x86: avoid RWX mappings for all of DRAM Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 07/13] efi/x86: limit EFI old memory map to SGI UV machines Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 08/13] efi/arm: defer probe of PCIe backed efifb on DT systems Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 09/13] efi: Fix comment for efi_mem_type() wrt absent physical addresses Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 10/13] efi: Add a flags parameter to efi_memory_map Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 11/13] efi: Add tracking for dynamically allocated memmaps Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 12/13] efi: Fix efi_memmap_alloc() leaks Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 13/13] efi: Fix handling of multiple efi_fake_mem= entries Ard Biesheuvel
2020-01-20  8:25 ` [GIT PULL 00/13] More EFI updates for v5.6 Ingo Molnar
2020-01-20  8:45   ` Ard Biesheuvel
2020-01-22  7:03     ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMj1kXFBoM03po-nmi+BWXOh6RQRNPmpkxnNFe-bf2bsVNW4Cg@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=arnd@arndb.de \
    --cc=dan.j.williams@intel.com \
    --cc=dyoung@redhat.com \
    --cc=glin@suse.com \
    --cc=jslaby@suse.cz \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=saravanak@google.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.