From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 22 Jan 2019 04:48:59 -0000 Received: from userp2130.oracle.com ([156.151.31.86]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1glnzd-00043X-Ka for speck@linutronix.de; Tue, 22 Jan 2019 05:48:58 +0100 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0M4ibFQ094558 for ; Tue, 22 Jan 2019 04:48:51 GMT Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2q3uauhc0j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 22 Jan 2019 04:48:50 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x0M4mohN012331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 22 Jan 2019 04:48:50 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x0M4mo8C032312 for ; Tue, 22 Jan 2019 04:48:50 GMT Date: Mon, 21 Jan 2019 23:48:49 -0500 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [PATCH v5 15/27] MDSv5 1 Message-ID: <20190122044849.GK12859@char.us.oracle.com> References: <24251e879478600d7015012f91e62a2e4bc0880b.1547858934.git.ak@linux.intel.com> MIME-Version: 1.0 In-Reply-To: <24251e879478600d7015012f91e62a2e4bc0880b.1547858934.git.ak@linux.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, Jan 18, 2019 at 04:50:30PM -0800, speck for Andi Kleen wrote: > From: Andi Kleen > Subject: mds: Schedule cpu clear for memzero_explicit and > kzfree > > Assume that any code using these functions is sensitive and shouldn't > leak any data. > > This handles clearing for key data used in the kernel. > > Suggested-by: Linus Torvalds > Signed-off-by: Andi Kleen Reviewed-by: Konrad Rzeszutek Wilk > --- > lib/string.c | 6 ++++++ > mm/slab_common.c | 5 ++++- > 2 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/lib/string.c b/lib/string.c > index 38e4ca08e757..9ce59dd86541 100644 > --- a/lib/string.c > +++ b/lib/string.c > @@ -28,6 +28,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -715,12 +716,17 @@ EXPORT_SYMBOL(memset); > * necessary, memzero_explicit() should be used instead in > * order to prevent the compiler from optimising away zeroing. > * > + * As a side effect this may also trigger extra cleaning > + * of CPU state before the next kernel exit to avoid > + * side channels. > + * > * 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); > + lazy_clear_cpu(); > barrier_data(s); > } > EXPORT_SYMBOL(memzero_explicit); > diff --git a/mm/slab_common.c b/mm/slab_common.c > index 81732d05e74a..7b5e2e1318a2 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -1576,6 +1576,9 @@ EXPORT_SYMBOL(krealloc); > * Note: this function zeroes the whole allocated buffer which can be a good > * deal bigger than the requested buffer size passed to kmalloc(). So be > * careful when using this function in performance sensitive code. > + * > + * As a side effect this may also clear CPU state later before the > + * next kernel exit to avoid side channels. > */ > void kzfree(const void *p) > { > @@ -1585,7 +1588,7 @@ void kzfree(const void *p) > if (unlikely(ZERO_OR_NULL_PTR(mem))) > return; > ks = ksize(mem); > - memset(mem, 0, ks); > + memzero_explicit(mem, ks); > kfree(mem); > } > EXPORT_SYMBOL(kzfree); > -- > 2.17.2