From: Russell King - ARM Linux admin <linux@armlinux.org.uk> To: Lukasz Stelmach <l.stelmach@samsung.com> Cc: Masahiro Yamada <masahiroy@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Thomas Gleixner <tglx@linutronix.de>, Enrico Weigelt <info@metux.net>, Kees Cook <keescook@chromium.org>, Ingo Molnar <mingo@kernel.org>, Ben Dooks <ben-linux@fluff.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, AKASHI Takahiro <takahiro.akashi@linaro.org>, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>, Marek Szyprowski <m.szyprowski@samsung.com> Subject: Re: [PATCH 3/5] arm: decompressor: define a new zImage tag Date: Mon, 1 Jun 2020 19:25:55 +0100 [thread overview] Message-ID: <20200601182555.GP1551@shell.armlinux.org.uk> (raw) In-Reply-To: <dleftjwo4qsqqf.fsf%l.stelmach@samsung.com> On Mon, Jun 01, 2020 at 06:19:52PM +0200, Lukasz Stelmach wrote: > It was <2020-06-01 pon 15:55>, when Russell King - ARM Linux admin wrote: > > On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote: > >> Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool) > >> requirements of the decompressor code. > > > > Why do we need to know the stack and BSS size, when the userspace > > kexec tool doesn't need to know this to perform the same function. > > > kexec-tools load zImage as low in DRAM as possible and rely on two > assumptions: > > + the zImage will copy itself to make enough room for the kernel, > + sizeof(zImage+mem) < sizeof(kernel+mem), which is true because > of compression. > > DRAM start > + 0x8000 > > zImage |-----------|-----|-------| > text+data bss stack > > text+data bss > kernel |---------------------|-------------------| > > > initrd |-initrd-|-dtb-| This is actually incorrect, because the decompressor will self- relocate itself to avoid the area that it is going to decompress into. So, while the decompressor runs, in the above situation it ends up as: ram |------------------------------------------------------... text+data bss kernel |---------------------|-------------------| zImage |-----------|-----|-------| text+data bss stack+malloc Where "text+data" is actually smaller than the image size that was loaded - the part of the image that performs the relocation is discarded (the first chunk of code up to "restart" - 200 bytes.) The BSS is typically smaller than 200 bytes, so we've been able to get away without knowing the actual BSS size so far. ram |--|-----------------------------------------|---------... |<>| TEXT_OFFSET kernel |---------------------|-------------------| |<----edata_size----->|<-----bss_size---->| |<---------------kernel_size------------->| zImage |-----------|-----|-------| |<-------len------->| (initial) |<----------len------------>| (final) The "final" len value is what the decompressor prints as the "zImage requires" debugging value. Hence, the size that the decompressed kernel requires is kernel_size. The size that the decompressor requires is edata_size + len(final). Now, if you intend to load the kernel to ram + TEXT_OFFSET + edata_size then it isn't going to lose the first 200 bytes of code, so as you correctly point out, we need to know the BSS size. > >> +struct arm_zimage_tag_dc { > >> + struct tag_header hdr; > >> + union { > >> +#define ZIMAGE_TAG_DECOMP_SIZE ARM_ZIMAGE_MAGIC4 > >> + struct zimage_decomp_size { > >> + __le32 bss_size; > >> + __le32 stack_size; > >> + __le32 malloc_size; > >> + } decomp_size; You certainly don't need to know all this. All you need to know is how much space the decompressor requires after the end of the image, encompassing the BSS size, stack size and malloc size, which is one value. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> To: Lukasz Stelmach <l.stelmach@samsung.com> Cc: Kees Cook <keescook@chromium.org>, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>, Masahiro Yamada <masahiroy@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, linux-kernel@vger.kernel.org, AKASHI Takahiro <takahiro.akashi@linaro.org>, Ben Dooks <ben-linux@fluff.org>, Thomas Gleixner <tglx@linutronix.de>, Enrico Weigelt <info@metux.net>, Ingo Molnar <mingo@kernel.org>, linux-arm-kernel@lists.infradead.org, Marek Szyprowski <m.szyprowski@samsung.com> Subject: Re: [PATCH 3/5] arm: decompressor: define a new zImage tag Date: Mon, 1 Jun 2020 19:25:55 +0100 [thread overview] Message-ID: <20200601182555.GP1551@shell.armlinux.org.uk> (raw) In-Reply-To: <dleftjwo4qsqqf.fsf%l.stelmach@samsung.com> On Mon, Jun 01, 2020 at 06:19:52PM +0200, Lukasz Stelmach wrote: > It was <2020-06-01 pon 15:55>, when Russell King - ARM Linux admin wrote: > > On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote: > >> Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool) > >> requirements of the decompressor code. > > > > Why do we need to know the stack and BSS size, when the userspace > > kexec tool doesn't need to know this to perform the same function. > > > kexec-tools load zImage as low in DRAM as possible and rely on two > assumptions: > > + the zImage will copy itself to make enough room for the kernel, > + sizeof(zImage+mem) < sizeof(kernel+mem), which is true because > of compression. > > DRAM start > + 0x8000 > > zImage |-----------|-----|-------| > text+data bss stack > > text+data bss > kernel |---------------------|-------------------| > > > initrd |-initrd-|-dtb-| This is actually incorrect, because the decompressor will self- relocate itself to avoid the area that it is going to decompress into. So, while the decompressor runs, in the above situation it ends up as: ram |------------------------------------------------------... text+data bss kernel |---------------------|-------------------| zImage |-----------|-----|-------| text+data bss stack+malloc Where "text+data" is actually smaller than the image size that was loaded - the part of the image that performs the relocation is discarded (the first chunk of code up to "restart" - 200 bytes.) The BSS is typically smaller than 200 bytes, so we've been able to get away without knowing the actual BSS size so far. ram |--|-----------------------------------------|---------... |<>| TEXT_OFFSET kernel |---------------------|-------------------| |<----edata_size----->|<-----bss_size---->| |<---------------kernel_size------------->| zImage |-----------|-----|-------| |<-------len------->| (initial) |<----------len------------>| (final) The "final" len value is what the decompressor prints as the "zImage requires" debugging value. Hence, the size that the decompressed kernel requires is kernel_size. The size that the decompressor requires is edata_size + len(final). Now, if you intend to load the kernel to ram + TEXT_OFFSET + edata_size then it isn't going to lose the first 200 bytes of code, so as you correctly point out, we need to know the BSS size. > >> +struct arm_zimage_tag_dc { > >> + struct tag_header hdr; > >> + union { > >> +#define ZIMAGE_TAG_DECOMP_SIZE ARM_ZIMAGE_MAGIC4 > >> + struct zimage_decomp_size { > >> + __le32 bss_size; > >> + __le32 stack_size; > >> + __le32 malloc_size; > >> + } decomp_size; You certainly don't need to know all this. All you need to know is how much space the decompressor requires after the end of the image, encompassing the BSS size, stack size and malloc size, which is one value. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-06-01 18:38 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CGME20200601142806eucas1p2680c5625411e7a695d8469760a926520@eucas1p2.samsung.com> 2020-06-01 14:27 ` [PATCH 0/5] kexec_file_load() for arm Łukasz Stelmach 2020-06-01 14:27 ` Łukasz Stelmach [not found] ` <CGME20200601142810eucas1p1767585cf172d26aedb551d7453aa7402@eucas1p1.samsung.com> 2020-06-01 14:27 ` [PATCH 1/5] arm: decompressor: set malloc pool size for the decompressor Łukasz Stelmach 2020-06-01 14:27 ` Łukasz Stelmach 2020-06-01 14:46 ` Russell King - ARM Linux admin 2020-06-01 14:46 ` Russell King - ARM Linux admin [not found] ` <CGME20200601145652eucas1p11dcea1cea21824d0a6bfe6ab38c1cab7@eucas1p1.samsung.com> 2020-06-01 14:56 ` Lukasz Stelmach 2020-06-01 14:56 ` Lukasz Stelmach 2020-06-01 15:10 ` Russell King - ARM Linux admin 2020-06-01 15:10 ` Russell King - ARM Linux admin [not found] ` <CGME20200601165420eucas1p273e0cdb143312b9a621e2444c5daae9b@eucas1p2.samsung.com> 2020-06-01 16:54 ` Lukasz Stelmach 2020-06-01 16:54 ` Lukasz Stelmach [not found] ` <CGME20200601142810eucas1p23056f7997a880ff7d676c64703f87115@eucas1p2.samsung.com> 2020-06-01 14:27 ` [PATCH 2/5] arm: add image header definitions Łukasz Stelmach 2020-06-01 14:27 ` Łukasz Stelmach [not found] ` <CGME20200601142810eucas1p1c42ff7c9b417f04bc506261726f08b4f@eucas1p1.samsung.com> 2020-06-01 14:27 ` [PATCH 3/5] arm: decompressor: define a new zImage tag Łukasz Stelmach 2020-06-01 14:27 ` Łukasz Stelmach 2020-06-01 14:55 ` Russell King - ARM Linux admin 2020-06-01 14:55 ` Russell King - ARM Linux admin [not found] ` <CGME20200601162002eucas1p28eb08a42de6f313458e9391bd5976e90@eucas1p2.samsung.com> 2020-06-01 16:19 ` Lukasz Stelmach 2020-06-01 16:19 ` Lukasz Stelmach 2020-06-01 18:25 ` Russell King - ARM Linux admin [this message] 2020-06-01 18:25 ` Russell King - ARM Linux admin [not found] ` <CGME20200601202757eucas1p11d380be9e0b2fe912a358d21e2d8dc2a@eucas1p1.samsung.com> 2020-06-01 20:27 ` Lukasz Stelmach 2020-06-01 20:27 ` Lukasz Stelmach 2020-06-01 20:41 ` Russell King - ARM Linux admin 2020-06-01 20:41 ` Russell King - ARM Linux admin [not found] ` <CGME20200602161720eucas1p257e9e892ed4679ed1d168db34d089a82@eucas1p2.samsung.com> 2020-06-02 16:17 ` Lukasz Stelmach 2020-06-02 16:17 ` Lukasz Stelmach [not found] ` <CGME20200601142811eucas1p260e5a434ea7743eecdb37c4d975c5f05@eucas1p2.samsung.com> 2020-06-01 14:27 ` [PATCH 4/5] arm: Add kexec_image_info Łukasz Stelmach 2020-06-01 14:27 ` Łukasz Stelmach 2020-06-01 14:56 ` Russell King - ARM Linux admin 2020-06-01 14:56 ` Russell King - ARM Linux admin [not found] ` <CGME20200601163034eucas1p1f9c726b605c18bf3944254cd83dd67b3@eucas1p1.samsung.com> 2020-06-01 16:30 ` Lukasz Stelmach 2020-06-01 16:30 ` Lukasz Stelmach [not found] ` <CGME20200601142811eucas1p1604c8e6ca06c09f1ec821ea5e1918c53@eucas1p1.samsung.com> 2020-06-01 14:27 ` [PATCH 5/5] arm: kexec_file: load zImage or uImage, initrd and dtb Łukasz Stelmach 2020-06-01 14:27 ` Łukasz Stelmach 2020-06-01 15:07 ` Russell King - ARM Linux admin 2020-06-01 15:07 ` Russell King - ARM Linux admin 2020-06-01 15:14 ` Russell King - ARM Linux admin 2020-06-01 15:14 ` Russell King - ARM Linux admin [not found] ` <CGME20200601164700eucas1p2e30af458bae7e820ca55f7936ac3579a@eucas1p2.samsung.com> 2020-06-01 16:46 ` Lukasz Stelmach 2020-06-01 16:46 ` Lukasz Stelmach [not found] ` <CGME20200601184829eucas1p1b06bfc130083f6248d624febed1de9fc@eucas1p1.samsung.com> 2020-06-01 18:48 ` Lukasz Stelmach 2020-06-01 18:48 ` Lukasz Stelmach [not found] ` <CGME20200602161737eucas1p241dd0e0a9b5eea7c5d5774c46b3c570b@eucas1p2.samsung.com> 2020-06-02 16:17 ` [PATCH v2 0/5] kexec_file_load() for arm Łukasz Stelmach 2020-06-02 16:17 ` Łukasz Stelmach [not found] ` <CGME20200602161737eucas1p2c83700f7c17296c4367ee3fda1c6e783@eucas1p2.samsung.com> 2020-06-02 16:17 ` [PATCH v2 1/5] arm: decompressor: set malloc pool size for the decompressor Łukasz Stelmach 2020-06-02 16:17 ` Łukasz Stelmach [not found] ` <CGME20200602161738eucas1p27dfbe386bd76555598d5574faf4fdad3@eucas1p2.samsung.com> 2020-06-02 16:17 ` [PATCH v2 2/5] arm: add image header definitions Łukasz Stelmach 2020-06-02 16:17 ` Łukasz Stelmach [not found] ` <CGME20200602161738eucas1p2151f88b526bb009c27820a4f290a961e@eucas1p2.samsung.com> 2020-06-02 16:17 ` [PATCH v2 3/5] arm: decompressor: define a new zImage tag Łukasz Stelmach 2020-06-02 16:17 ` Łukasz Stelmach [not found] ` <CGME20200602161738eucas1p2ccfaa7610dc6f76e209ba96d6278259e@eucas1p2.samsung.com> 2020-06-02 16:17 ` [PATCH v2 4/5] arm: Add kexec_image_info Łukasz Stelmach 2020-06-02 16:17 ` Łukasz Stelmach [not found] ` <CGME20200602161739eucas1p16a56ff590bf44e747d5ad6e178d57067@eucas1p1.samsung.com> 2020-06-02 16:17 ` [PATCH v2 5/5] arm: kexec_file: load zImage or uImage, initrd and dtb Łukasz Stelmach 2020-06-02 16:17 ` Łukasz Stelmach 2020-06-11 10:37 ` [PATCH 0/5] kexec_file_load() for arm Dave Young 2020-06-11 10:37 ` Dave Young 2020-06-11 10:37 ` Dave Young [not found] ` <CGME20200930183921eucas1p11a56f805421a614be67f869f5ed18b9b@eucas1p1.samsung.com> 2020-09-30 18:34 ` [PATCH v3 0/4] " Łukasz Stelmach 2020-09-30 18:34 ` Łukasz Stelmach 2020-09-30 18:34 ` Łukasz Stelmach [not found] ` <CGME20200930183923eucas1p2241d3e1b8d4d05a2228448ff8fc4bb74@eucas1p2.samsung.com> 2020-09-30 18:34 ` [PATCH v3 1/4] arm: add image header definitions Łukasz Stelmach 2020-09-30 18:34 ` Łukasz Stelmach 2020-09-30 18:34 ` Łukasz Stelmach [not found] ` <CGME20200930183924eucas1p2869520cc28e705073cb08c37c1e2fc6d@eucas1p2.samsung.com> 2020-09-30 18:34 ` [PATCH v3 2/4] arm: decompressor: define a new zImage tag Łukasz Stelmach 2020-09-30 18:34 ` Łukasz Stelmach 2020-09-30 18:34 ` Łukasz Stelmach [not found] ` <CGME20200930183924eucas1p1eba72052e1723ce75e00cbadbe03b6fa@eucas1p1.samsung.com> 2020-09-30 18:34 ` [PATCH v3 3/4] arm: Add kexec_image_info Łukasz Stelmach 2020-09-30 18:34 ` Łukasz Stelmach 2020-09-30 18:34 ` Łukasz Stelmach [not found] ` <CGME20200930183924eucas1p281730f3d651fc2c78d6a95e47a2c5220@eucas1p2.samsung.com> 2020-09-30 18:34 ` [PATCH v3 4/4] arm: kexec_file: load zImage or uImage, initrd and dtb Łukasz Stelmach 2020-09-30 18:34 ` Łukasz Stelmach 2020-09-30 18:34 ` Łukasz Stelmach 2020-10-01 10:09 ` kernel test robot 2020-10-01 10:09 ` kernel test robot
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=20200601182555.GP1551@shell.armlinux.org.uk \ --to=linux@armlinux.org.uk \ --cc=b.zolnierkie@samsung.com \ --cc=ben-linux@fluff.org \ --cc=info@metux.net \ --cc=keescook@chromium.org \ --cc=l.stelmach@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=m.szyprowski@samsung.com \ --cc=masahiroy@kernel.org \ --cc=mingo@kernel.org \ --cc=ndesaulniers@google.com \ --cc=takahiro.akashi@linaro.org \ --cc=tglx@linutronix.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: linkBe 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.