All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: mark.rutland@arm.com, linux-efi@vger.kernel.org,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Alexander Graf <agraf@suse.de>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	james.morse@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] efi: arm/arm64: allow SetVirtualAddressMap() to be omitted
Date: Wed, 30 Jan 2019 18:19:48 +0000	[thread overview]
Message-ID: <20190130181948.GC18558@fuggles.cambridge.arm.com> (raw)
In-Reply-To: <20190126102207.29488-1-ard.biesheuvel@linaro.org>

Hi Ard,

On Sat, Jan 26, 2019 at 11:22:07AM +0100, Ard Biesheuvel wrote:
> The UEFI spec revision 2.7 errata A section 8.4 has the following to
> say about the virtual memory runtime services:
> 
>   "This section contains function definitions for the virtual memory
>   support that may be optionally used by an operating system at runtime.
>   If an operating system chooses to make EFI runtime service calls in a
>   virtual addressing mode instead of the flat physical mode, then the
>   operating system must use the services in this section to switch the
>   EFI runtime services from flat physical addressing to virtual
>   addressing."

I should probably go RTFM, but what does UEFI say about the attributes of
"flat physical addressing"? The wording above implies to me that it should
act as though the stage-1 MMU is disabled because it's described as an
alternative to virtual addressing.

If we move in a direction where we avoid calling SetVirtualAddressMap() by
default on arm64, isn't there a real threat that this firmware call will no
longer be validated? Do we need to worry about that?

Finally, Bjorn said that SDM850 is unbootable without this change. Why is
that?

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: mark.rutland@arm.com, linux-efi@vger.kernel.org,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Alexander Graf <agraf@suse.de>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	james.morse@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] efi: arm/arm64: allow SetVirtualAddressMap() to be omitted
Date: Wed, 30 Jan 2019 18:19:48 +0000	[thread overview]
Message-ID: <20190130181948.GC18558@fuggles.cambridge.arm.com> (raw)
In-Reply-To: <20190126102207.29488-1-ard.biesheuvel@linaro.org>

Hi Ard,

On Sat, Jan 26, 2019 at 11:22:07AM +0100, Ard Biesheuvel wrote:
> The UEFI spec revision 2.7 errata A section 8.4 has the following to
> say about the virtual memory runtime services:
> 
>   "This section contains function definitions for the virtual memory
>   support that may be optionally used by an operating system at runtime.
>   If an operating system chooses to make EFI runtime service calls in a
>   virtual addressing mode instead of the flat physical mode, then the
>   operating system must use the services in this section to switch the
>   EFI runtime services from flat physical addressing to virtual
>   addressing."

I should probably go RTFM, but what does UEFI say about the attributes of
"flat physical addressing"? The wording above implies to me that it should
act as though the stage-1 MMU is disabled because it's described as an
alternative to virtual addressing.

If we move in a direction where we avoid calling SetVirtualAddressMap() by
default on arm64, isn't there a real threat that this firmware call will no
longer be validated? Do we need to worry about that?

Finally, Bjorn said that SDM850 is unbootable without this change. Why is
that?

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-01-30 18:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-26 10:22 [PATCH] efi: arm/arm64: allow SetVirtualAddressMap() to be omitted Ard Biesheuvel
2019-01-26 10:22 ` Ard Biesheuvel
2019-01-26 12:27 ` Heinrich Schuchardt
2019-01-26 12:27   ` Heinrich Schuchardt
2019-01-26 12:28   ` Ard Biesheuvel
2019-01-26 12:28     ` Ard Biesheuvel
2019-01-26 12:34     ` Alexander Graf
2019-01-26 12:34       ` Alexander Graf
2019-01-26 14:33       ` Heinrich Schuchardt
2019-01-26 14:33         ` Heinrich Schuchardt
2019-01-26 15:03         ` Ard Biesheuvel
2019-01-26 15:03           ` Ard Biesheuvel
2019-01-26 16:49           ` Ard Biesheuvel
2019-01-26 16:49             ` Ard Biesheuvel
2019-01-28 18:04 ` Jeffrey Hugo
2019-01-28 18:04   ` Jeffrey Hugo
2019-01-28 18:24   ` Ard Biesheuvel
2019-01-28 18:24     ` Ard Biesheuvel
2019-01-30  0:06 ` Bjorn Andersson
2019-01-30  0:06   ` Bjorn Andersson
2019-01-30  9:40   ` Ard Biesheuvel
2019-01-30  9:40     ` Ard Biesheuvel
2019-01-30 18:19 ` Will Deacon [this message]
2019-01-30 18:19   ` Will Deacon
2019-01-30 18:29   ` Ard Biesheuvel
2019-01-30 18:29     ` Ard Biesheuvel
2019-02-01  8:06 ` Lee Jones

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=20190130181948.GC18558@fuggles.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=agraf@suse.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=james.morse@arm.com \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=takahiro.akashi@linaro.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.