Capture TRACER_TRACE_ID env var in eBPF

[jdidion]

Updated eBPF code that captures a single variable, TRACER_TRACE_ID, if present, from a process' environment.

Notes:

• This won't work for the general case of capturing all environment variables - the eBPF event object size limitation is too small.
• This will only work for capturing a limited number of pre-specified environment variables, because the number of instructions quickly increase beyond the maximum allowed complexity of an eBPF program.

I also updated the exit handling code to capture the full wait status rather than just the exit code. I tried to write a test for this but there is an error that the eBPF program can't be installed.

🧪 Testing

To install tracer with this version/branch, run:

curl -sSL https://install.tracer.cloud | CLI_BRANCH="branch_name" sh

To use the installer of tracer with this version/branch, run:

curl -sSL https://install.tracer.cloud | INS_BRANCH="branch_name" sh

📌 Summary

🔍 Related Issues/Tickets

✨ Changes Introduced

✨ Infrastructure Impact

✅ Checklist

• Code follows the project's style guidelines
• I have performed a self-review of my own code
• I have tested the changes and they work as expected
• Documentation has been updated if needed
• Tests have been added or updated

🛠️ How to Test

🚀 Screenshots (if applicable)

📌 Additional Notes

[cloudflare-workers-and-pages]

Deploying tracer-client with    Cloudflare Pages

Latest commit:	9d0d2d1
Status:	✅  Deploy successful!
Preview URL:	https://64fd9f9c.tracer-client.pages.dev
Branch Preview URL:	https://feature-ebpf-env-variables-f.tracer-client.pages.dev

View logs

[MicheleVerriello]

can you also remove this filename? i don't think it's useful and we never get this

[jdidion]

done

[MicheleVerriello]

same here for the filename

[jdidion]

done

[graphite-app]

The signal termination check needs a slight adjustment. According to POSIX wait status conventions, a process is terminated by a signal when (status & 0x7f) != 0 and (status & 0x7f) != 0x7f. The current implementation only checks the first condition, which could lead to incorrect identification of signal terminations.

The correct implementation should be:

let signaled = (status & 0x7f) != 0 && (status & 0x7f) != 0x7f;

This ensures proper handling of all wait status cases according to the POSIX specification.

Suggested change

	let signaled = (status & 0x7f) != 0;
	let term_signal = if signaled {
	let signaled = (status & 0x7f) != 0 && (status & 0x7f) != 0x7f;
	let term_signal = if signaled {

Spotted by Diamond

Is this helpful? React 👍 or 👎 to let us know.

[graphite-app]

There's a potential buffer overflow vulnerability in the startswith function. The function reads up to plen bytes from string s without verifying that s has sufficient length. If s is shorter than plen, this will read beyond the buffer bounds, potentially causing undefined behavior.

Consider adding a null terminator check for s before accessing each character:

static __always_inline int startswith(const char *s, const char *p, int plen)
{
  /* memcmp is verifier-friendly when plen is bounded */
  for (int i = 0; i < plen; i++)
  {
    if (!s[i] || s[i] != p[i])
      return 0;
    if (!p[i])
      break;
  }
  return 1;
}

This ensures the function stops if it reaches the end of string s before reading plen characters.

Suggested change

	static __always_inline int startswith(const char *s, const char *p, int plen)
	{
	/* memcmp is verifier-friendly when plen is bounded */
	for (int i = 0; i < plen; i++)
	{
	if (s[i] != p[i])
	return 0;
	if (!p[i])
	break;
	}
	return 1;
	}
	static __always_inline int startswith(const char *s, const char *p, int plen)
	{
	/* memcmp is verifier-friendly when plen is bounded */
	for (int i = 0; i < plen; i++)
	{
	if (!s[i] || s[i] != p[i])
	return 0;
	if (!p[i])
	break;
	}
	return 1;
	}

Spotted by Diamond

Is this helpful? React 👍 or 👎 to let us know.