https://github.com/m4b/goblin/issues/415

@ljs tadaa https://www.youtube.com/watch?v=QDUv_8Dw-Mw

GitHub's co-founder and former CEO launched the Ladybird initiative, a brand-new independent browser written from scratch and backed by a non-profit.
https://linuxiac.com/ladybird-is-a-new-browser-initiative-backed-up-by-1m/

More GPLv3 there is in the world, more there is legal risks for AI companies. It has that power, even tho was not designed with this exact purpose in mind.

I think, just based on experience on previous tech revolutions, that #AI is neither useless nor it is going to repeal and replace human labor.

It just hasn’t hit the its roof, or more precisely constraints, yet.

Media only giving voice to either AI companies or AI researchers turned into doomsday predictors, is at least quite strong signal of a bubble.

If you feel that AI is evil, here’s couple of suggestions what you can do:

1. Engage and support open source ecosystem. It is essentially a crowd-sourced alternative to AI where people work together to realize the best possible software for other people and for themselves.
2. Consider #GPLv3 and #AGPLv3 as an alternative to making “standard Github choice” of #Apache or #MIT. It is a self-governing and collaboration enabling licensing model. I think AI makes #GPL more relevant than it ever has been so far in its history. I’ve at least started to pro-actively rethink how I license my own projects, instead of lazily just putting MIT or similar license.

I'm happy I got to see this sight in my lifetime ;-) The blue egg of death.

@ljs i still that in this case more relevant than what type of memory error we are talking about, is how long the rollback process took ;-)

i'd expect large cloud companies to test their emergency procedures, not just red teaming but also simulate faulty patches getting through.

I like bpftool/libbpf approach definitely over bpftrace and Aya.rs. Both add a shimmering layer that masks the view for me too much. Also, bpftrace does not allow to *tailor* the tracing process because it defines one ;-) [and is great for what it is, love it]

I could imagine Aya.rs hit me if I was doing user space profiling. I think it is great too but sub-optimally heavy for my needs...

I know this looks like crap but it was "enough implementation" for me to be sure that this kind of program is actually doable ;-) Sometimes it is good to optimize for the worst... https://codeberg.org/jarkko/hello-ebpf

I.e. BPF program only passes the backtraces to the ring buffer and no intelligence on that side. All heavy-lifting will be done by the host program. The only shared data structure is a single BPF ring buffer.

I think that I do as a next #BPF exercise a "poor man's" flame graph generator for #TPM driver, meaning no interaction and make most of VT output ;-)

I could also consider to do it for #kernel #keyring later on but TPM driver is easier to scope: only look at events that end up to tpm_transmit().

Instead of "perf sampling approach" I'm planning to use BPF ring buffer and use that to all backtraces to tpm_transmit() to the user space host program. Then the host program implemented with C will post-process that queue in parallel.

Frequency of TPM commands is low enough so that 1:1 granularity should be possible.

Can't wait to get this done, will be a fun tool for future patch reviews I make ;-)

#eBPF

Backed up for future revisit with tpm_transmit() histogram: https://codeberg.org/jarkko/hello-ebpf. I learned something :-)

I’ll try next open coding sudo bpftrace -e 'kprobe:tpm_transmit { @[kstack] = count(); }'.

I.e. probably something like this (at least compiles and loads):

#include "vmlinux.h"
#include <bpf/bpf_core_read.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

char LICENSE[] SEC("license") = "GPL";

struct {
	__uint(type, BPF_MAP_TYPE_HASH);
	__type(key, int);
	__type(value, int);
	__uint(max_entries, 100);
} tpm_transmits SEC(".maps");

SEC("kprobe/tpm_transmit")
int BPF_KPROBE(kprobe__tpm_transmit, struct pt_regs *regs)
{
	/* TODO: update tpm_transmits map */
	return 0;
}

Also, kprobe requires target architecture, so the object file is now compiled as follows:

clang -g -O2 -target bpf -D__TARGET_ARCH_x86 -c payload.c

Binary has now a symbol for maps:

~/work/local/ebpf master*
❯ nm payload.o
0000000000000000 T kprobe__tpm_transmit
0000000000000000 r ____kprobe__tpm_transmit.____fmt
0000000000000000 D LICENSE
0000000000000000 D tpm_transmits

I don’t have any particular use for eBPF but it is nice to get a bit more in-depth picture on the topic…

Just wanted to go through how it is done without any external tools and/or abstraction layers, so now I know... ☑️

Here’s a minimal shenanigans for #eBPF #C host, with bpftool taking care of header generation.

Payload (payload.c):

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
SEC("tracepoint/syscalls/sys_enter_execve")
int tracepoint__syscalls__sys_enter_execve(struct trace_event_raw_sys_enter *ctx)
{
	bpf_printk("execve");
	return 0;
}
char LICENSE[] SEC("license") = "GPL";

Host (main.c):

#include <bpf/bpf.h>
#include <bpf/libbpf.h>
#include <signal.h>
#include "payload.h"

static volatile bool interrupted = false;
struct payload *obj;

void do_sigint(int value)
{
	interrupted = true;
}

int main(void)
{
	struct sigaction sa;
	ssize_t ret;

	obj = payload__open();
	if (!obj)
		exit(1);

	ret  = payload__load(obj);
	if (ret)
		goto err;

	ret = payload__attach(obj);
	if (ret)
		goto err;

	sa.sa_handler = do_sigint;
	sigaction(SIGINT, &sa, NULL);
	while (!interrupted);
	fprintf(stderr, "\ndone\n");
	payload__destroy(obj);	
	exit(0);

err:
	payload__destroy(obj);	
	exit(1);
}

Build (build.sh):

#!/usr/bin/env sh

# vmlinux
bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

# payload
clang -g -O2 -target bpf -I . -c payload.c -o payload.o
bpftool gen skeleton payload.o > payload.h

# main
clang -g -O2 -Wall -I . -c main.c -o main.o

# hello-ebpf
clang -Wall -O2 -g main.o -lbpf -lelf -lz -o hello-ebpf

While running trace_pipe is expected to have output like this:

             cat-61135   [011] ....1  8303.116335: bpf_trace_printk: execve
             zsh-61136   [002] ....1  8303.116691: bpf_trace_printk: execve
             zsh-61139   [004] ....1  8303.118436: bpf_trace_printk: execve

#linux #kernel #tracing

@vathpela @robhague commodore power ✊

@jwz And also it is my new and better LinkedIn. I've scored couple of relevant work interviews for the future through this forum "without even trying" just doing my thing and logging it here, and not trying to form any kind of "professional image".

@jwz I like use this platofrm as my devlog, make short writeups, snippets and such and so forth. Then I bookmark the most relevant ones, and later on I use them as source material for longer writeups, presentations and other stuff. Mastodon is sort of like "better Github Gists" for my needs.

Submitted some ideas to rust-vmm/vm-memory how it should be extended to work for confidential (#SGX, #SNP and #TDX) payloads to make it scale for the needs of #Enarx:

https://github.com/rust-vmm/vm-memory/issues/291

#linux #kvm #rust #rustlang

@janantos Yeah, still I'd expect more rigid implementation from vending machine tbh. I.e. not saying that PowerShell would be somehow worse than any other scripting language.