The purgatory code now uses the shared lib/crypto/sha256.c sha256
implementation. This needs memzero_explicit, implement this.
Reported-by: Arvind Sankar <[email protected]>
Fixes: 906a4bb97f5d ("crypto: sha256 - Use get/put_unaligned_be32 to get input, memzero_explicit")
Signed-off-by: Hans de Goede <[email protected]>
---
Changes in v2:
- Add barrier_data() call after the memset, making the function really
explicit. Using barrier_data() works fine in the purgatory (build)
environment.
---
arch/x86/boot/compressed/string.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/boot/compressed/string.c b/arch/x86/boot/compressed/string.c
index 81fc1eaa3229..654a7164a702 100644
--- a/arch/x86/boot/compressed/string.c
+++ b/arch/x86/boot/compressed/string.c
@@ -50,6 +50,12 @@ void *memset(void *s, int c, size_t n)
return s;
}
+void memzero_explicit(void *s, size_t count)
+{
+ memset(s, 0, count);
+ barrier_data(s);
+}
+
void *memmove(void *dest, const void *src, size_t n)
{
unsigned char *d = dest;
--
2.23.0
* Hans de Goede <[email protected]> wrote:
> The purgatory code now uses the shared lib/crypto/sha256.c sha256
> implementation. This needs memzero_explicit, implement this.
>
> Reported-by: Arvind Sankar <[email protected]>
> Fixes: 906a4bb97f5d ("crypto: sha256 - Use get/put_unaligned_be32 to get input, memzero_explicit")
> Signed-off-by: Hans de Goede <[email protected]>
> ---
> Changes in v2:
> - Add barrier_data() call after the memset, making the function really
> explicit. Using barrier_data() works fine in the purgatory (build)
> environment.
> ---
> arch/x86/boot/compressed/string.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/x86/boot/compressed/string.c b/arch/x86/boot/compressed/string.c
> index 81fc1eaa3229..654a7164a702 100644
> --- a/arch/x86/boot/compressed/string.c
> +++ b/arch/x86/boot/compressed/string.c
> @@ -50,6 +50,12 @@ void *memset(void *s, int c, size_t n)
> return s;
> }
>
> +void memzero_explicit(void *s, size_t count)
> +{
> + memset(s, 0, count);
> + barrier_data(s);
> +}
So the barrier_data() is only there to keep LTO from optimizing out the
seemingly unused function?
Is there no canonical way to do that, instead of a seemingly obscure
barrier_data() call - which would require a comment at minimum.
We do have $(DISABLE_LTO), not sure whether it's applicable here though.
Thanks,
Ingo
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: ee008a19f1c72c37ffa54326a592035dddb66fd6
Gitweb: https://git.kernel.org/tip/ee008a19f1c72c37ffa54326a592035dddb66fd6
Author: Hans de Goede <[email protected]>
AuthorDate: Mon, 07 Oct 2019 15:47:24 +02:00
Committer: Ingo Molnar <[email protected]>
CommitterDate: Mon, 07 Oct 2019 16:47:35 +02:00
x86/boot: Provide memzero_explicit()
The purgatory code now uses the shared lib/crypto/sha256.c sha256
implementation. This needs memzero_explicit(), implement this.
We also have barrier_data() call after the memset, making sure
neither the compiler nor the linker optimizes out this seemingly
unused function.
Reported-by: Arvind Sankar <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: H . Peter Anvin <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Fixes: 906a4bb97f5d ("crypto: sha256 - Use get/put_unaligned_be32 to get input, memzero_explicit")
Link: https://lkml.kernel.org/r/[email protected]
[ Added comment. ]
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/boot/compressed/string.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/boot/compressed/string.c b/arch/x86/boot/compressed/string.c
index 81fc1ea..dd30e63 100644
--- a/arch/x86/boot/compressed/string.c
+++ b/arch/x86/boot/compressed/string.c
@@ -50,6 +50,16 @@ void *memset(void *s, int c, size_t n)
return s;
}
+void memzero_explicit(void *s, size_t count)
+{
+ memset(s, 0, count);
+ /*
+ * Make sure this function never gets inlined and
+ * the memset() never gets optimized away:
+ */
+ barrier_data(s);
+}
+
void *memmove(void *dest, const void *src, size_t n)
{
unsigned char *d = dest;
* Arvind Sankar <[email protected]> wrote:
> With the barrier in there, is there any reason to *not* inline the
> function? barrier_data() is an asm statement that tells the compiler
> that the asm uses the memory that was set to zero, thus preventing it
> from removing the memset even if nothing else uses that memory later. A
> more detailed comment is there in compiler-gcc.h. I can't see why it
> wouldn't work even if it were inlined.
>
> If the function can indeed be inlined, we could just make the common
> implementation a macro and avoid duplicating it? As mentioned in another
> mail, we otherwise will likely need another duplicate implementation for
> arch/s390/purgatory as well.
I suspect macro would be justified in this case. Mind sending a v3 patch
to demonstrate how it would all look like?
I'll zap v2 if the macro solution looks better.
Thanks,
Ingo
On Mon, Oct 07, 2019 at 05:40:07PM +0200, Ingo Molnar wrote:
>
> * Arvind Sankar <[email protected]> wrote:
>
> > With the barrier in there, is there any reason to *not* inline the
> > function? barrier_data() is an asm statement that tells the compiler
> > that the asm uses the memory that was set to zero, thus preventing it
> > from removing the memset even if nothing else uses that memory later. A
> > more detailed comment is there in compiler-gcc.h. I can't see why it
> > wouldn't work even if it were inlined.
> >
> > If the function can indeed be inlined, we could just make the common
> > implementation a macro and avoid duplicating it? As mentioned in another
> > mail, we otherwise will likely need another duplicate implementation for
> > arch/s390/purgatory as well.
>
> I suspect macro would be justified in this case. Mind sending a v3 patch
> to demonstrate how it would all look like?
>
> I'll zap v2 if the macro solution looks better.
>
> Thanks,
>
> Ingo
Patch attached to turn memzero_explicit into inline function.