From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_LOW, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1935 invoked from network); 26 May 2023 09:52:56 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 26 May 2023 09:52:56 -0000 Received: (qmail 13630 invoked by uid 550); 26 May 2023 09:52:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13588 invoked from network); 26 May 2023 09:52:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zhasha.com; s=wirbelwind; t=1685094756; bh=JBqPanzKJygA6vSG1O8LDabKuLI8h20waSIOvYnl9uE=; h=Date:From:To:Subject:In-Reply-To:References; b=FaoyRv3cWijPVr6f4bAgHmFrqxVXaoER7exMgGHlGaapLnLupo8+Si6j3nVvboSB2 KcYUR5JTlfj3veHlLl3W+wnmxecZaTvD0Tu8jkjGKcclY3iryteXP9vEd9TB6SYYGW rohb32TykB6fioBSLSWJ9y4hkg+aPbrcd+yNTeiE= Date: Fri, 26 May 2023 11:52:36 +0200 From: Joakim Sindholt To: musl@lists.openwall.com Message-Id: <20230526115236.b15f8bf97a529da07fba514f@zhasha.com> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Fri__26_May_2023_11_52_36_+0200_PDh2_YC5B3VodRdH" Subject: Re: [musl] [C23 string conversion 1/3] C23: add the new memset_explicit function This is a multi-part message in MIME format. --Multipart=_Fri__26_May_2023_11_52_36_+0200_PDh2_YC5B3VodRdH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 26 May 2023 11:25:43 +0200, Jens Gustedt wrote: > This function is meant to work around the fact that C compilers are > allowed to optimize calls to memset out, if they are able to detect > that the byte array will die soon, anyway. This permission for memset > may lead to data leak when non-priveledged parts of an application > would be able to reconstruct secret information from memory received > through malloc or on the stack. > > This function here is to force compilers to do the clean up operation > under all circumstances. How to do that is out of the scope of the C > standard, so there is not much help there, it only describes the > intent. > > By having a slow bytewise copy, we intent also to have predictable > timing, such that we can avoid side-channel attacks. We also do our > best to remove the meta-information, which is the pointer value from > the stack and combine that with a synchronizing operation at the end. I don't see how this is in any way useful. It's certainly not part of the standard, which only says: > The intention is that the memory store is always performed (i.e., > never elided), regardless of optimizations. This is in contrast to > calls to the memset function (7.26.6.1) > --- > include/string.h | 1 + > src/string/memset_explicit.c | 14 ++++++++++++++ > 2 files changed, 15 insertions(+) > create mode 100644 src/string/memset_explicit.c > > diff --git a/include/string.h b/include/string.h > index 05019c03..78ccccbd 100644 > --- a/include/string.h > +++ b/include/string.h > @@ -27,6 +27,7 @@ extern "C" { > void *memcpy (void *__restrict, const void *__restrict, size_t); > void *memmove (void *, const void *, size_t); > void *memset (void *, int, size_t); > +void *memset_explicit(void *, int, size_t); > int memcmp (const void *, const void *, size_t); > > void *(memchr) (const void *, int, size_t); > diff --git a/src/string/memset_explicit.c b/src/string/memset_explicit.c > new file mode 100644 > index 00000000..49ced751 > --- /dev/null > +++ b/src/string/memset_explicit.c > @@ -0,0 +1,14 @@ > +#include > +#include > +#include > + > +void *memset_explicit(void *dest, register int c, register size_t n) > +{ > + register unsigned char volatile *p = dest; > + register unsigned char volatile *stop = p + n; > + for (; p < stop; ++p) > + *p = c; > + // the CAS operation serves as memory barrier, and destroys the > + // information, if it happened to be spilled on the stack > + return a_cas_p(&dest, dest, 0); > +} > -- > 2.34.1 > Musl effectively already has this function in that it has explicit_bzero. Why not simply copy it? Hell, while we're at it, implement explicit_bzero in terms of memset_explicit. --Multipart=_Fri__26_May_2023_11_52_36_+0200_PDh2_YC5B3VodRdH Content-Type: application/octet-stream; name="0001-implement-C23-memset_explicit.patch" Content-Disposition: attachment; filename="0001-implement-C23-memset_explicit.patch" Content-Transfer-Encoding: base64 RnJvbSA2MGEyYWQyYzRmMGIxYWY4YTBjMmU2OTNkMjNlODNjZTg3YTZjNDg5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKb2FraW0gU2luZGhvbHQgPG9wZW5zb3VyY2VAemhhc2hhLmNv bT4KRGF0ZTogRnJpLCAyNiBNYXkgMjAyMyAxMTo1MDozNCArMDIwMApTdWJqZWN0OiBbUEFUQ0hd IGltcGxlbWVudCBDMjMgbWVtc2V0X2V4cGxpY2l0CgotLS0KIGluY2x1ZGUvc3RyaW5nLmggICAg ICAgICAgICAgfCAxICsKIHNyYy9zdHJpbmcvZXhwbGljaXRfYnplcm8uYyAgfCAzICstLQogc3Jj L3N0cmluZy9tZW1zZXRfZXhwbGljaXQuYyB8IDggKysrKysrKysKIDMgZmlsZXMgY2hhbmdlZCwg MTAgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBzcmMv c3RyaW5nL21lbXNldF9leHBsaWNpdC5jCgpkaWZmIC0tZ2l0IGEvaW5jbHVkZS9zdHJpbmcuaCBi L2luY2x1ZGUvc3RyaW5nLmgKaW5kZXggZGI3M2QyYTkuLmRlNDIzMmI1IDEwMDY0NAotLS0gYS9p bmNsdWRlL3N0cmluZy5oCisrKyBiL2luY2x1ZGUvc3RyaW5nLmgKQEAgLTI3LDYgKzI3LDcgQEAg ZXh0ZXJuICJDIiB7CiB2b2lkICptZW1jcHkgKHZvaWQgKl9fcmVzdHJpY3QsIGNvbnN0IHZvaWQg Kl9fcmVzdHJpY3QsIHNpemVfdCk7CiB2b2lkICptZW1tb3ZlICh2b2lkICosIGNvbnN0IHZvaWQg Kiwgc2l6ZV90KTsKIHZvaWQgKm1lbXNldCAodm9pZCAqLCBpbnQsIHNpemVfdCk7Cit2b2lkICpt ZW1zZXRfZXhwbGljaXQgKHZvaWQgKiwgaW50LCBzaXplX3QpOwogaW50IG1lbWNtcCAoY29uc3Qg dm9pZCAqLCBjb25zdCB2b2lkICosIHNpemVfdCk7CiB2b2lkICptZW1jaHIgKGNvbnN0IHZvaWQg KiwgaW50LCBzaXplX3QpOwogCmRpZmYgLS1naXQgYS9zcmMvc3RyaW5nL2V4cGxpY2l0X2J6ZXJv LmMgYi9zcmMvc3RyaW5nL2V4cGxpY2l0X2J6ZXJvLmMKaW5kZXggZjJlMTJmMjMuLjczOGEwOTZi IDEwMDY0NAotLS0gYS9zcmMvc3RyaW5nL2V4cGxpY2l0X2J6ZXJvLmMKKysrIGIvc3JjL3N0cmlu Zy9leHBsaWNpdF9iemVyby5jCkBAIC0zLDYgKzMsNSBAQAogCiB2b2lkIGV4cGxpY2l0X2J6ZXJv KHZvaWQgKmQsIHNpemVfdCBuKQogewotCWQgPSBtZW1zZXQoZCwgMCwgbik7Ci0JX19hc21fXyBf X3ZvbGF0aWxlX18gKCIiIDogOiAiciIoZCkgOiAibWVtb3J5Iik7CisJbWVtc2V0X2V4cGxpY2l0 KGQsIDAsIG4pOwogfQpkaWZmIC0tZ2l0IGEvc3JjL3N0cmluZy9tZW1zZXRfZXhwbGljaXQuYyBi L3NyYy9zdHJpbmcvbWVtc2V0X2V4cGxpY2l0LmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg MDAwMDAwMDAuLmFjNTRmMGNmCi0tLSAvZGV2L251bGwKKysrIGIvc3JjL3N0cmluZy9tZW1zZXRf ZXhwbGljaXQuYwpAQCAtMCwwICsxLDggQEAKKyNpbmNsdWRlIDxzdHJpbmcuaD4KKwordm9pZCAq bWVtc2V0X2V4cGxpY2l0KHZvaWQgKmQsIGludCBjLCBzaXplX3QgbikKK3sKKwlkID0gbWVtc2V0 KGQsIGMsIG4pOworCV9fYXNtX18gX192b2xhdGlsZV9fICgiIiA6IDogInIiKGQpIDogIm1lbW9y eSIpOworCXJldHVybiBkOworfQotLSAKMi4yNi4zCgo= --Multipart=_Fri__26_May_2023_11_52_36_+0200_PDh2_YC5B3VodRdH--