From: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>
To: Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
Cc: Ard Biesheuvel
<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
geoff.levand-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Peter Jones <pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH v3 03/13] arm64: improve CONFIG_STRICT_DEVMEM handling
Date: Tue, 25 Nov 2014 18:48:00 +0100 [thread overview]
Message-ID: <20141125174800.GA3938@pd.tnic> (raw)
In-Reply-To: <20141125173925.GE3331-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
On Tue, Nov 25, 2014 at 05:39:25PM +0000, Matt Fleming wrote:
> On Tue, 18 Nov, at 01:57:02PM, Ard Biesheuvel wrote:
> > Improve the handling of /dev/mem mappings under CONFIG_STRICT_DEVMEM by:
> > - allowing read-only access to parts of System RAM that are not
> > considered memory by the kernel, this is mainly intended for exposing
> > UEFI Configuration tables to userland;
> > - avoid using non-cached mappings for those parts of System RAM, as it
> > may result in mismatched attributes.
>
> Is this really the best way to expose EFI config tables?
>
> We already have parts in /sys/firmware/efi/ and in particular we expose
> the runtime mappings there for kexec on x86.
Yeah!
> Hooking this into the /dev/mem infrastructure just seems wrong to me.
And this virtmap.c thing is arm-only, AFAICT, but it looks like generic
code and like a wholly new way of doing the efi page table.
This thing needs to be properly split into generic pieces which go into
drivers/firmware/efi/ and arm-specific which would make that EFI_VIRTMAP
into an arch bit.
And so on and so on...
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
WARNING: multiple messages have this Message-ID (diff)
From: bp@alien8.de (Borislav Petkov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 03/13] arm64: improve CONFIG_STRICT_DEVMEM handling
Date: Tue, 25 Nov 2014 18:48:00 +0100 [thread overview]
Message-ID: <20141125174800.GA3938@pd.tnic> (raw)
In-Reply-To: <20141125173925.GE3331@console-pimps.org>
On Tue, Nov 25, 2014 at 05:39:25PM +0000, Matt Fleming wrote:
> On Tue, 18 Nov, at 01:57:02PM, Ard Biesheuvel wrote:
> > Improve the handling of /dev/mem mappings under CONFIG_STRICT_DEVMEM by:
> > - allowing read-only access to parts of System RAM that are not
> > considered memory by the kernel, this is mainly intended for exposing
> > UEFI Configuration tables to userland;
> > - avoid using non-cached mappings for those parts of System RAM, as it
> > may result in mismatched attributes.
>
> Is this really the best way to expose EFI config tables?
>
> We already have parts in /sys/firmware/efi/ and in particular we expose
> the runtime mappings there for kexec on x86.
Yeah!
> Hooking this into the /dev/mem infrastructure just seems wrong to me.
And this virtmap.c thing is arm-only, AFAICT, but it looks like generic
code and like a wholly new way of doing the efi page table.
This thing needs to be properly split into generic pieces which go into
drivers/firmware/efi/ and arm-specific which would make that EFI_VIRTMAP
into an arch bit.
And so on and so on...
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Matt Fleming <matt@console-pimps.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
leif.lindholm@linaro.org, roy.franz@linaro.org,
linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
msalter@redhat.com, dyoung@redhat.com, linux-efi@vger.kernel.org,
matt.fleming@intel.com, will.deacon@arm.com,
catalin.marinas@arm.com, grant.likely@linaro.org,
geoff.levand@linaro.org, linux-kernel@vger.kernel.org,
Peter Jones <pjones@redhat.com>
Subject: Re: [PATCH v3 03/13] arm64: improve CONFIG_STRICT_DEVMEM handling
Date: Tue, 25 Nov 2014 18:48:00 +0100 [thread overview]
Message-ID: <20141125174800.GA3938@pd.tnic> (raw)
In-Reply-To: <20141125173925.GE3331@console-pimps.org>
On Tue, Nov 25, 2014 at 05:39:25PM +0000, Matt Fleming wrote:
> On Tue, 18 Nov, at 01:57:02PM, Ard Biesheuvel wrote:
> > Improve the handling of /dev/mem mappings under CONFIG_STRICT_DEVMEM by:
> > - allowing read-only access to parts of System RAM that are not
> > considered memory by the kernel, this is mainly intended for exposing
> > UEFI Configuration tables to userland;
> > - avoid using non-cached mappings for those parts of System RAM, as it
> > may result in mismatched attributes.
>
> Is this really the best way to expose EFI config tables?
>
> We already have parts in /sys/firmware/efi/ and in particular we expose
> the runtime mappings there for kexec on x86.
Yeah!
> Hooking this into the /dev/mem infrastructure just seems wrong to me.
And this virtmap.c thing is arm-only, AFAICT, but it looks like generic
code and like a wholly new way of doing the efi page table.
This thing needs to be properly split into generic pieces which go into
drivers/firmware/efi/ and arm-specific which would make that EFI_VIRTMAP
into an arch bit.
And so on and so on...
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
next prev parent reply other threads:[~2014-11-25 17:48 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-18 12:56 [PATCH v3 00/13] arm64: stable UEFI mappings for kexec Ard Biesheuvel
2014-11-18 12:56 ` Ard Biesheuvel
[not found] ` <1416315432-8534-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-11-18 12:57 ` [PATCH v3 01/13] arm64/mm: add explicit struct_mm argument to __create_mapping() Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
2014-11-18 12:57 ` [PATCH v3 02/13] arm64/mm: add create_pgd_mapping() to create private page tables Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
[not found] ` <1416315432-8534-3-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-11-25 14:32 ` Will Deacon
2014-11-25 14:32 ` Will Deacon
2014-11-18 12:57 ` [PATCH v3 03/13] arm64: improve CONFIG_STRICT_DEVMEM handling Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
[not found] ` <1416315432-8534-4-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-11-25 17:39 ` Matt Fleming
2014-11-25 17:39 ` Matt Fleming
2014-11-25 17:39 ` Matt Fleming
[not found] ` <20141125173925.GE3331-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-11-25 17:48 ` Borislav Petkov [this message]
2014-11-25 17:48 ` Borislav Petkov
2014-11-25 17:48 ` Borislav Petkov
2014-11-26 9:30 ` Dave Young
2014-11-26 9:30 ` Dave Young
[not found] ` <20141126093042.GA6474-4/PLUo9XfK+sDdueE5tM26fLeoKvNuZc@public.gmane.org>
2014-11-26 16:23 ` Ard Biesheuvel
2014-11-26 16:23 ` Ard Biesheuvel
2014-11-27 6:22 ` Dave Young
2014-11-27 6:22 ` Dave Young
2014-11-18 12:57 ` [PATCH v3 04/13] efi: split off remapping code from efi_config_init() Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
[not found] ` <1416315432-8534-5-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-11-25 17:24 ` Matt Fleming
2014-11-25 17:24 ` Matt Fleming
[not found] ` <20141125172419.GD3331-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-11-25 17:48 ` Will Deacon
2014-11-25 17:48 ` Will Deacon
2014-11-18 12:57 ` [PATCH v3 05/13] efi: add common infrastructure for stub-installed virtual mapping Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
2014-11-18 12:57 ` [PATCH v3 06/13] efi: register iomem resources for UEFI reserved regions Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
2014-11-18 12:57 ` [PATCH v3 07/13] arm64/efi: move SetVirtualAddressMap() to UEFI stub Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
2014-11-18 12:57 ` [PATCH v3 08/13] arm64/efi: remove free_boot_services() and friends Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
2014-11-18 12:57 ` [PATCH v3 09/13] arm64/efi: remove idmap manipulations from UEFI code Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
2014-11-18 12:57 ` [PATCH v3 10/13] arm64/efi: use UEFI memory map unconditionally if available Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
2014-11-18 12:57 ` [PATCH v3 11/13] arm64/efi: use plain memblock API for adding and removing reserved RAM Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
[not found] ` <1416315432-8534-12-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-11-20 17:28 ` Mark Salter
2014-11-20 17:28 ` Mark Salter
[not found] ` <1416504536.6398.58.camel-PDpCo7skNiwAicBL8TP8PQ@public.gmane.org>
2014-11-20 17:38 ` Ard Biesheuvel
2014-11-20 17:38 ` Ard Biesheuvel
[not found] ` <CAKv+Gu9XQWrQyPi+8=vhXWkJXtnJ+8=evNC-Z_MkWR8Wuk6Awg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-20 17:54 ` Mark Salter
2014-11-20 17:54 ` Mark Salter
[not found] ` <1416506069.6398.64.camel-PDpCo7skNiwAicBL8TP8PQ@public.gmane.org>
2014-11-21 12:07 ` Ard Biesheuvel
2014-11-21 12:07 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_2kn10dh7LMbhVVYu8+LkMoN_Vxi-tnmCEcBTJ7qs_Jg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-21 15:21 ` Mark Salter
2014-11-21 15:21 ` Mark Salter
[not found] ` <1416583273.6398.71.camel-PDpCo7skNiwAicBL8TP8PQ@public.gmane.org>
2014-11-26 16:59 ` Ard Biesheuvel
2014-11-26 16:59 ` Ard Biesheuvel
2014-11-18 12:57 ` [PATCH v3 12/13] efi: efistub: allow allocation alignment larger than EFI_PAGE_SIZE Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
[not found] ` <1416315432-8534-13-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-11-27 17:30 ` Matt Fleming
2014-11-27 17:30 ` Matt Fleming
2014-11-18 12:57 ` [PATCH v3 13/13] arm64/efi: set EFI_ALLOC_ALIGN to 64 KB Ard Biesheuvel
2014-11-18 12:57 ` Ard Biesheuvel
2014-11-20 1:27 ` [PATCH v3 00/13] arm64: stable UEFI mappings for kexec Geoff Levand
2014-11-20 1:27 ` Geoff Levand
2014-11-20 22:05 ` Geoff Levand
2014-11-20 22:05 ` Geoff Levand
2014-11-22 8:49 ` Ard Biesheuvel
2014-11-22 8:49 ` 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=20141125174800.GA3938@pd.tnic \
--to=bp-gina5biwoiwzqb+pc5nmwq@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=geoff.levand-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=grant.likely-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=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org \
--cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=will.deacon-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.