From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 286EC37BE81 for ; Tue, 21 Apr 2026 03:06:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776740799; cv=none; b=r3VNalhoORdLVBtyuGIbKSw3Pth2o2e2lLiLmpaUDUh8VvrP30HkFNd6ax1MhaDfczMyYDTs8oGF1wRVhL8FlmIiBGYRV6F+PkTYczqihcjrmdAgAgMymtq/mj9gPhTAWWy/46uDV2AY8/cp6sly4RY2ZdsPePCh+YQMJPixdHQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776740799; c=relaxed/simple; bh=ezMwEMLGAhcGTdQ8X9wIqNhUP1mkpwmf7k0v/U06VK8=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=VI3uJAOSc6GyYN8Roi98UMjwtTFiZ9XLSh2/G8xsaLhpa1xM525fveTBr9FYvgivd7sFD+6AmJGGJ45q6QiCR4XVOIKOpn//2K/0yjv/Q+aRi82HQedkNJXL96Ur/XPkpTD+U+vdlPxoG4KgZPA5fyK1JRhg9/WfNZej1xiel7E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jfZ+lRX6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jfZ+lRX6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF502C2BCB6; Tue, 21 Apr 2026 03:06:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776740798; bh=ezMwEMLGAhcGTdQ8X9wIqNhUP1mkpwmf7k0v/U06VK8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From; b=jfZ+lRX6SiZrH4ZXiQES2haKCs16RRyZ3pKX9nwaKUq3CbjniclcL0u5Oj41yTtQx L45bXVOWpXiF81K8jvL/JoMEYnvn6BkbaySrnPZ5JDsq8C+U3G3GIgITxRAfHbw24x 5EInVdCQq6X0/bBwzoYd7V7hfjcgXXB9DUBUACIYtBHlGaNJnADhp0bFF3REatVQ2T 3+x2sx1ehKgNV4qYY26mSt2V+5llsu29jPiREl2s1rGg9FUXHCALHhJjoqlRBrt3Su 1yrr/lsZ/B9wvxTKHtI8zUO8NYhB3ncLn3yjXn39QW3sFtRxvO+zARlE+L9MfEcb/B bYuHUqyYN8Lmg== From: sashiko-bot@kernel.org Subject: Re: [PATCH v5 08/10] hornet: Add a light skeleton data extractor scripts Reply-To: sashiko@lists.linux.dev To: "Blaise Boscaccy" Cc: bpf@vger.kernel.org In-Reply-To: <20260420212653.438685-9-bboscaccy@linux.microsoft.com> References: <20260420212653.438685-9-bboscaccy@linux.microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Apr 2026 03:06:38 +0000 Message-Id: <20260421030638.AF502C2BCB6@smtp.kernel.org> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Sashiko AI review found 4 potential issue(s): - [High] Payload data corruption due to grep matching multiple lines and pr= intf format string reuse. - [Medium] Scripts fail to preprocess headers because gcc is invoked withou= t include paths. - [Medium] Pipeline failure when processing BPF programs with empty map dat= a. - [Low] Copy-paste error in usage text and unsafe unquoted variable usage. -- commit 5d4574520f6f666709ea15ecc132a023d9222886 Author: Blaise Boscaccy hornet: Add a light skeleton data extractor scripts This commit introduces bash scripts to extract instructions and map data fr= om autogenerated eBPF light skeleton headers. These payloads can be used for signing light skeleton binaries. > diff --git a/scripts/hornet/extract-insn.sh b/scripts/hornet/extract-insn= .sh > new file mode 100755 > index 0000000000000..52338f057ff6b > --- /dev/null > +++ b/scripts/hornet/extract-insn.sh [ ... ] > +if [ $ARGC -ne $EXPECTED_ARGS ] ; then > + usage > +else > + printf $(gcc -E $1 | grep "opts_insn" | \ > + awk -F"=3D" '{print $2}' | sed 's/;\+$//' | sed 's/\"//g') > +fi Will this corrupt the binary payload if grep matches multiple lines? Skeleton headers generated by bpftool typically contain additional references like opts.insns_sz =3D sizeof(opts_insn) - 1; and opts.insns =3D (void *)opts_insn;. Because the $(...) command substitution is unquoted, Bash will split the output into multiple arguments. Since printf doesn't receive format specifiers, it will reuse the binary payload as the format string for each extra argument (such as sizeof, -, 1), repeating the payload multiple times in the output. Also, because EXPECTED_ARGS=3D1 is strictly enforced, users cannot pass -I flags. Since the generated headers unconditionally include and , will gcc -E fail and terminate before emitting the target variables if those headers are not in the default system include pat= h? Could $1 be quoted as "$1" to prevent failures when the file path contains spaces? > diff --git a/scripts/hornet/extract-map.sh b/scripts/hornet/extract-map.sh > new file mode 100755 > index 0000000000000..c309f505c6238 > --- /dev/null > +++ b/scripts/hornet/extract-map.sh [ ... ] > +function usage() { > + echo "Sample script for extracting instructions" This isn't a bug, but should this say "extracting map data" instead of "instructions" since this is the map extractor script? > + echo "autogenerated eBPF lskel headers" > + echo "" > + echo "USAGE: header_file" > + exit > +} [ ... ] > diff --git a/scripts/hornet/extract-skel.sh b/scripts/hornet/extract-skel= .sh > new file mode 100755 > index 0000000000000..6550a86b89917 > --- /dev/null > +++ b/scripts/hornet/extract-skel.sh [ ... ] > +if [ $ARGC -ne $EXPECTED_ARGS ] ; then > + usage > +else > + printf $(gcc -E $1 | grep "static const char opts_$2" | \ > + awk -F"=3D" '{print $2}' | sed 's/;\+$//' | sed 's/\"//g') > +fi If a BPF program uses no maps, the extracted skeleton will declare static const char opts_data[] =3D "";. The awk and sed pipeline will strip the quotes, resulting in an empty command substitution. Since calling printf without arguments triggers a shell usage error (bash: printf: usage: printf [-v var] format [arguments]) and returns a non-zero exit status, will this break automated pipelines for map-less BPF programs? Additionally, since extract-skel.sh avoids the multiple-match issue by using a stricter grep pattern (grep "static const char opts_$2"), does this make extract-insn.sh and extract-map.sh redundant? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260420212653.4386= 85-1-bboscaccy@linux.microsoft.com?part=3D8