All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@intel.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Ingo Molnar <mingo@kernel.org>
Cc: linux-efi <linux-efi@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Alexander Graf <agraf@suse.de>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Borislav Petkov <bp@alien8.de>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Jeffrey Hugo <jhugo@codeaurora.org>,
	Lee Jones <lee.jones@linaro.org>,
	"Leif Lindholm" <leif.lindholm@linaro.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Jones <pjones@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>
Subject: RE: [PATCH 02/10] x86/efi: Return error status if mapping EFI regions fail
Date: Mon, 4 Feb 2019 22:29:34 +0000	[thread overview]
Message-ID: <FFF73D592F13FD46B8700F0A279B802F486FF4C3@ORSMSX114.amr.corp.intel.com> (raw)
In-Reply-To: <CAKv+Gu-vxV_U03jdMY0N1UMDWcB1jZLKj-ONV2rsw3UTeimhBg@mail.gmail.com>

> > > efi_map_region() creates VA mappings for an given EFI region using
> > > any one of the two helper functions (namely __map_region() and
> old_map_region()).
> > > These helper functions *could* fail while creating mappings and
> > > presently their return value is not checked. Not checking for the
> > > return value of these functions might create issues because after
> > > these functions return "md->virt_addr" is set to the requested
> > > virtual address (so it's assumed that these functions always succeed
> > > which is not quite true). This assumption leads to "md->virt_addr"
> > > having invalid mapping should any of
> > > __map_region() or old_map_region() fail.
> > >
> > > Hence, check for the return value of these functions and if indeed
> > > they fail, turn off EFI Runtime Services forever because kernel
> > > cannot prioritize among EFI regions.
> > >
[...................]
> > > -void __init old_map_region(efi_memory_desc_t *md)
> > > +int __init old_map_region(efi_memory_desc_t *md)
> > >  {
> > >       u64 start_pfn, end_pfn, end;
> > >       unsigned long size;
> > > @@ -601,10 +601,14 @@ void __init old_map_region(efi_memory_desc_t
> *md)
> > >               va = efi_ioremap(md->phys_addr, size,
> > >                                md->type, md->attribute);
> > >
> > > -     md->virt_addr = (u64) (unsigned long) va;
> > > -     if (!va)
> > > +     if (!va) {
> > >               pr_err("ioremap of 0x%llX failed!\n",
> > >                      (unsigned long long)md->phys_addr);
> > > +             return -ENOMEM;
> > > +     }
> > > +
> > > +     md->virt_addr = (u64)(unsigned long)va;
> > > +     return 0;
> >
> > Just wondering, shouldn't the failure path set ->virt_addr to
> > something safe, just in case a caller doesn't check the error and relies on it?
> >
> > That's because in this commit we've now changed it from 0 to undefined.
> >
> 
> Indeed. We don't usually rely on the value of ->virt_addr when
> EFI_RUNTIME_SERVICES is unset, but there is some sysfs code, and perhaps
> some other places where we do reference ->virt_addr, and not assigning it at all
> is obviously wrong, and potentially hazardous.
>

Ok.. makes sense.
Do you think md->virt_addr = 0 for fail case is ok?

> > > +int __init efi_map_region_fixed(efi_memory_desc_t *md) { return 0;
> > > +}
> >
> > Inline functions should be marked inline ...
> >
> > >       if (efi_va < EFI_VA_END) {
> > > -             pr_warn(FW_WARN "VA address range overflow!\n");
> > > -             return;
> > > +             pr_err(FW_WARN "VA address range overflow!\n");
> > > +             return -ENOMEM;
> > >       }
> > >
> > >       /* Do the VA map */
> > > -     __map_region(md, efi_va);
> > > +     if (__map_region(md, efi_va))
> > > +             return -ENOMEM;
> > > +
> > >       md->virt_addr = efi_va;
> > > +     return 0;
> >
> > Same error return problem of leaving ->virt_addr undefined.
> >

Sure! Will fix it in V2.

> > Note that I also fixed up the grammar and readability of the changelog
> > - see the updated version below.

Thanks for fixing :)

> >
> > Thanks,
> >
> >         Ingo
> >
> > =============>
> > Subject: x86/efi: Return error status if mapping of EFI regions fails
> > From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Date: Sat, 2 Feb 2019 10:41:11 +0100
> >
> > From: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
> >
> > efi_map_region() creates VA mappings for a given EFI region using one
> > of the two helper functions (namely __map_region() and old_map_region()).
> >
> > These helper functions could fail while creating mappings and
> > presently their return value is not checked.
> >
> > Not checking for the return value of these functions might create
> > bugs, because after these functions return "md->virt_addr" is set to
> > the requested virtual address (so it's assumed that these functions
> > always succeed which is not quite true). This assumption leads to
> > "md->virt_addr" having invalid mapping, should any of __map_region()
> > or old_map_region() fail.
> >
> > Hence, check for the return value of these functions and if indeed
> > they fail, turn off EFI Runtime Services forever because kernel cannot
> > prioritize among EFI regions.
> >
> > This also fixes the comment "FIXME: add error handling" in
> > kexec_enter_virtual_mode().
> >
> 
> Thanks Ingo.
> 
> Sai, could you please respin this and use Ingo's updated version of the commit
> log?

Sure! I will send a V2 with the mentioned changes.

Regards,
Sai

  reply	other threads:[~2019-02-04 22:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-02  9:41 [GIT PULL 00/10] EFI changes for v5.1 Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 01/10] x86/efi: Mark can_free_region() as an __init function Ard Biesheuvel
2019-02-04  7:21   ` [tip:efi/core] " tip-bot for Sai Praneeth Prakhya
2019-02-02  9:41 ` [PATCH 02/10] x86/efi: Return error status if mapping EFI regions fail Ard Biesheuvel
2019-02-04  7:18   ` Ingo Molnar
2019-02-04  7:25     ` Ingo Molnar
2019-02-04  7:28     ` Ard Biesheuvel
2019-02-04 22:29       ` Prakhya, Sai Praneeth [this message]
2019-02-08 15:50         ` Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 03/10] efi: memattr: don't bail on zero VA if it equals the region's PA Ard Biesheuvel
2019-02-04  8:42   ` [tip:efi/core] efi/memattr: Don't " tip-bot for Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 04/10] efi: use 32-bit alignment for efi_guid_t Ard Biesheuvel
2019-02-04  8:43   ` [tip:efi/core] efi: Use " tip-bot for Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 05/10] efi/fdt: More cleanups Ard Biesheuvel
2019-02-04  8:44   ` [tip:efi/core] efi/fdt: Apply more cleanups tip-bot for Ingo Molnar
2019-02-02  9:41 ` [PATCH 06/10] efi: replace GPL license boilerplate with SPDX headers Ard Biesheuvel
2019-02-04  8:44   ` [tip:efi/core] efi: Replace " tip-bot for Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 07/10] efi: arm/arm64: allow SetVirtualAddressMap() to be omitted Ard Biesheuvel
2019-02-04  8:45   ` [tip:efi/core] efi/arm/arm64: Allow " tip-bot for Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 08/10] x86: make ARCH_USE_MEMREMAP_PROT a generic Kconfig symbol Ard Biesheuvel
2019-02-04  8:46   ` [tip:efi/core] x86: Make " tip-bot for Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 09/10] efi: x86: convert x86 EFI earlyprintk into generic earlycon implementation Ard Biesheuvel
2019-02-04  8:46   ` [tip:efi/core] efi/x86: Convert " tip-bot for Ard Biesheuvel
2019-02-02  9:41 ` [PATCH 10/10] acpi: bgrt: parse BGRT to obtain BMP address before it gets clobbered Ard Biesheuvel
2019-02-04  8:47   ` [tip:efi/core] acpi/bgrt: Parse " tip-bot for Ard Biesheuvel
2019-02-05 19:07   ` [PATCH 10/10] acpi: bgrt: parse " Ghannam, Yazen
2019-02-05 23:27     ` Ard Biesheuvel

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=FFF73D592F13FD46B8700F0A279B802F486FF4C3@ORSMSX114.amr.corp.intel.com \
    --to=sai.praneeth.prakhya@intel.com \
    --cc=agraf@suse.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=bp@alien8.de \
    --cc=jhugo@codeaurora.org \
    --cc=lee.jones@linaro.org \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pjones@redhat.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=xypron.glpk@gmx.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.