linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.cz>
To: Gary Lin <glin@suse.com>, Ard Biesheuvel <ardb@kernel.org>
Cc: 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 10:10:25 +0200	[thread overview]
Message-ID: <984a2b3c-a9d4-e733-6372-4abf0f99be1f@suse.cz> (raw)
In-Reply-To: <20200409080626.GV5951@GaryWorkstation>

On 09. 04. 20, 10:06, Gary Lin wrote:
> On Thu, Apr 09, 2020 at 09:51:20AM +0200, Ard Biesheuvel wrote:
>> On Wed, 8 Apr 2020 at 12:51, Jiri Slaby <jslaby@suse.cz> wrote:
>>>
>>> Ccing Gary.
>>>
>>> On 08. 04. 20, 12:47, Ard Biesheuvel wrote:
>>>> On Wed, 8 Apr 2020 at 12:42, Jiri Slaby <jslaby@suse.cz> wrote:
>>>>>
>>>>> On 13. 01. 20, 18:22, Ard Biesheuvel wrote:
>>>>>> The mixed mode thunking routine requires a part of it to be
>>>>>> mapped 1:1, and for this reason, we currently map the entire
>>>>>> kernel .text read/write in the EFI page tables, which is bad.
>>>>>>
>>>>>> In fact, the kernel_map_pages_in_pgd() invocation that installs
>>>>>> this mapping is entirely redundant, since all of DRAM is already
>>>>>> 1:1 mapped read/write in the EFI page tables when we reach this
>>>>>> point, which means that .rodata is mapped read-write as well.
>>>>>>
>>>>>> So let's remap both .text and .rodata read-only in the EFI
>>>>>> page tables.
>>>>>
>>>>> This patch causes unhandled page faults in mixed mode:
>>>>>
>>>>>> BUG: unable to handle page fault for address: 000000001557ee88
>>>>>> #PF: supervisor write access in kernel mode
>>>>>> #PF: error_code(0x0003) - permissions violation
>>>>>> PGD fd52063 P4D fd52063 PUD fd53063 PMD 154000e1
>>>>>> Oops: 0003 [#1] SMP PTI
>>>>>> CPU: 1 PID: 191 Comm: systemd-escape Not tainted
>>>>> 5.6.2-20.gb22bc26-default #1 openSUSE Tumbleweed (unreleased)
>>>>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0
>>>>> 02/06/2015
>>>>>> RIP: 0008:0x3d2eed95
>>>>>> Code: 8b 45 d4 8b 4d 10 8b 40 04 89 01 89 3b 50 6a 00 8b 55 0c 6a 00
>>>>> 8b 45 08 0f b6 4d e4 6a 01 31 f6 e8 ee c5 fc ff 83 c4 10 eb 07 <89> 03
>>>>> be 05 00 00 80 a1 74 63 31 3d 83 c0 48 e8 44 d2 ff ff eb 05
>>>>>> RSP: 0018:000000000fd66fa0 EFLAGS: 00010002
>>>>>> RAX: 0000000000000001 RBX: 000000001557ee88 RCX: 000000003d1f1120
>>>>>> RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000001
>>>>>> RBP: 000000000fd66fd8 R08: 000000001557ee88 R09: 0000000000000000
>>>>>> R10: 0000000000000055 R11: 0000000000000000 R12: 0000000015bcf000
>>>>>> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
>>>>>> FS:  00007f36ee9dc940(0000) GS:ffff9b903d700000(0000)
>>>>> knlGS:0000000000000000
>>>>>> CS:  0008 DS: 0018 ES: 0018 CR0: 0000000080050033
>>>>>> CR2: 000000001557ee88 CR3: 000000000fd5e000 CR4: 00000000000006e0
>>>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>>>>>> Call Trace:
>>>>>> Modules linked in: efivarfs
>>>>>> CR2: 000000001557ee88
>>>>>
>>>>> EFI apparently tries to write to now read-only memory.
>>>>>
>>>>> See:
>>>>> https://bugzilla.suse.com/show_bug.cgi?id=1168645
>>>>>
>>>>> Reverting it on the top of 5.6 fixes the issue.
>>>>>
>>>>> I am using
>>>>> /usr/share/qemu/ovmf-ia32-code.bin
>>>>> /usr/share/qemu/ovmf-ia32-vars.bin
>>>>> from qemu-ovmf-ia32-202002-1.1.noarch rpm.
>>>>>
>>>>
>>>> Do you have a git tree for Suse's OVMF fork? I did a lot of testing
>>>> with upstream OVMF, and never ran into this issue.
>>>
>>> Not really a git tree, but the sources are here:
>>> https://build.opensuse.org/package/show/openSUSE:Factory/ovmf
>>>
>>
>>
>> Anywhere I can get an actual build? The src rpm only has the sources,
>> and the i586 rpm has nothing except
>>
>> $ 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.

thanks,
-- 
js
suse labs

  reply	other threads:[~2020-04-09  8:10 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 [this message]
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
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=984a2b3c-a9d4-e733-6372-4abf0f99be1f@suse.cz \
    --to=jslaby@suse.cz \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=dan.j.williams@intel.com \
    --cc=dyoung@redhat.com \
    --cc=glin@suse.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).