* [U-Boot] [PATCH 1/2] arm64: booti: update "res1" field to "flags" @ 2017-02-22 2:34 Masahiro Yamada 2017-02-22 2:34 ` [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory Masahiro Yamada 0 siblings, 1 reply; 12+ messages in thread From: Masahiro Yamada @ 2017-02-22 2:34 UTC (permalink / raw) To: u-boot As Documentation/arm64/booting.txt of the latest Linux says, the field "res1" is now "flags". Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> --- cmd/booti.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/booti.c b/cmd/booti.c index bff87a8..f65f0e7 100644 --- a/cmd/booti.c +++ b/cmd/booti.c @@ -20,7 +20,7 @@ struct Image_header { uint32_t code1; /* Executable code */ uint64_t text_offset; /* Image load offset, LE */ uint64_t image_size; /* Effective Image size, LE */ - uint64_t res1; /* reserved */ + uint64_t flags; /* kernel flags, LE */ uint64_t res2; /* reserved */ uint64_t res3; /* reserved */ uint64_t res4; /* reserved */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory 2017-02-22 2:34 [U-Boot] [PATCH 1/2] arm64: booti: update "res1" field to "flags" Masahiro Yamada @ 2017-02-22 2:34 ` Masahiro Yamada 2017-02-22 16:19 ` Tom Rini 0 siblings, 1 reply; 12+ messages in thread From: Masahiro Yamada @ 2017-02-22 2:34 UTC (permalink / raw) To: u-boot At first, the ARM64 Linux booting requirement recommended that the kernel image be placed text_offset bytes from 2MB aligned base near the start of usable system RAM because memory below that base address was unusable at that time. This requirement was relaxed by Linux commit a7f8de168ace ("arm64: allow kernel Image to be loaded anywhere in physical memory"). Since then, the bit 3 of the flags field indicates the tolerance of the kernel physical placement. If this bit is set, the 2MB aligned base may be anywhere in physical memory. For details, see Documentation/arm64/booting.txt of Linux. The booti command should be also relaxed to not expect the kernel image at the start of the system RAM. Even when booting older kernel versions, it still makes sense to have some space below the kernel. For example, some firmware may sit at the start of the system RAM. After all, the most flexible way for booting the kernel is to respect the original images->ep instead of gd->bd->bi_dram[0].start. If image->ep (which is the address given to the booti command) already meets the address requirement, just use it. If not, relocate the kernel to the next 2MB aligned address. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> --- cmd/booti.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/cmd/booti.c b/cmd/booti.c index f65f0e7..9408c34 100644 --- a/cmd/booti.c +++ b/cmd/booti.c @@ -11,6 +11,8 @@ #include <image.h> #include <lmb.h> #include <mapmem.h> +#include <linux/kernel.h> +#include <linux/sizes.h> DECLARE_GLOBAL_DATA_PTR; @@ -54,7 +56,9 @@ static int booti_setup(bootm_headers_t *images) * If we are not at the correct run-time location, set the new * correct location and then move the image there. */ - dst = gd->bd->bi_dram[0].start + le64_to_cpu(ih->text_offset); + dst = images->ep - ih->text_offset; + dst = ALIGN(dst, SZ_2M); + dst += ih->text_offset; unmap_sysmem(ih); -- 1.9.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory 2017-02-22 2:34 ` [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory Masahiro Yamada @ 2017-02-22 16:19 ` Tom Rini 2017-02-23 9:17 ` Masahiro Yamada 0 siblings, 1 reply; 12+ messages in thread From: Tom Rini @ 2017-02-22 16:19 UTC (permalink / raw) To: u-boot On Wed, Feb 22, 2017 at 11:34:26AM +0900, Masahiro Yamada wrote: > At first, the ARM64 Linux booting requirement recommended that the > kernel image be placed text_offset bytes from 2MB aligned base near > the start of usable system RAM because memory below that base address > was unusable at that time. > > This requirement was relaxed by Linux commit a7f8de168ace ("arm64: > allow kernel Image to be loaded anywhere in physical memory"). > Since then, the bit 3 of the flags field indicates the tolerance > of the kernel physical placement. If this bit is set, the 2MB > aligned base may be anywhere in physical memory. For details, see > Documentation/arm64/booting.txt of Linux. > > The booti command should be also relaxed to not expect the kernel > image at the start of the system RAM. Even when booting older > kernel versions, it still makes sense to have some space below the > kernel. For example, some firmware may sit at the start of the > system RAM. > > After all, the most flexible way for booting the kernel is to respect > the original images->ep instead of gd->bd->bi_dram[0].start. If > image->ep (which is the address given to the booti command) already > meets the address requirement, just use it. If not, relocate the > kernel to the next 2MB aligned address. > > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > --- > > cmd/booti.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/cmd/booti.c b/cmd/booti.c > index f65f0e7..9408c34 100644 > --- a/cmd/booti.c > +++ b/cmd/booti.c > @@ -11,6 +11,8 @@ > #include <image.h> > #include <lmb.h> > #include <mapmem.h> > +#include <linux/kernel.h> > +#include <linux/sizes.h> > > DECLARE_GLOBAL_DATA_PTR; > > @@ -54,7 +56,9 @@ static int booti_setup(bootm_headers_t *images) > * If we are not at the correct run-time location, set the new > * correct location and then move the image there. > */ > - dst = gd->bd->bi_dram[0].start + le64_to_cpu(ih->text_offset); > + dst = images->ep - ih->text_offset; > + dst = ALIGN(dst, SZ_2M); > + dst += ih->text_offset; I think the code will be slightly more complex here but I would rather see us check for the presence of the flag which allows for us to relocate things rather than assume that we can always use the address provided, or round it up. The 'contract' wwith the kernel previously said it must be from start of memory and I'd rather not change that. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170222/16ba6164/attachment.sig> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory 2017-02-22 16:19 ` Tom Rini @ 2017-02-23 9:17 ` Masahiro Yamada 2017-02-23 15:31 ` Tom Rini 0 siblings, 1 reply; 12+ messages in thread From: Masahiro Yamada @ 2017-02-23 9:17 UTC (permalink / raw) To: u-boot Hi Tom, 2017-02-23 1:19 GMT+09:00 Tom Rini <trini@konsulko.com>: > On Wed, Feb 22, 2017 at 11:34:26AM +0900, Masahiro Yamada wrote: > >> At first, the ARM64 Linux booting requirement recommended that the >> kernel image be placed text_offset bytes from 2MB aligned base near >> the start of usable system RAM because memory below that base address >> was unusable at that time. >> >> This requirement was relaxed by Linux commit a7f8de168ace ("arm64: >> allow kernel Image to be loaded anywhere in physical memory"). >> Since then, the bit 3 of the flags field indicates the tolerance >> of the kernel physical placement. If this bit is set, the 2MB >> aligned base may be anywhere in physical memory. For details, see >> Documentation/arm64/booting.txt of Linux. >> >> The booti command should be also relaxed to not expect the kernel >> image at the start of the system RAM. Even when booting older >> kernel versions, it still makes sense to have some space below the >> kernel. For example, some firmware may sit at the start of the >> system RAM. >> >> After all, the most flexible way for booting the kernel is to respect >> the original images->ep instead of gd->bd->bi_dram[0].start. If >> image->ep (which is the address given to the booti command) already >> meets the address requirement, just use it. If not, relocate the >> kernel to the next 2MB aligned address. >> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >> --- >> >> cmd/booti.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/cmd/booti.c b/cmd/booti.c >> index f65f0e7..9408c34 100644 >> --- a/cmd/booti.c >> +++ b/cmd/booti.c >> @@ -11,6 +11,8 @@ >> #include <image.h> >> #include <lmb.h> >> #include <mapmem.h> >> +#include <linux/kernel.h> >> +#include <linux/sizes.h> >> >> DECLARE_GLOBAL_DATA_PTR; >> >> @@ -54,7 +56,9 @@ static int booti_setup(bootm_headers_t *images) >> * If we are not at the correct run-time location, set the new >> * correct location and then move the image there. >> */ >> - dst = gd->bd->bi_dram[0].start + le64_to_cpu(ih->text_offset); >> + dst = images->ep - ih->text_offset; >> + dst = ALIGN(dst, SZ_2M); >> + dst += ih->text_offset; > > I think the code will be slightly more complex here but I would rather > see us check for the presence of the flag which allows for us to > relocate things rather than assume that we can always use the address > provided, or round it up. The 'contract' wwith the kernel previously > said it must be from start of memory and I'd rather not change that. At first, I tried this approach. The problem (at least for me) is commit a7f8de168ace is quite new; this is only included in Linux 4.5 and later. Linux 4.4 LTS will be used on Socionext's products for a while. However, I need to avoid the relocation of the kernel image. The gd->bd->bi_dram[0].start points to the start of the DRAM. Here, some firmware is sitting at the start of the DRAM. To hide the head of the memory from Linux, the memory node in the device tree is carved out. If CONFIG_ARCH_FIXUP_FDT_MEMORY is not set, U-Boot passes the memory node as-is to Linux. As a result, the Image is placed out of the available memory region specified by DT, then Linux fails to boot. Somehow I want to achieve, "Even when booting older kernel versions, it still makes sense to have some space below the kernel. For example, some firmware may sit at the start of the system RAM." Perhaps, can we introduce a CONFIG to enable/disable the relocation? Or, any other good idea? -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory 2017-02-23 9:17 ` Masahiro Yamada @ 2017-02-23 15:31 ` Tom Rini 2017-02-26 22:41 ` Tom Rini 0 siblings, 1 reply; 12+ messages in thread From: Tom Rini @ 2017-02-23 15:31 UTC (permalink / raw) To: u-boot On Thu, Feb 23, 2017 at 06:17:38PM +0900, Masahiro Yamada wrote: > Hi Tom, > > > 2017-02-23 1:19 GMT+09:00 Tom Rini <trini@konsulko.com>: > > On Wed, Feb 22, 2017 at 11:34:26AM +0900, Masahiro Yamada wrote: > > > >> At first, the ARM64 Linux booting requirement recommended that the > >> kernel image be placed text_offset bytes from 2MB aligned base near > >> the start of usable system RAM because memory below that base address > >> was unusable at that time. > >> > >> This requirement was relaxed by Linux commit a7f8de168ace ("arm64: > >> allow kernel Image to be loaded anywhere in physical memory"). > >> Since then, the bit 3 of the flags field indicates the tolerance > >> of the kernel physical placement. If this bit is set, the 2MB > >> aligned base may be anywhere in physical memory. For details, see > >> Documentation/arm64/booting.txt of Linux. > >> > >> The booti command should be also relaxed to not expect the kernel > >> image at the start of the system RAM. Even when booting older > >> kernel versions, it still makes sense to have some space below the > >> kernel. For example, some firmware may sit at the start of the > >> system RAM. > >> > >> After all, the most flexible way for booting the kernel is to respect > >> the original images->ep instead of gd->bd->bi_dram[0].start. If > >> image->ep (which is the address given to the booti command) already > >> meets the address requirement, just use it. If not, relocate the > >> kernel to the next 2MB aligned address. > >> > >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > >> --- > >> > >> cmd/booti.c | 6 +++++- > >> 1 file changed, 5 insertions(+), 1 deletion(-) > >> > >> diff --git a/cmd/booti.c b/cmd/booti.c > >> index f65f0e7..9408c34 100644 > >> --- a/cmd/booti.c > >> +++ b/cmd/booti.c > >> @@ -11,6 +11,8 @@ > >> #include <image.h> > >> #include <lmb.h> > >> #include <mapmem.h> > >> +#include <linux/kernel.h> > >> +#include <linux/sizes.h> > >> > >> DECLARE_GLOBAL_DATA_PTR; > >> > >> @@ -54,7 +56,9 @@ static int booti_setup(bootm_headers_t *images) > >> * If we are not at the correct run-time location, set the new > >> * correct location and then move the image there. > >> */ > >> - dst = gd->bd->bi_dram[0].start + le64_to_cpu(ih->text_offset); > >> + dst = images->ep - ih->text_offset; > >> + dst = ALIGN(dst, SZ_2M); > >> + dst += ih->text_offset; > > > > I think the code will be slightly more complex here but I would rather > > see us check for the presence of the flag which allows for us to > > relocate things rather than assume that we can always use the address > > provided, or round it up. The 'contract' wwith the kernel previously > > said it must be from start of memory and I'd rather not change that. > > > At first, I tried this approach. > > The problem (at least for me) is > commit a7f8de168ace is quite new; this is only included in Linux 4.5 and later. > Linux 4.4 LTS will be used on Socionext's products for a while. > However, I need to avoid the relocation of the kernel image. > > The gd->bd->bi_dram[0].start points to the start of the DRAM. > Here, some firmware is sitting at the start of the DRAM. > To hide the head of the memory from Linux, > the memory node in the device tree is carved out. > > If CONFIG_ARCH_FIXUP_FDT_MEMORY is not set, > U-Boot passes the memory node as-is to Linux. > As a result, the Image is placed out of the available memory region > specified by DT, > then Linux fails to boot. > > > Somehow I want to achieve, > "Even when booting older kernel versions, it still makes sense to have > some space below the > kernel. For example, some firmware may sit at the start of the system RAM." > > > Perhaps, can we introduce a CONFIG > to enable/disable the relocation? > Or, any other good idea? I guess the answer is that I need to find some time to re-read the history on Documentation/arm64/booting.txt to see when various restrictions changed / were introduced. I'm also willing to say that perhaps my initial implementation (or the follow up when text_offset was introduced) was incorrectly too strict. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170223/3320194f/attachment.sig> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory 2017-02-23 15:31 ` Tom Rini @ 2017-02-26 22:41 ` Tom Rini 2017-02-28 17:03 ` Masahiro Yamada 0 siblings, 1 reply; 12+ messages in thread From: Tom Rini @ 2017-02-26 22:41 UTC (permalink / raw) To: u-boot On Thu, Feb 23, 2017 at 10:31:17AM -0500, Tom Rini wrote: > On Thu, Feb 23, 2017 at 06:17:38PM +0900, Masahiro Yamada wrote: > > Hi Tom, > > > > > > 2017-02-23 1:19 GMT+09:00 Tom Rini <trini@konsulko.com>: > > > On Wed, Feb 22, 2017 at 11:34:26AM +0900, Masahiro Yamada wrote: > > > > > >> At first, the ARM64 Linux booting requirement recommended that the > > >> kernel image be placed text_offset bytes from 2MB aligned base near > > >> the start of usable system RAM because memory below that base address > > >> was unusable at that time. > > >> > > >> This requirement was relaxed by Linux commit a7f8de168ace ("arm64: > > >> allow kernel Image to be loaded anywhere in physical memory"). > > >> Since then, the bit 3 of the flags field indicates the tolerance > > >> of the kernel physical placement. If this bit is set, the 2MB > > >> aligned base may be anywhere in physical memory. For details, see > > >> Documentation/arm64/booting.txt of Linux. > > >> > > >> The booti command should be also relaxed to not expect the kernel > > >> image at the start of the system RAM. Even when booting older > > >> kernel versions, it still makes sense to have some space below the > > >> kernel. For example, some firmware may sit at the start of the > > >> system RAM. > > >> > > >> After all, the most flexible way for booting the kernel is to respect > > >> the original images->ep instead of gd->bd->bi_dram[0].start. If > > >> image->ep (which is the address given to the booti command) already > > >> meets the address requirement, just use it. If not, relocate the > > >> kernel to the next 2MB aligned address. > > >> > > >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > > >> --- > > >> > > >> cmd/booti.c | 6 +++++- > > >> 1 file changed, 5 insertions(+), 1 deletion(-) > > >> > > >> diff --git a/cmd/booti.c b/cmd/booti.c > > >> index f65f0e7..9408c34 100644 > > >> --- a/cmd/booti.c > > >> +++ b/cmd/booti.c > > >> @@ -11,6 +11,8 @@ > > >> #include <image.h> > > >> #include <lmb.h> > > >> #include <mapmem.h> > > >> +#include <linux/kernel.h> > > >> +#include <linux/sizes.h> > > >> > > >> DECLARE_GLOBAL_DATA_PTR; > > >> > > >> @@ -54,7 +56,9 @@ static int booti_setup(bootm_headers_t *images) > > >> * If we are not at the correct run-time location, set the new > > >> * correct location and then move the image there. > > >> */ > > >> - dst = gd->bd->bi_dram[0].start + le64_to_cpu(ih->text_offset); > > >> + dst = images->ep - ih->text_offset; > > >> + dst = ALIGN(dst, SZ_2M); > > >> + dst += ih->text_offset; > > > > > > I think the code will be slightly more complex here but I would rather > > > see us check for the presence of the flag which allows for us to > > > relocate things rather than assume that we can always use the address > > > provided, or round it up. The 'contract' wwith the kernel previously > > > said it must be from start of memory and I'd rather not change that. > > > > > > At first, I tried this approach. > > > > The problem (at least for me) is > > commit a7f8de168ace is quite new; this is only included in Linux 4.5 and later. > > Linux 4.4 LTS will be used on Socionext's products for a while. > > However, I need to avoid the relocation of the kernel image. > > > > The gd->bd->bi_dram[0].start points to the start of the DRAM. > > Here, some firmware is sitting at the start of the DRAM. > > To hide the head of the memory from Linux, > > the memory node in the device tree is carved out. > > > > If CONFIG_ARCH_FIXUP_FDT_MEMORY is not set, > > U-Boot passes the memory node as-is to Linux. > > As a result, the Image is placed out of the available memory region > > specified by DT, > > then Linux fails to boot. > > > > > > Somehow I want to achieve, > > "Even when booting older kernel versions, it still makes sense to have > > some space below the > > kernel. For example, some firmware may sit at the start of the system RAM." > > > > > > Perhaps, can we introduce a CONFIG > > to enable/disable the relocation? > > Or, any other good idea? > > I guess the answer is that I need to find some time to re-read the > history on Documentation/arm64/booting.txt to see when various > restrictions changed / were introduced. I'm also willing to say that > perhaps my initial implementation (or the follow up when text_offset was > introduced) was incorrectly too strict. So, I re-read what the changes to the document were, before and after. Prior to the change, the kernel will not be able to use any memory below the 2MiB aligned address. After the change, the memory must be excluded using normal mechanisms (and is outside of this problem here). So, conceptually, I'm OK with changing our logic here a bit, what I did at first wrt text_offset was too literal. But: a) We need to re-work the comment in question now to explain a little better what is going on. b) we should continue to use le64_to_cpu() on text_offset (for consistency). c) I'm not convinced your math above is correct. images->ep is where we were put in memory. This is what we should make sure is 2MiB aligned, and then add to it the text_offset. And some quick testing with CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET enabled Images :) -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170226/bed77a7b/attachment.sig> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory 2017-02-26 22:41 ` Tom Rini @ 2017-02-28 17:03 ` Masahiro Yamada 2017-02-28 17:15 ` Tom Rini 0 siblings, 1 reply; 12+ messages in thread From: Masahiro Yamada @ 2017-02-28 17:03 UTC (permalink / raw) To: u-boot Hi Tom, 2017-02-27 7:41 GMT+09:00 Tom Rini <trini@konsulko.com>: > On Thu, Feb 23, 2017 at 10:31:17AM -0500, Tom Rini wrote: >> On Thu, Feb 23, 2017 at 06:17:38PM +0900, Masahiro Yamada wrote: >> > Hi Tom, >> > >> > >> > 2017-02-23 1:19 GMT+09:00 Tom Rini <trini@konsulko.com>: >> > > On Wed, Feb 22, 2017 at 11:34:26AM +0900, Masahiro Yamada wrote: >> > > >> > >> At first, the ARM64 Linux booting requirement recommended that the >> > >> kernel image be placed text_offset bytes from 2MB aligned base near >> > >> the start of usable system RAM because memory below that base address >> > >> was unusable at that time. >> > >> >> > >> This requirement was relaxed by Linux commit a7f8de168ace ("arm64: >> > >> allow kernel Image to be loaded anywhere in physical memory"). >> > >> Since then, the bit 3 of the flags field indicates the tolerance >> > >> of the kernel physical placement. If this bit is set, the 2MB >> > >> aligned base may be anywhere in physical memory. For details, see >> > >> Documentation/arm64/booting.txt of Linux. >> > >> >> > >> The booti command should be also relaxed to not expect the kernel >> > >> image at the start of the system RAM. Even when booting older >> > >> kernel versions, it still makes sense to have some space below the >> > >> kernel. For example, some firmware may sit at the start of the >> > >> system RAM. >> > >> >> > >> After all, the most flexible way for booting the kernel is to respect >> > >> the original images->ep instead of gd->bd->bi_dram[0].start. If >> > >> image->ep (which is the address given to the booti command) already >> > >> meets the address requirement, just use it. If not, relocate the >> > >> kernel to the next 2MB aligned address. >> > >> >> > >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >> > >> --- >> > >> >> > >> cmd/booti.c | 6 +++++- >> > >> 1 file changed, 5 insertions(+), 1 deletion(-) >> > >> >> > >> diff --git a/cmd/booti.c b/cmd/booti.c >> > >> index f65f0e7..9408c34 100644 >> > >> --- a/cmd/booti.c >> > >> +++ b/cmd/booti.c >> > >> @@ -11,6 +11,8 @@ >> > >> #include <image.h> >> > >> #include <lmb.h> >> > >> #include <mapmem.h> >> > >> +#include <linux/kernel.h> >> > >> +#include <linux/sizes.h> >> > >> >> > >> DECLARE_GLOBAL_DATA_PTR; >> > >> >> > >> @@ -54,7 +56,9 @@ static int booti_setup(bootm_headers_t *images) >> > >> * If we are not at the correct run-time location, set the new >> > >> * correct location and then move the image there. >> > >> */ >> > >> - dst = gd->bd->bi_dram[0].start + le64_to_cpu(ih->text_offset); >> > >> + dst = images->ep - ih->text_offset; >> > >> + dst = ALIGN(dst, SZ_2M); >> > >> + dst += ih->text_offset; >> > > >> > > I think the code will be slightly more complex here but I would rather >> > > see us check for the presence of the flag which allows for us to >> > > relocate things rather than assume that we can always use the address >> > > provided, or round it up. The 'contract' wwith the kernel previously >> > > said it must be from start of memory and I'd rather not change that. >> > >> > >> > At first, I tried this approach. >> > >> > The problem (at least for me) is >> > commit a7f8de168ace is quite new; this is only included in Linux 4.5 and later. >> > Linux 4.4 LTS will be used on Socionext's products for a while. >> > However, I need to avoid the relocation of the kernel image. >> > >> > The gd->bd->bi_dram[0].start points to the start of the DRAM. >> > Here, some firmware is sitting at the start of the DRAM. >> > To hide the head of the memory from Linux, >> > the memory node in the device tree is carved out. >> > >> > If CONFIG_ARCH_FIXUP_FDT_MEMORY is not set, >> > U-Boot passes the memory node as-is to Linux. >> > As a result, the Image is placed out of the available memory region >> > specified by DT, >> > then Linux fails to boot. >> > >> > >> > Somehow I want to achieve, >> > "Even when booting older kernel versions, it still makes sense to have >> > some space below the >> > kernel. For example, some firmware may sit at the start of the system RAM." >> > >> > >> > Perhaps, can we introduce a CONFIG >> > to enable/disable the relocation? >> > Or, any other good idea? >> >> I guess the answer is that I need to find some time to re-read the >> history on Documentation/arm64/booting.txt to see when various >> restrictions changed / were introduced. I'm also willing to say that >> perhaps my initial implementation (or the follow up when text_offset was >> introduced) was incorrectly too strict. > > So, I re-read what the changes to the document were, before and after. > Prior to the change, the kernel will not be able to use any memory below > the 2MiB aligned address. After the change, the memory must be excluded > using normal mechanisms (and is outside of this problem here). So, > conceptually, I'm OK with changing our logic here a bit, what I did at > first wrt text_offset was too literal. But: > a) We need to re-work the comment in question now to explain a little > better what is going on. Yes. > b) we should continue to use le64_to_cpu() on text_offset (for > consistency). I had accidentally dropped it. Will fix. > c) I'm not convinced your math above is correct. images->ep is where we > were put in memory. This is what we should make sure is 2MiB aligned, > and then add to it the text_offset. And some quick testing with > CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET enabled Images :) My intention is images->ep = (2MiB aligned base) + text_offset If this equation is met, the image is already placed at the bootable position. We can skip the relocation. Theoretically, we can not know the value of text_offset in advance (especially for CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET). However, in practice, we know text_offset is 0x80000. If we put the image at 2MiB aligned base, the relocation would always happen. -- Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory 2017-02-28 17:03 ` Masahiro Yamada @ 2017-02-28 17:15 ` Tom Rini 2017-03-07 11:43 ` Mark Rutland 0 siblings, 1 reply; 12+ messages in thread From: Tom Rini @ 2017-02-28 17:15 UTC (permalink / raw) To: u-boot On Wed, Mar 01, 2017 at 02:03:58AM +0900, Masahiro Yamada wrote: > Hi Tom, > > 2017-02-27 7:41 GMT+09:00 Tom Rini <trini@konsulko.com>: > > On Thu, Feb 23, 2017 at 10:31:17AM -0500, Tom Rini wrote: > >> On Thu, Feb 23, 2017 at 06:17:38PM +0900, Masahiro Yamada wrote: > >> > Hi Tom, > >> > > >> > > >> > 2017-02-23 1:19 GMT+09:00 Tom Rini <trini@konsulko.com>: > >> > > On Wed, Feb 22, 2017 at 11:34:26AM +0900, Masahiro Yamada wrote: > >> > > > >> > >> At first, the ARM64 Linux booting requirement recommended that the > >> > >> kernel image be placed text_offset bytes from 2MB aligned base near > >> > >> the start of usable system RAM because memory below that base address > >> > >> was unusable at that time. > >> > >> > >> > >> This requirement was relaxed by Linux commit a7f8de168ace ("arm64: > >> > >> allow kernel Image to be loaded anywhere in physical memory"). > >> > >> Since then, the bit 3 of the flags field indicates the tolerance > >> > >> of the kernel physical placement. If this bit is set, the 2MB > >> > >> aligned base may be anywhere in physical memory. For details, see > >> > >> Documentation/arm64/booting.txt of Linux. > >> > >> > >> > >> The booti command should be also relaxed to not expect the kernel > >> > >> image at the start of the system RAM. Even when booting older > >> > >> kernel versions, it still makes sense to have some space below the > >> > >> kernel. For example, some firmware may sit at the start of the > >> > >> system RAM. > >> > >> > >> > >> After all, the most flexible way for booting the kernel is to respect > >> > >> the original images->ep instead of gd->bd->bi_dram[0].start. If > >> > >> image->ep (which is the address given to the booti command) already > >> > >> meets the address requirement, just use it. If not, relocate the > >> > >> kernel to the next 2MB aligned address. > >> > >> > >> > >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > >> > >> --- > >> > >> > >> > >> cmd/booti.c | 6 +++++- > >> > >> 1 file changed, 5 insertions(+), 1 deletion(-) > >> > >> > >> > >> diff --git a/cmd/booti.c b/cmd/booti.c > >> > >> index f65f0e7..9408c34 100644 > >> > >> --- a/cmd/booti.c > >> > >> +++ b/cmd/booti.c > >> > >> @@ -11,6 +11,8 @@ > >> > >> #include <image.h> > >> > >> #include <lmb.h> > >> > >> #include <mapmem.h> > >> > >> +#include <linux/kernel.h> > >> > >> +#include <linux/sizes.h> > >> > >> > >> > >> DECLARE_GLOBAL_DATA_PTR; > >> > >> > >> > >> @@ -54,7 +56,9 @@ static int booti_setup(bootm_headers_t *images) > >> > >> * If we are not at the correct run-time location, set the new > >> > >> * correct location and then move the image there. > >> > >> */ > >> > >> - dst = gd->bd->bi_dram[0].start + le64_to_cpu(ih->text_offset); > >> > >> + dst = images->ep - ih->text_offset; > >> > >> + dst = ALIGN(dst, SZ_2M); > >> > >> + dst += ih->text_offset; > >> > > > >> > > I think the code will be slightly more complex here but I would rather > >> > > see us check for the presence of the flag which allows for us to > >> > > relocate things rather than assume that we can always use the address > >> > > provided, or round it up. The 'contract' wwith the kernel previously > >> > > said it must be from start of memory and I'd rather not change that. > >> > > >> > > >> > At first, I tried this approach. > >> > > >> > The problem (at least for me) is > >> > commit a7f8de168ace is quite new; this is only included in Linux 4.5 and later. > >> > Linux 4.4 LTS will be used on Socionext's products for a while. > >> > However, I need to avoid the relocation of the kernel image. > >> > > >> > The gd->bd->bi_dram[0].start points to the start of the DRAM. > >> > Here, some firmware is sitting at the start of the DRAM. > >> > To hide the head of the memory from Linux, > >> > the memory node in the device tree is carved out. > >> > > >> > If CONFIG_ARCH_FIXUP_FDT_MEMORY is not set, > >> > U-Boot passes the memory node as-is to Linux. > >> > As a result, the Image is placed out of the available memory region > >> > specified by DT, > >> > then Linux fails to boot. > >> > > >> > > >> > Somehow I want to achieve, > >> > "Even when booting older kernel versions, it still makes sense to have > >> > some space below the > >> > kernel. For example, some firmware may sit at the start of the system RAM." > >> > > >> > > >> > Perhaps, can we introduce a CONFIG > >> > to enable/disable the relocation? > >> > Or, any other good idea? > >> > >> I guess the answer is that I need to find some time to re-read the > >> history on Documentation/arm64/booting.txt to see when various > >> restrictions changed / were introduced. I'm also willing to say that > >> perhaps my initial implementation (or the follow up when text_offset was > >> introduced) was incorrectly too strict. > > > > So, I re-read what the changes to the document were, before and after. > > Prior to the change, the kernel will not be able to use any memory below > > the 2MiB aligned address. After the change, the memory must be excluded > > using normal mechanisms (and is outside of this problem here). So, > > conceptually, I'm OK with changing our logic here a bit, what I did at > > first wrt text_offset was too literal. But: > > a) We need to re-work the comment in question now to explain a little > > better what is going on. > > Yes. > > > b) we should continue to use le64_to_cpu() on text_offset (for > > consistency). > > I had accidentally dropped it. > Will fix. > > > c) I'm not convinced your math above is correct. images->ep is where we > > were put in memory. This is what we should make sure is 2MiB aligned, > > and then add to it the text_offset. And some quick testing with > > CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET enabled Images :) > > > My intention is > > images->ep = (2MiB aligned base) + text_offset > > > If this equation is met, the image is already placed at the bootable position. > We can skip the relocation. > > > Theoretically, we can not know the value of text_offset in advance > (especially for CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET). > However, in practice, we know text_offset is 0x80000. > > > If we put the image at 2MiB aligned base, the relocation would always happen. Correct. But I honestly don't know if non-randomized text offset is the common case people will optimize for or randomized for added security will be the more common case. I suppose the important thing is that yes, if loaded at 2MiB aligned + text_offset we should be correct, and that's what counts. If you test it both ways and it's good and behaving correctly, that's what matters. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170228/7dc63223/attachment.sig> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory 2017-02-28 17:15 ` Tom Rini @ 2017-03-07 11:43 ` Mark Rutland 2017-03-07 12:16 ` Tom Rini 0 siblings, 1 reply; 12+ messages in thread From: Mark Rutland @ 2017-03-07 11:43 UTC (permalink / raw) To: u-boot On Tue, Feb 28, 2017 at 12:15:09PM -0500, Tom Rini wrote: > On Wed, Mar 01, 2017 at 02:03:58AM +0900, Masahiro Yamada wrote: > > 2017-02-27 7:41 GMT+09:00 Tom Rini <trini@konsulko.com>: > > > On Thu, Feb 23, 2017 at 10:31:17AM -0500, Tom Rini wrote: > > > c) I'm not convinced your math above is correct. images->ep is where we > > > were put in memory. This is what we should make sure is 2MiB aligned, > > > and then add to it the text_offset. And some quick testing with > > > CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET enabled Images :) > > > > My intention is > > > > images->ep = (2MiB aligned base) + text_offset > > > > If this equation is met, the image is already placed at the bootable position. > > We can skip the relocation. > > > > Theoretically, we can not know the value of text_offset in advance > > (especially for CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET). > > However, in practice, we know text_offset is 0x80000. Per the arm64 Image header, no particular value of text_offset should be assumed. Please do not assume a particular value It has always been the intent that bootloaders should read this, though this evidently wasn't very clear (and the bootwrapper set a bad example). I tried to clear this up with documentation updates (and the addition of ARM64_RANDOMIZE_TEXT_OFFSET). > > If we put the image at 2MiB aligned base, the relocation would > > always happen. > > Correct. But I honestly don't know if non-randomized text offset is the > common case people will optimize for or randomized for added security will be > the more common case. FWIW, the randomized text_offset is a bootloader debugging/testing feature, and there's no security aspect to it. It was added [1] as an additional to hint to bootloader authors that they must respect the text_offset field. Thanks, Mark. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=da57a369d3bc5cd61db90f7e9555840381db9b09 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory 2017-03-07 11:43 ` Mark Rutland @ 2017-03-07 12:16 ` Tom Rini 2017-03-07 13:54 ` Mark Rutland 0 siblings, 1 reply; 12+ messages in thread From: Tom Rini @ 2017-03-07 12:16 UTC (permalink / raw) To: u-boot On Tue, Mar 07, 2017 at 11:43:52AM +0000, Mark Rutland wrote: > On Tue, Feb 28, 2017 at 12:15:09PM -0500, Tom Rini wrote: > > On Wed, Mar 01, 2017 at 02:03:58AM +0900, Masahiro Yamada wrote: > > > 2017-02-27 7:41 GMT+09:00 Tom Rini <trini@konsulko.com>: > > > > On Thu, Feb 23, 2017 at 10:31:17AM -0500, Tom Rini wrote: > > > > > c) I'm not convinced your math above is correct. images->ep is where we > > > > were put in memory. This is what we should make sure is 2MiB aligned, > > > > and then add to it the text_offset. And some quick testing with > > > > CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET enabled Images :) > > > > > > My intention is > > > > > > images->ep = (2MiB aligned base) + text_offset > > > > > > If this equation is met, the image is already placed at the bootable position. > > > We can skip the relocation. > > > > > > Theoretically, we can not know the value of text_offset in advance > > > (especially for CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET). > > > However, in practice, we know text_offset is 0x80000. > > Per the arm64 Image header, no particular value of text_offset should > be assumed. Please do not assume a particular value > > It has always been the intent that bootloaders should read this, though > this evidently wasn't very clear (and the bootwrapper set a bad > example). I tried to clear this up with documentation updates (and the > addition of ARM64_RANDOMIZE_TEXT_OFFSET). > > > > If we put the image at 2MiB aligned base, the relocation would > > > always happen. > > > > Correct. But I honestly don't know if non-randomized text offset is the > > common case people will optimize for or randomized for added security will be > > the more common case. > > FWIW, the randomized text_offset is a bootloader debugging/testing > feature, and there's no security aspect to it. > > It was added [1] as an additional to hint to bootloader authors that > they must respect the text_offset field. Right, and we do this today. But since this doubles as a kind of cheap KASLR I would also expect to see it used, even if not intended, in this way. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170307/a1e1099b/attachment.sig> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory 2017-03-07 12:16 ` Tom Rini @ 2017-03-07 13:54 ` Mark Rutland 2017-03-07 14:12 ` Tom Rini 0 siblings, 1 reply; 12+ messages in thread From: Mark Rutland @ 2017-03-07 13:54 UTC (permalink / raw) To: u-boot On Tue, Mar 07, 2017 at 07:16:56AM -0500, Tom Rini wrote: > On Tue, Mar 07, 2017 at 11:43:52AM +0000, Mark Rutland wrote: > > On Tue, Feb 28, 2017 at 12:15:09PM -0500, Tom Rini wrote: > > > On Wed, Mar 01, 2017 at 02:03:58AM +0900, Masahiro Yamada wrote: > > > > 2017-02-27 7:41 GMT+09:00 Tom Rini <trini@konsulko.com>: > > > > If we put the image at 2MiB aligned base, the relocation would > > > > always happen. > > > > > > Correct. But I honestly don't know if non-randomized text offset is the > > > common case people will optimize for or randomized for added security will be > > > the more common case. > > > > FWIW, the randomized text_offset is a bootloader debugging/testing > > feature, and there's no security aspect to it. > > > > It was added [1] as an additional to hint to bootloader authors that > > they must respect the text_offset field. > > Right, and we do this today. But since this doubles as a kind of cheap > KASLR I would also expect to see it used, even if not intended, in this > way. I can certainly imagine people loading the kernel at a random physical base address (i.e. a random 2M base + text_offset), and doing that's perfectly fine for kernels happy to be loaded at arbitrary bases. That may help to frustrate some DMA attacks. I take it that's what you meant? Given text_offset itself is fixed at compile time, randomizing it provides absolutely no security benefit, and we should be careful not to give the impression that it does. Thanks, Mark. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory 2017-03-07 13:54 ` Mark Rutland @ 2017-03-07 14:12 ` Tom Rini 0 siblings, 0 replies; 12+ messages in thread From: Tom Rini @ 2017-03-07 14:12 UTC (permalink / raw) To: u-boot On Tue, Mar 07, 2017 at 01:54:43PM +0000, Mark Rutland wrote: > On Tue, Mar 07, 2017 at 07:16:56AM -0500, Tom Rini wrote: > > On Tue, Mar 07, 2017 at 11:43:52AM +0000, Mark Rutland wrote: > > > On Tue, Feb 28, 2017 at 12:15:09PM -0500, Tom Rini wrote: > > > > On Wed, Mar 01, 2017 at 02:03:58AM +0900, Masahiro Yamada wrote: > > > > > 2017-02-27 7:41 GMT+09:00 Tom Rini <trini@konsulko.com>: > > > > > If we put the image at 2MiB aligned base, the relocation would > > > > > always happen. > > > > > > > > Correct. But I honestly don't know if non-randomized text offset is the > > > > common case people will optimize for or randomized for added security will be > > > > the more common case. > > > > > > FWIW, the randomized text_offset is a bootloader debugging/testing > > > feature, and there's no security aspect to it. > > > > > > It was added [1] as an additional to hint to bootloader authors that > > > they must respect the text_offset field. > > > > Right, and we do this today. But since this doubles as a kind of cheap > > KASLR I would also expect to see it used, even if not intended, in this > > way. > > I can certainly imagine people loading the kernel at a random physical > base address (i.e. a random 2M base + text_offset), and doing that's > perfectly fine for kernels happy to be loaded at arbitrary bases. That > may help to frustrate some DMA attacks. > > I take it that's what you meant? > > Given text_offset itself is fixed at compile time, randomizing it > provides absolutely no security benefit, and we should be careful not to > give the impression that it does. I was thinking that since it's randomized per compile and the likely number of instances not running some stock kernel, that would further add to frustrating some DMA attacks. But, no, that's not really correct. Thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170307/d43d19c9/attachment.sig> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-03-07 14:12 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-22 2:34 [U-Boot] [PATCH 1/2] arm64: booti: update "res1" field to "flags" Masahiro Yamada 2017-02-22 2:34 ` [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory Masahiro Yamada 2017-02-22 16:19 ` Tom Rini 2017-02-23 9:17 ` Masahiro Yamada 2017-02-23 15:31 ` Tom Rini 2017-02-26 22:41 ` Tom Rini 2017-02-28 17:03 ` Masahiro Yamada 2017-02-28 17:15 ` Tom Rini 2017-03-07 11:43 ` Mark Rutland 2017-03-07 12:16 ` Tom Rini 2017-03-07 13:54 ` Mark Rutland 2017-03-07 14:12 ` Tom Rini
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.