All of lore.kernel.org
 help / color / mirror / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Jeff King <peff@peff.net>,
	Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com,
	Taylor Blau <ttaylorr@openai.com>
Subject: Re: [PATCH v2 0/7] trace2: stop allowing die()
Date: Mon, 31 Aug 2026 09:27:49 -0400	[thread overview]
Message-ID: <a41bdb3b-1fe7-4c1e-9d16-72390d93503b@gmail.com> (raw)
In-Reply-To: <20260827052318.GC176544@coredump.intra.peff.net>

On 8/27/2026 1:23 AM, Jeff King wrote:
> On Tue, Aug 25, 2026 at 06:56:14PM +0000, Derrick Stolee via GitGitGadget wrote:
> 
>> This starts with a new banned-die.h header file at the root of the repo and
>> including it from all trace2 API *.c files. It starts empty, but the later
>> patches will add one method at a time:
>>
>>  * xsnprintf() : This is the original patch, but made more complete by
>>    adding the method to banned-die.h.
>>  * xstrdup()
>>  * ALLOC_ARRAY()
>>  * xstrfmt()
>>  * ALLOC_GROW()
>>  * xcalloc()
> 
> OK. This feels like the tip of the iceberg, though. All of strbuf would
> have to be off-limits, too (both because it calls malloc directly, but
> also because it will bail if snprintf() returns -1). I won't be
> surprised if there are other indirect calls hiding in various places
> (e.g., all of json-writer.c).

You're absolutely right. Not only in json-writer.c, but several direct
calls to the strbuf API. The only real way to fix that would be to
create a "safe strbuf" library. This is potentially an interesting
direction that I might want to pursue and send an RFC after getting
started. 
> I think if you really want to avoid allocations in trace2 it would
> probably need to be a ground-up no-dependency rewrite.

Or to update the dependencies to be "safe". Not an easy thing, either
way.

I don't have much knowledge of CodeQL, but the following vibe-coded
.ql script is able to detect these transitive calls and demonstrate
the issue:

----

import cpp

class Trace2Function extends Function {
  Trace2Function() {
    getFile().getRelativePath() = "trace2.c" or
    getFile().getRelativePath().matches("trace2/%.c")
  }
}

predicate directlyCalls(Function caller, Function callee) {
  exists(FunctionCall call |
    call.getEnclosingFunction() = caller and
    call.getTarget() = callee
  )
}

from Trace2Function source, Function sink
where
  sink.getName() = "die" and
  directlyCalls+(source, sink)
select source, "This Trace2 function can transitively reach die()."

----

Adding such a check now would obviously fail and not provide any
ability to demonstrate incremental progress like banned-die.h.

I know that microsoft/git is running CodeQL analysis to look for
security issues [1] but doesn't appear to be running specific
queries like this one.

[1] https://github.com/microsoft/git/commit/6b367b94752b7ae0fada0629a542e90ea0a1892c

Perhaps this is something we could investigate in the future.

Thanks,
-Stolee


  reply	other threads:[~2026-08-31 13:27 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 16:12 [PATCH] trace2: tolerate failed timestamp formatting Derrick Stolee via GitGitGadget
2026-07-17 16:24 ` Taylor Blau
2026-07-18 15:01   ` Derrick Stolee
2026-07-20 14:29     ` Junio C Hamano
2026-07-20 14:37       ` Taylor Blau
2026-07-29 21:35       ` Junio C Hamano
2026-07-31 13:26         ` Derrick Stolee
2026-07-31 15:57           ` Junio C Hamano
2026-08-25 18:56 ` [PATCH v2 0/7] trace2: stop allowing die() Derrick Stolee via GitGitGadget
2026-08-25 18:56   ` [PATCH v2 1/7] banned-die: create header for banning of functions Derrick Stolee via GitGitGadget
2026-08-25 20:34     ` Junio C Hamano
2026-08-31 12:28       ` Derrick Stolee
2026-08-31 13:30       ` Patrick Steinhardt
2026-08-25 22:14     ` Elijah Newren
2026-08-31 12:29       ` Derrick Stolee
2026-08-27  5:10     ` Jeff King
2026-08-31 12:38       ` Derrick Stolee
2026-08-25 18:56   ` [PATCH v2 2/7] trace2: tolerate failed timestamp formatting Derrick Stolee via GitGitGadget
2026-08-25 18:56   ` [PATCH v2 3/7] trace2: remove use of xstrdup() Derrick Stolee via GitGitGadget
2026-08-25 22:14     ` Elijah Newren
2026-08-31 12:41       ` Derrick Stolee
2026-08-25 18:56   ` [PATCH v2 4/7] trace2: remove use of ALLOC_ARRAY() Derrick Stolee via GitGitGadget
2026-08-25 18:56   ` [PATCH v2 5/7] trace2: remove use of xstrfmt() Derrick Stolee via GitGitGadget
2026-08-25 22:14     ` Elijah Newren
2026-08-25 22:36       ` Junio C Hamano
2026-08-31 12:51         ` Derrick Stolee
2026-08-25 18:56   ` [PATCH v2 6/7] trace2: remove use of ALLOC_GROW() Derrick Stolee via GitGitGadget
2026-08-25 22:14     ` Elijah Newren
2026-08-25 18:56   ` [PATCH v2 7/7] trace2: remove use of xcalloc() Derrick Stolee via GitGitGadget
2026-08-27  5:23   ` [PATCH v2 0/7] trace2: stop allowing die() Jeff King
2026-08-31 13:27     ` Derrick Stolee [this message]
2026-09-01  5:01       ` Jeff King
2026-09-01  5:03         ` Jeff King
2026-09-01 13:42           ` Derrick Stolee
2026-08-31 17:25 ` [PATCH v3 " Derrick Stolee via GitGitGadget
2026-08-31 17:25   ` [PATCH v3 1/7] banned-die: create header for banning of functions Derrick Stolee via GitGitGadget
2026-08-31 17:25   ` [PATCH v3 2/7] trace2: tolerate failed timestamp formatting Derrick Stolee via GitGitGadget
2026-08-31 17:25   ` [PATCH v3 3/7] trace2: remove use of xstrdup() Derrick Stolee via GitGitGadget
2026-08-31 17:25   ` [PATCH v3 4/7] trace2: remove use of ALLOC_ARRAY() Derrick Stolee via GitGitGadget
2026-08-31 17:25   ` [PATCH v3 5/7] trace2: remove use of xstrfmt() Derrick Stolee via GitGitGadget
2026-08-31 17:25   ` [PATCH v3 6/7] trace2: remove use of ALLOC_GROW() Derrick Stolee via GitGitGadget
2026-08-31 17:25   ` [PATCH v3 7/7] trace2: remove use of xcalloc() Derrick Stolee via GitGitGadget
2026-10-06 14:37   ` [PATCH v3 0/7] trace2: stop allowing die() Derrick Stolee

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=a41bdb3b-1fe7-4c1e-9d16-72390d93503b@gmail.com \
    --to=stolee@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=ttaylorr@openai.com \
    /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.