From: Sascha Hauer <sha@pengutronix.de>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: barebox@lists.infradead.org, rcz@pengutronix.de
Subject: Re: [PATCH 4/4] of: request reserved memory regions so other code can't
Date: Thu, 9 Jun 2022 10:31:19 +0200 [thread overview]
Message-ID: <20220609083119.GG1615@pengutronix.de> (raw)
In-Reply-To: <20220609054342.661505-5-a.fatoum@pengutronix.de>
On Thu, Jun 09, 2022 at 07:43:42AM +0200, Ahmad Fatoum wrote:
> From: Rouven Czerwinski <r.czerwinski@pengutronix.de>
>
> Add a reserved_mem_read initcall which parses the reserved-memory
> entries and adds barebox of reserve entries. This avoids e.g. bootm
> trying to place the kernel into a reserved region.
>
> Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> Compared with Rouven's v2, rename OF_RESERVE_ENTRY_FLAG_NO_RESERVE
> to NO_FIXUP and read both /reserved-memory and /memreserve
> to request memory regions.
> ---
> common/memory.c | 21 +++++++++++++++++++--
> drivers/of/Makefile | 1 +
> drivers/of/fdt.c | 12 ++++++++----
> include/of.h | 2 ++
> 4 files changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/common/memory.c b/common/memory.c
> index 95995bb6e310..b40c74bfe97f 100644
> --- a/common/memory.c
> +++ b/common/memory.c
> @@ -12,6 +12,7 @@
> #include <asm-generic/memory_layout.h>
> #include <asm/sections.h>
> #include <malloc.h>
> +#include <of.h>
>
> /*
> * Begin and End of memory area for malloc(), and current "brk"
> @@ -53,9 +54,12 @@ void mem_malloc_init(void *start, void *end)
> mem_malloc_initialized = 1;
> }
>
> -#if !defined __SANDBOX__
> static int mem_malloc_resource(void)
> {
> + struct of_reserve_map *map;
> + int i;
> +
> +#if !defined __SANDBOX__
> /*
> * Normally it's a bug when one of these fails,
> * but we have some setups where some of these
> @@ -80,10 +84,23 @@ static int mem_malloc_resource(void)
> #ifdef STACK_BASE
> request_sdram_region("stack", STACK_BASE, STACK_SIZE);
> #endif
> +#endif
> +
> + map = of_get_reserve_map();
> + if (!map)
> + return 0;
> +
> + for (i = 0; i < map->num_entries; i++) {
> + const char *name;
> +
> + name = map->runtime_fw & BIT(i) ? "protected code" : "protected data";
> + request_sdram_region(name, map->start[i],
> + map->end[i] - map->start[i] + 1);
> + }
Regions for entries that are present up to this point are always requested
whereas regions for entries that are added later are never requested.
This only works for you because all regions you are interested in
(OPTEE, ppa) happen to be registered before this point while all others
that you can't do a request_sdram_region() on happen to be added after
this point. That looks quite fragile.
If you want to protect OPTEE resources then call request_sdram_region()
from the code instantiating OPTEE. In case of OPTEE this happens too
early when the resource system is not yet ready, so pick it up in a
later initcall.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2022-06-09 8:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-09 5:43 [PATCH 0/4] " Ahmad Fatoum
2022-06-09 5:43 ` [PATCH 1/4] nvmem: rmem: get, don't request, memory region Ahmad Fatoum
2022-06-09 5:43 ` [PATCH 2/4] of: reserve: mark runtime firmware code regions specially Ahmad Fatoum
2022-06-09 8:05 ` Sascha Hauer
2022-06-09 8:17 ` Ahmad Fatoum
2022-06-09 5:43 ` [PATCH 3/4] of: add of_get_reserve_map stub for !CONFIG_OFTREE Ahmad Fatoum
2022-06-09 9:14 ` Sascha Hauer
2022-06-09 5:43 ` [PATCH 4/4] of: request reserved memory regions so other code can't Ahmad Fatoum
2022-06-09 8:31 ` [PATCH] fixup! " Ahmad Fatoum
2022-06-09 8:31 ` Sascha Hauer [this message]
2022-06-09 8:36 ` [PATCH 4/4] " Ahmad Fatoum
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=20220609083119.GG1615@pengutronix.de \
--to=sha@pengutronix.de \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=rcz@pengutronix.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