From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>,
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>,
Matt Fleming <matt@codeblueprint.co.uk>,
Peter Jones <pjones@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-efi@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
Sasha Levin <sashal>
Subject: [PATCH 4.9 67/91] efi/memattr: Dont bail on zero VA if it equals the regions PA
Date: Thu, 4 Apr 2019 10:47:51 +0200 [thread overview]
Message-ID: <20190404084539.330838278@linuxfoundation.org> (raw)
In-Reply-To: <20190404084535.450029272@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
[ Upstream commit 5de0fef0230f3c8d75cff450a71740a7bf2db866 ]
The EFI memory attributes code cross-references the EFI memory map with
the more granular EFI memory attributes table to ensure that they are in
sync before applying the strict permissions to the regions it describes.
Since we always install virtual mappings for the EFI runtime regions to
which these strict permissions apply, we currently perform a sanity check
on the EFI memory descriptor, and ensure that the EFI_MEMORY_RUNTIME bit
is set, and that the virtual address has been assigned.
However, in cases where a runtime region exists at physical address 0x0,
and the virtual mapping equals the physical mapping, e.g., when running
in mixed mode on x86, we encounter a memory descriptor with the runtime
attribute and virtual address 0x0, and incorrectly draw the conclusion
that a runtime region exists for which no virtual mapping was installed,
and give up altogether. The consequence of this is that firmware mappings
retain their read-write-execute permissions, making the system more
vulnerable to attacks.
So let's only bail if the virtual address of 0x0 has been assigned to a
physical region that does not reside at address 0x0.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Alexander Graf <agraf@suse.de>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Jeffrey Hugo <jhugo@codeaurora.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Fixes: 10f0d2f577053 ("efi: Implement generic support for the Memory ...")
Link: http://lkml.kernel.org/r/20190202094119.13230-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/firmware/efi/memattr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c
index 236004b9a50d..9faa09e7c31f 100644
--- a/drivers/firmware/efi/memattr.c
+++ b/drivers/firmware/efi/memattr.c
@@ -93,7 +93,7 @@ static bool entry_is_valid(const efi_memory_desc_t *in, efi_memory_desc_t *out)
if (!(md->attribute & EFI_MEMORY_RUNTIME))
continue;
- if (md->virt_addr == 0) {
+ if (md->virt_addr == 0 && md->phys_addr != 0) {
/* no virtual mapping has been installed by the stub */
break;
}
--
2.19.1
parent reply other threads:[~2019-04-04 8:47 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20190404084535.450029272@linuxfoundation.org>]
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=20190404084539.330838278@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--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=matt@codeblueprint.co.uk \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=pjones@redhat.com \
--cc=sai.praneeth.prakhya@intel.com \
--cc=stable@vger.kernel.org \
--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 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).