linux-kernel - Re: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXFBoM03po-nmi+BWXOh6RQRNPmpkxnNFe-bf2bsVNW4Cg@mail.gmail.com>
Date:   Thu, 9 Apr 2020 11:45:03 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Jiri Slaby <jslaby@...e.cz>
Cc:     Gary Lin <glin@...e.com>, linux-efi <linux-efi@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Arnd Bergmann <arnd@...db.de>,
        Dan Williams <dan.j.williams@...el.com>,
        Dave Young <dyoung@...hat.com>,
        Saravana Kannan <saravanak@...gle.com>
Subject: Re: [PATCH 05/13] efi/x86: don't map the entire kernel text RW for
 mixed mode

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