All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	mark.rutland-5wv7dgnIgG8@public.gmane.org
Subject: Re: [PATCH 2/2] arm*: efi: drop writable mapping of the UEFI System table
Date: Fri, 26 Feb 2016 15:01:56 +0000	[thread overview]
Message-ID: <20160226150156.GC7475@codeblueprint.co.uk> (raw)
In-Reply-To: <1456496435-12679-2-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

On Fri, 26 Feb, at 03:20:35PM, Ard Biesheuvel wrote:
> Commit 2eec5dedf770 ("efi/arm-init: Use read-only early mappings")
> updated the early ARM UEFI init code to create the temporary, early
> mapping of the UEFI System table using read-only attributes, as a
> hardening measure against inadvertent modification.
> 
> However, this still leaves the permanent, writable mapping of the UEFI
> System table, which is only ever referenced during invocations of UEFI
> Runtime Services, at which time the UEFI virtual mapping is available,
> which also covers the system table. (This is guaranteed by the fact that
> SetVirtualAddressMap(), which is a runtime service itself, converts
> various entries in the table to their virtual equivalents, which implies
> that the table must be covered by a RuntimeServicesData region that has
> the EFI_MEMORY_RUNTIME attribute.)
> 
> So instead of creating this permanent mapping, record the virtual address
> of the system table inside the UEFI virtual mapping, and dereference that
> when accessing the table. This protects the contents of the system table
> from inadvertent (or deliberate) modification when no UEFI Runtime
> Services calls are in progress.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  drivers/firmware/efi/arm-init.c    |  2 ++
>  drivers/firmware/efi/arm-runtime.c | 27 ++++++++++++++++-----------
>  2 files changed, 18 insertions(+), 11 deletions(-)

Looks like a nice cleanup. Applied.

WARNING: multiple messages have this Message-ID (diff)
From: matt@codeblueprint.co.uk (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm*: efi: drop writable mapping of the UEFI System table
Date: Fri, 26 Feb 2016 15:01:56 +0000	[thread overview]
Message-ID: <20160226150156.GC7475@codeblueprint.co.uk> (raw)
In-Reply-To: <1456496435-12679-2-git-send-email-ard.biesheuvel@linaro.org>

On Fri, 26 Feb, at 03:20:35PM, Ard Biesheuvel wrote:
> Commit 2eec5dedf770 ("efi/arm-init: Use read-only early mappings")
> updated the early ARM UEFI init code to create the temporary, early
> mapping of the UEFI System table using read-only attributes, as a
> hardening measure against inadvertent modification.
> 
> However, this still leaves the permanent, writable mapping of the UEFI
> System table, which is only ever referenced during invocations of UEFI
> Runtime Services, at which time the UEFI virtual mapping is available,
> which also covers the system table. (This is guaranteed by the fact that
> SetVirtualAddressMap(), which is a runtime service itself, converts
> various entries in the table to their virtual equivalents, which implies
> that the table must be covered by a RuntimeServicesData region that has
> the EFI_MEMORY_RUNTIME attribute.)
> 
> So instead of creating this permanent mapping, record the virtual address
> of the system table inside the UEFI virtual mapping, and dereference that
> when accessing the table. This protects the contents of the system table
> from inadvertent (or deliberate) modification when no UEFI Runtime
> Services calls are in progress.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  drivers/firmware/efi/arm-init.c    |  2 ++
>  drivers/firmware/efi/arm-runtime.c | 27 ++++++++++++++++-----------
>  2 files changed, 18 insertions(+), 11 deletions(-)

Looks like a nice cleanup. Applied.

  parent reply	other threads:[~2016-02-26 15:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26 14:20 [PATCH 1/2] efi: get rid of EFI_SYSTEM_TABLES status bit Ard Biesheuvel
2016-02-26 14:20 ` Ard Biesheuvel
     [not found] ` <1456496435-12679-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-02-26 14:20   ` [PATCH 2/2] arm*: efi: drop writable mapping of the UEFI System table Ard Biesheuvel
2016-02-26 14:20     ` Ard Biesheuvel
     [not found]     ` <1456496435-12679-2-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-02-26 15:01       ` Matt Fleming [this message]
2016-02-26 15:01         ` Matt Fleming
     [not found]         ` <20160226150156.GC7475-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-03-22 15:08           ` Ard Biesheuvel
2016-03-22 15:08             ` Ard Biesheuvel
     [not found]             ` <CAKv+Gu8+pYR_jxjcVeXgekVqD_BugtRLgNNhOkvhuaEpddbHRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-23 16:16               ` Matt Fleming
2016-03-23 16:16                 ` Matt Fleming
     [not found]                 ` <20160323161624.GG11676-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-03-23 22:11                   ` Ard Biesheuvel
2016-03-23 22:11                     ` Ard Biesheuvel
2016-02-26 14:43   ` [PATCH 1/2] efi: get rid of EFI_SYSTEM_TABLES status bit Matt Fleming
2016-02-26 14:43     ` Matt Fleming

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=20160226150156.GC7475@codeblueprint.co.uk \
    --to=matt-mf/unelci9gs6ibeejttw/xrex20p6io@public.gmane.org \
    --cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@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.