All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Hans de Goede <hdegoede@redhat.com>,
	linux-crypto@vger.kernel.org, linux-s390@vger.kernel.org,
	x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Stephan Mueller <smueller@chronox.de>,
	kexec@lists.infradead.org
Subject: Re: [PATCH] lib/string: make memzero_explicit inline instead of external
Date: Thu, 10 Oct 2019 14:56:00 +0800	[thread overview]
Message-ID: <20191010065600.GA9838@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20191010025229.GA3376@dhcp-128-65.nay.redhat.com>

On 10/10/19 at 10:52am, Dave Young wrote:
> On 10/07/19 at 06:00pm, Arvind Sankar wrote:
> > With the use of the barrier implied by barrier_data(), there is no need
> > for memzero_explicit to be extern. Making it inline saves the overhead
> > of a function call, and allows the code to be reused in arch/*/purgatory
> > without having to duplicate the implementation.
> > 
> > Fixes: 906a4bb97f5d ("crypto: sha256 - Use get/put_unaligned_be32 to get input, memzero_explicit")
> > Reviewed-by: Hans de Goede <hdegoede@redhat.com>
> > Tested-by: Hans de Goede <hdegoede@redhat.com>
> > Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
> > ---
> >  include/linux/string.h | 21 ++++++++++++++++++++-
> >  lib/string.c           | 21 ---------------------
> >  2 files changed, 20 insertions(+), 22 deletions(-)
> > 
> > diff --git a/include/linux/string.h b/include/linux/string.h
> > index b2f9df7f0761..b6ccdc2c7f02 100644
> > --- a/include/linux/string.h
> > +++ b/include/linux/string.h
> > @@ -227,7 +227,26 @@ static inline bool strstarts(const char *str, const char *prefix)
> >  }
> >  
> >  size_t memweight(const void *ptr, size_t bytes);
> > -void memzero_explicit(void *s, size_t count);
> > +
> > +/**
> > + * memzero_explicit - Fill a region of memory (e.g. sensitive
> > + *		      keying data) with 0s.
> > + * @s: Pointer to the start of the area.
> > + * @count: The size of the area.
> > + *
> > + * Note: usually using memset() is just fine (!), but in cases
> > + * where clearing out _local_ data at the end of a scope is
> > + * necessary, memzero_explicit() should be used instead in
> > + * order to prevent the compiler from optimising away zeroing.
> > + *
> > + * memzero_explicit() doesn't need an arch-specific version as
> > + * it just invokes the one of memset() implicitly.
> > + */
> > +static inline void memzero_explicit(void *s, size_t count)
> > +{
> > +	memset(s, 0, count);
> > +	barrier_data(s);
> > +}
> >  
> >  /**
> >   * kbasename - return the last part of a pathname.
> > diff --git a/lib/string.c b/lib/string.c
> > index cd7a10c19210..08ec58cc673b 100644
> > --- a/lib/string.c
> > +++ b/lib/string.c
> > @@ -748,27 +748,6 @@ void *memset(void *s, int c, size_t count)
> >  EXPORT_SYMBOL(memset);
> >  #endif
> >  
> > -/**
> > - * memzero_explicit - Fill a region of memory (e.g. sensitive
> > - *		      keying data) with 0s.
> > - * @s: Pointer to the start of the area.
> > - * @count: The size of the area.
> > - *
> > - * Note: usually using memset() is just fine (!), but in cases
> > - * where clearing out _local_ data at the end of a scope is
> > - * necessary, memzero_explicit() should be used instead in
> > - * order to prevent the compiler from optimising away zeroing.
> > - *
> > - * memzero_explicit() doesn't need an arch-specific version as
> > - * it just invokes the one of memset() implicitly.
> > - */
> > -void memzero_explicit(void *s, size_t count)
> > -{
> > -	memset(s, 0, count);
> > -	barrier_data(s);
> > -}
> > -EXPORT_SYMBOL(memzero_explicit);
> > -
> >  #ifndef __HAVE_ARCH_MEMSET16
> >  /**
> >   * memset16() - Fill a memory area with a uint16_t
> > -- 
> 
> Thanks for the fix!  Ccing kexec list since the problem is kexec/kdump
> related.  People can try it when they see same issue.
> 

Also:

Tested-by: Dave Young <dyoung@redhat.com>

Thanks
Dave


WARNING: multiple messages have this Message-ID (diff)
From: Dave Young <dyoung@redhat.com>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: linux-s390@vger.kernel.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Stephan Mueller <smueller@chronox.de>,
	x86@kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, Hans de Goede <hdegoede@redhat.com>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	linux-crypto@vger.kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH] lib/string: make memzero_explicit inline instead of external
Date: Thu, 10 Oct 2019 14:56:00 +0800	[thread overview]
Message-ID: <20191010065600.GA9838@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20191010025229.GA3376@dhcp-128-65.nay.redhat.com>

On 10/10/19 at 10:52am, Dave Young wrote:
> On 10/07/19 at 06:00pm, Arvind Sankar wrote:
> > With the use of the barrier implied by barrier_data(), there is no need
> > for memzero_explicit to be extern. Making it inline saves the overhead
> > of a function call, and allows the code to be reused in arch/*/purgatory
> > without having to duplicate the implementation.
> > 
> > Fixes: 906a4bb97f5d ("crypto: sha256 - Use get/put_unaligned_be32 to get input, memzero_explicit")
> > Reviewed-by: Hans de Goede <hdegoede@redhat.com>
> > Tested-by: Hans de Goede <hdegoede@redhat.com>
> > Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
> > ---
> >  include/linux/string.h | 21 ++++++++++++++++++++-
> >  lib/string.c           | 21 ---------------------
> >  2 files changed, 20 insertions(+), 22 deletions(-)
> > 
> > diff --git a/include/linux/string.h b/include/linux/string.h
> > index b2f9df7f0761..b6ccdc2c7f02 100644
> > --- a/include/linux/string.h
> > +++ b/include/linux/string.h
> > @@ -227,7 +227,26 @@ static inline bool strstarts(const char *str, const char *prefix)
> >  }
> >  
> >  size_t memweight(const void *ptr, size_t bytes);
> > -void memzero_explicit(void *s, size_t count);
> > +
> > +/**
> > + * memzero_explicit - Fill a region of memory (e.g. sensitive
> > + *		      keying data) with 0s.
> > + * @s: Pointer to the start of the area.
> > + * @count: The size of the area.
> > + *
> > + * Note: usually using memset() is just fine (!), but in cases
> > + * where clearing out _local_ data at the end of a scope is
> > + * necessary, memzero_explicit() should be used instead in
> > + * order to prevent the compiler from optimising away zeroing.
> > + *
> > + * memzero_explicit() doesn't need an arch-specific version as
> > + * it just invokes the one of memset() implicitly.
> > + */
> > +static inline void memzero_explicit(void *s, size_t count)
> > +{
> > +	memset(s, 0, count);
> > +	barrier_data(s);
> > +}
> >  
> >  /**
> >   * kbasename - return the last part of a pathname.
> > diff --git a/lib/string.c b/lib/string.c
> > index cd7a10c19210..08ec58cc673b 100644
> > --- a/lib/string.c
> > +++ b/lib/string.c
> > @@ -748,27 +748,6 @@ void *memset(void *s, int c, size_t count)
> >  EXPORT_SYMBOL(memset);
> >  #endif
> >  
> > -/**
> > - * memzero_explicit - Fill a region of memory (e.g. sensitive
> > - *		      keying data) with 0s.
> > - * @s: Pointer to the start of the area.
> > - * @count: The size of the area.
> > - *
> > - * Note: usually using memset() is just fine (!), but in cases
> > - * where clearing out _local_ data at the end of a scope is
> > - * necessary, memzero_explicit() should be used instead in
> > - * order to prevent the compiler from optimising away zeroing.
> > - *
> > - * memzero_explicit() doesn't need an arch-specific version as
> > - * it just invokes the one of memset() implicitly.
> > - */
> > -void memzero_explicit(void *s, size_t count)
> > -{
> > -	memset(s, 0, count);
> > -	barrier_data(s);
> > -}
> > -EXPORT_SYMBOL(memzero_explicit);
> > -
> >  #ifndef __HAVE_ARCH_MEMSET16
> >  /**
> >   * memset16() - Fill a memory area with a uint16_t
> > -- 
> 
> Thanks for the fix!  Ccing kexec list since the problem is kexec/kdump
> related.  People can try it when they see same issue.
> 

Also:

Tested-by: Dave Young <dyoung@redhat.com>

Thanks
Dave


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2019-10-10  6:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-07 13:47 [PATCH v2 5.4 regression fix] x86/boot: Provide memzero_explicit Hans de Goede
2019-10-07 14:00 ` Ingo Molnar
2019-10-07 14:11   ` Hans de Goede
2019-10-07 14:22     ` Ingo Molnar
2019-10-07 14:29       ` Hans de Goede
2019-10-07 14:46         ` Ingo Molnar
2019-10-07 15:20           ` Arvind Sankar
2019-10-07 15:40             ` Ingo Molnar
2019-10-07 18:42               ` Arvind Sankar
2019-10-07 19:36                 ` Hans de Goede
2019-10-07 22:00                   ` [PATCH] lib/string: make memzero_explicit inline instead of external Arvind Sankar
2019-10-08 11:33                     ` [tip: x86/urgent] lib/string: Make memzero_explicit() " tip-bot2 for Arvind Sankar
2019-10-08 11:33                     ` tip-bot2 for Arvind Sankar
2019-10-10  2:52                     ` [PATCH] lib/string: make memzero_explicit " Dave Young
2019-10-10  2:52                       ` Dave Young
2019-10-10  6:56                       ` Dave Young [this message]
2019-10-10  6:56                         ` Dave Young
2019-10-07 14:49 ` [tip: x86/urgent] x86/boot: Provide memzero_explicit() tip-bot2 for Hans de Goede
2019-10-07 14:49 ` tip-bot2 for Hans de Goede

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=20191010065600.GA9838@dhcp-128-65.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bp@alien8.de \
    --cc=hdegoede@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nivedita@alum.mit.edu \
    --cc=smueller@chronox.de \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.