Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D7B3C678D5 for ; Thu, 9 Mar 2023 00:31:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229732AbjCIAbF (ORCPT ); Wed, 8 Mar 2023 19:31:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53522 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229634AbjCIAbB (ORCPT ); Wed, 8 Mar 2023 19:31:01 -0500 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84F7C5552B; Wed, 8 Mar 2023 16:31:00 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C5C8D5C017E; Wed, 8 Mar 2023 19:30:58 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 08 Mar 2023 19:30:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bur.io; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1678321858; x=1678408258; bh=WP wVWF0IoiZrZqy+/FAl/fj3eRnsltm3szUz0R/YJXQ=; b=G80ZhESH6esAmX8eZy TciXLj3ZMVwTL1/gaMxgcNgrC5vfKKp0CDSYjSJiTtt7xJdYJdlvb2bONbKEywOd nLV3OLT2Q4WA8QkQUTDHVg8nLYlWCkMISBnd3SuY8FYD2WfqZ6+Oz2zO4ZMPTZrN m9n79a39js7CDfq+fFNW/8UH4FOS+qUldHwnsEKpH5gq94iFXndp9J7c9wV2MRIm kt40ZnZziBh6UerFkLL1IdT0+6jGfUPoE6cWGiF4Q2PkUhxqHwahYlx9bjrB+3HO Kfv4W+kiOtxjJs8zgIJiMUocx8mqipg/dOfccviMfG+RkPU4TfaEw5iFiWHS5ss8 lSJw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1678321858; x=1678408258; bh=WPwVWF0IoiZrZ qy+/FAl/fj3eRnsltm3szUz0R/YJXQ=; b=RD+9fBm8nykm3tr+gshXJNngnVB5l HpnOAyqDdiM1E+CrVR0dfy/vucfFdwe5+4roo3T1Vq+8RdsIub/q6JWU0X1vrPBk JByetFxVlcugGqAp9xLMO166AvGsbdsjhFj449p9SJkfWPPLqUjDisRvgxafJJ/f YH2nVzxCrQzIhwdKoXstOp79KCqeOi90P8/DB3/dvgb93xE/V+B9KB2oQRrt6nja eRiYTxNrd2/Z9ctCthBd2g3UAkS3EQZ1djv5XxMyrHZL4mRBySx3Z+d8ZxXmzuLk sw2vNmEMABOKY7nljk6Tpl2E24OkKWkSmQ5sDwmIV2PoIPqWTdoMDwbnw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvddugedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehorhhi shcuuehurhhkohhvuceosghorhhishessghurhdrihhoqeenucggtffrrghtthgvrhhnpe ekvdekffejleelhfevhedvjeduhfejtdfhvdevieeiiedugfeugfdtjefgfeeljeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsohhrihhsse gsuhhrrdhioh X-ME-Proxy: Feedback-ID: i083147f8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Mar 2023 19:30:57 -0500 (EST) Date: Wed, 8 Mar 2023 16:30:55 -0800 From: Boris Burkov To: sdf@google.com Cc: Rong Tao , andrii@kernel.org, rongtao@cestc.cn, Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Jiri Olsa , "open list:BPF [LIBRARY] (libbpf)" , open list Subject: Re: [PATCH bpf-next] libbpf: poison strlcpy() Message-ID: <20230309003055.GA6586@zen> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 05, 2023 at 10:47:15AM -0800, sdf@google.com wrote: > On 01/05, Rong Tao wrote: > > From: Rong Tao > > > Since commit 9fc205b413b3("libbpf: Add sane strncpy alternative and use > > it internally") introduce libbpf_strlcpy(), thus add strlcpy() to a poison > > list to prevent accidental use of it. > > > Signed-off-by: Rong Tao > > Acked-by: Stanislav Fomichev > > > --- > > tools/lib/bpf/libbpf_internal.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > diff --git a/tools/lib/bpf/libbpf_internal.h > > b/tools/lib/bpf/libbpf_internal.h > > index 377642ff51fc..2d26ded383ca 100644 > > --- a/tools/lib/bpf/libbpf_internal.h > > +++ b/tools/lib/bpf/libbpf_internal.h > > @@ -20,8 +20,8 @@ > > /* make sure libbpf doesn't use kernel-only integer typedefs */ > > #pragma GCC poison u8 u16 u32 u64 s8 s16 s32 s64 > > > -/* prevent accidental re-addition of reallocarray() */ > > -#pragma GCC poison reallocarray > > +/* prevent accidental re-addition of reallocarray()/strlcpy() */ > > +#pragma GCC poison reallocarray strlcpy On my musl system, I believe this broke compilation, as string.h defines strlcpy, and is included after this poisoning when compiling strset.c FWIW, I could work around it by adding #include above #include in strset.c, since the poison doesn't apply to symbols that existed before it ran, but this feels like a kludge, and not in the spirit of the original poisoning patch.. I'm curious what the proper workaround should be for a libc that defines strlcpy. Thanks, Boris > > > #include "libbpf.h" > > #include "btf.h" > > -- > > 2.39.0 >