From: Sai Praneeth Prakhya <sai.praneeth.prakhya-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Lee,
Chun-Yi" <jlee-IBi9RG/b67k@public.gmane.org>,
Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>,
Ricardo Neri
<ricardo.neri-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Ard Biesheuvel
<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Ravi Shankar
<ravi.v.shankar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Fenghua Yu <fenghua.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH V2] x86/efi: Add missing 1:1 mappings to support buggy firmware
Date: Tue, 28 Feb 2017 19:25:34 -0800 [thread overview]
Message-ID: <1488338734.4028.32.camel@intel.com> (raw)
In-Reply-To: <1488332358.4028.15.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >
> > I don't think we should be adding yet another place in the EFI code
> > where we're modifying the page tables.
> >
> > We already have the ability to map EFI_CONVENTIONAL_MEMORY regions
> > inside of efi_map_regions() via the should_map_region() function.
> >
> > Currently, unless you're booting in mixed mode that function will
> > return 'false' if the region type is EFI_CONVENTIONAL_MEMORY, so to
> > get your machine booting you need to do two things,
> >
> > 1) Modify should_map_region() to allow EFI_CONVENTIONAL_MEMORY to be
> > mapped
> >
> > 2) Modify the 64-bit version of efi_map_region() to *only* create
> > 1:1 mapping for EFI_CONVENTIONAL_MEMORY regions.
>
> Thanks for the suggestions! Will try these and will let you know if that
> fixes the issue.
>
I have noticed this issue on two machines HP laptop and a Desktop
(Gigabyte). Adding mappings for EFI_CONVENTIONAL_MEMORY and
*EFI_LOADER_DATA* solves the issue. Presently, I only have access to one
machine (Desktop) and as soon as I test this on laptop (hopefully it
does not access any other EFI regions illegally), I will send version 3
of the patch.
Since this patch will be mapping EFI_CONVENTIONAL_MEMORY and
EFI_LOADER_DATA in 1:1 mode on 64-bit machines, I think we could also do
the same with EFI_BOOT_SERVICES_DATA and EFI_BOOT_SERVICES_CODE. In
other words we could remove the existing mappings for
EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA from VA mapping.
I think; this should not break any machines because firmware could
access illegal addresses only in 1:1 mode and not in VA mode because
that's the only address space firmware has knowledge about. Firmware
doesn't know about virtual addresses until we pass them through
SetVirtualAddressMap().
So Matt, could you please confirm if you had come across any machines
that did illegal access to EFI regions using virtual addresses?
Regards,
Sai
next prev parent reply other threads:[~2017-03-01 3:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-15 4:03 [PATCH V2] x86/efi: Add missing 1:1 mappings to support buggy firmware Sai Praneeth Prakhya
[not found] ` <1487131421-23703-1-git-send-email-sai.praneeth.prakhya-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-02-28 11:51 ` Matt Fleming
[not found] ` <20170228115104.GC28416-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2017-03-01 1:39 ` Sai Praneeth Prakhya
[not found] ` <1488332358.4028.15.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-03-01 3:25 ` Sai Praneeth Prakhya [this message]
[not found] ` <1488338734.4028.32.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-03-16 11:47 ` Matt Fleming
[not found] ` <20170316114722.GD6261-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2017-03-20 18:52 ` Sai Praneeth Prakhya
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=1488338734.4028.32.camel@intel.com \
--to=sai.praneeth.prakhya-ral2jqcrhueavxtiumwx3w@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org \
--cc=fenghua.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=jlee-IBi9RG/b67k@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org \
--cc=ravi.v.shankar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=ricardo.neri-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
/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.