From: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org
Subject: Re: [PATCH] efi: libstub: Make file I/O chunking x86-specific
Date: Thu, 2 Feb 2017 21:44:49 +0000 [thread overview]
Message-ID: <20170202214449.GR31613@codeblueprint.co.uk> (raw)
In-Reply-To: <1485877949-21981-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, 31 Jan, at 03:52:29PM, Ard Biesheuvel wrote:
> The ARM decompressor is finicky when it comes to uninitialized variables
> with local linkage, the reason being that it may relocate .text and .bss
> independently when executing from ROM. This is only possible if all
> references into .bss from .text are absolute, and this happens to be the
> case for references emitted under -fpic to symbols with external linkage,
> and so all .bss references must involve symbols with external linkage.
>
> When building the ARM stub using clang, the initialized local variable
> __chunk_size is optimized into a zero-initialized flag that indicates
> whether chunking is in effect or not. This flag is therefore emitted into
> .bss, which triggers the ARM decompressor's diagnostics, resulting in a
> failed build.
>
> Under UEFI, we never execute the decompressor from ROM, so the diagnostic
> makes little sense here. But we can easily work around the issue by making
> __chunk_size global instead.
>
> However, given that the file I/O chunking that is controlled by the
> __chunk_size variable is intended to work around known bugs on various
> x86 implementations of UEFI, we can simply make the chunking an x86
> specific feature. This is an improvement by itself, and also removes the
> need to parse the efi= options in the stub entirely.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/firmware/efi/libstub/efi-stub-helper.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
Reviewed-by: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
WARNING: multiple messages have this Message-ID (diff)
From: matt@codeblueprint.co.uk (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] efi: libstub: Make file I/O chunking x86-specific
Date: Thu, 2 Feb 2017 21:44:49 +0000 [thread overview]
Message-ID: <20170202214449.GR31613@codeblueprint.co.uk> (raw)
In-Reply-To: <1485877949-21981-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, 31 Jan, at 03:52:29PM, Ard Biesheuvel wrote:
> The ARM decompressor is finicky when it comes to uninitialized variables
> with local linkage, the reason being that it may relocate .text and .bss
> independently when executing from ROM. This is only possible if all
> references into .bss from .text are absolute, and this happens to be the
> case for references emitted under -fpic to symbols with external linkage,
> and so all .bss references must involve symbols with external linkage.
>
> When building the ARM stub using clang, the initialized local variable
> __chunk_size is optimized into a zero-initialized flag that indicates
> whether chunking is in effect or not. This flag is therefore emitted into
> .bss, which triggers the ARM decompressor's diagnostics, resulting in a
> failed build.
>
> Under UEFI, we never execute the decompressor from ROM, so the diagnostic
> makes little sense here. But we can easily work around the issue by making
> __chunk_size global instead.
>
> However, given that the file I/O chunking that is controlled by the
> __chunk_size variable is intended to work around known bugs on various
> x86 implementations of UEFI, we can simply make the chunking an x86
> specific feature. This is an improvement by itself, and also removes the
> need to parse the efi= options in the stub entirely.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/firmware/efi/libstub/efi-stub-helper.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
next prev parent reply other threads:[~2017-02-02 21:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-31 15:52 [PATCH] efi: libstub: Make file I/O chunking x86-specific Ard Biesheuvel
2017-01-31 15:52 ` Ard Biesheuvel
[not found] ` <1485877949-21981-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-01-31 18:42 ` Arnd Bergmann
2017-01-31 18:42 ` Arnd Bergmann
2017-02-02 21:44 ` Matt Fleming [this message]
2017-02-02 21:44 ` Matt Fleming
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=20170202214449.GR31613@codeblueprint.co.uk \
--to=matt-mf/unelci9gs6ibeejttw/xrex20p6io@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@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.