today I learned that there is a company that sells "agentless" Linux EDR. you might wonder what it means to do EDR without an agent.
apparently "agentless" means "instead of installing a daemon that runs in the background, one super-uber-privileged server will periodically ssh into all your Linux boxes as root, drop executable files in a temporary folder, run those executable files to run a detection pass, and wipe itself from the system again".
See this diagram from their documentation:

— "Can you believe how stupid and primitive the ancient Greeks were? When they didn't know something, they asked an oracle, and they believed whatever it said!"
— "That's nuts. Where was this oracle?"
— "No idea. Let's go ask ChatGPT."

(gdb) c
Continuing.
Recursive internal problem.

Time to take a break, I guess…

Home made shoyu ramen

Today I finally carved out some time to implement return value capture for the Linux kernel function tracer. As of 6.17-rc1, this is done via the HAVE_FUNCTION_GRAPH_FREGS architecture feature. On ARM32, that basically means stashing function call specific registers in pt_regs inside the ftrace arch code.

Once I wrapped my head around the intended semantics, it came together surprisingly smoothly.

Then I enabled the ftrace self-test… and hit this splat:

[    3.299111] ------------[ cut here ]------------
[    3.299173] WARNING: CPU: 0 PID: 1 at kernel/trace/trace.c:2215 run_tracer_selftest+0x110/0x148
[    3.299441] Modules linked in:
[    3.299725] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc1-gd7ee5bdce789 #141 NONE 
[    3.299806] Hardware name: Generic DT based system
[    3.299887] Call trace: 
[    3.299932]  unwind_backtrace from show_stack+0x18/0x1c
[    3.299987]  show_stack from dump_stack_lvl+0x54/0x68
[    3.299999]  dump_stack_lvl from __warn+0x88/0x12c
[    3.300013]  __warn from warn_slowpath_fmt+0x194/0x19c
[    3.300026]  warn_slowpath_fmt from run_tracer_selftest+0x110/0x148
[    3.300039]  run_tracer_selftest from register_tracer+0x11c/0x1cc
[    3.300054]  register_tracer from do_one_initcall+0x60/0x210
[    3.300066]  do_one_initcall from kernel_init_freeable+0x1d4/0x240
[    3.300079]  kernel_init_freeable from kernel_init+0x20/0x140
[    3.300091]  kernel_init from ret_from_fork+0x14/0x28
[    3.300131] Exception stack(0xe080dfb0 to 0xe080dff8)
[    3.300204] dfa0:                                     00000000 00000000 00000000 00000000
[    3.300217] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    3.300224] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    3.300282] ---[ end trace 0000000000000000 ]---

I double- and triple-checked my changes, still no clue. Then it dawned on me: the test fails even without any of my patches. 🫠

2012: "Secure boot is a plot by Microsoft to kill Linux"
2025: EA's insistence on invasive anti-cheat results in a bunch of Windows users managing to get their secure boot configuration into a state where their GPUs no longer work and there's no recovery path: https://www.reddit.com/r/Battlefield/comments/1miaynl/secure_boot_megathread_guide_community_support/

Microsoft would have to be *very* bad at this for a plot to have backfired this badly

I am so enjoying watching #ai brogrammers crying in their designer water bottles as upgraded #ai models take their carefully crafted prompt and outputs totally different bollocks to the last one so they can't tweak their app any more.

It's enough pain for real programmers handling tool upgrades to tweak their work and re-run test suites but for the AI lot it's carnage.

• Step 1: While debugging a kernel issue, you want the return value of a function at startup.

• Step 2: Instead of just adding a printk() and recompiling, you try tracing like the cool kids.

• Step 3: Since 2023, the function graph tracer can show return values. You add to the kernel command line and reboot: ftrace=function_graph ftrace_filter=interesting_fn trace_options=funcgraph-retval

• Step 4: The trace shows no return value. You find that ARM return value capture exists only for AArch64, not ARM32.

• Step 5: You add a printk() and rebuild.

(disclaimer: i did not create this, but also could not find who created it)

Urgent help for OpenPrinting needed!

As many here know, I am co-founder and lead of OpenPrinting since 2001, known as the print guru for Linux and free software by many. I also got one of the 8 fellows of the Linux Foundation for this.

Up to now I was working at Canonical, hired back in 2006 just to run OpenPrinting and also to maintain printing-related Ubuntu packages.

... 🧵

Please boost.

#OpenPrinting #LinuxFoundation #getfedihired

list_add(figure_out_postgresql_replication, &task_list);

list_add(Linode, &shit_list);

"Ein Jahr nach dem #Crowdstrike -Ausfall: Was wurde aus dem IT-Fiasko gelernt?"

Nix. Es wird immer noch davon ausgegangen, dass Schlangenöl die IT-Sicherheit verbessern würde und verpflichtend gekauft werden muss. Jetzt halt mit noch mehr KI zur Cloud.

Linux Kernel Hardening: Ten Years Deep

Talk by @kees about the relevance of various Linux kernel vulnerability classes and the mitigations that address them.

Video: https://www.youtube.com/watch?v=c_NxzSRG50g
Slides: https://static.sched.com/hosted_files/lssna2025/9f/KSPP%20Ten%20Years%20Deep.pdf

Fefe hat alle Genesungswünsche E-Mails gelesen und bedankt sich bei allen sehr! Gleich geht die Reha weiter!

#fefe

Just saw a software devloper coding in a cafe

-NO Cursor
-NO Windsurf
-NO DeepSeek
-NO ChatGPT
-No Google

He just sat there typing code manually in vim on his rusty Thinkpad and reading man pages on Arch Linux

What a psychopath 🫣

I really hope major Linux distros will stop shipping the sudo disease in their default installations at some point.

A thing I'm quite tired of seeing in technical spaces are exceptions being made for engineers because they are "smart". Widely known as the brilliant asshole.

This is code. It can be difficult, doing it well is even more difficult. It's also table stakes for this job. Especially when it comes to OSS. We are not so unique that we can't be replaced with another coder. I have replaced myself with very competent engineers at Meta in my work with btrfs.

What makes "smart" engineers is their ability to work with other people. This fantasy that "ideas" are how we communicate and the best idea wins, the most technical argument wins, is simply not true. You get your code in because you know how to communicate. Does that include technical arguments? Of course it does. But if you bring that technical argument to the table with "I can't believe you were so stupid to do it this other way, you should all thank me for being here" you are going to be far less successful.

That doesn't make you smart. To me, "smart" includes all the things necessary to accomplish your task as quickly and efficiently as possible. Part of that for us is coding, but the larger part is communication and the relationships we build with each other by being consistent with how we communicate and treat other people.

I work with the smartest people in the world. They are smart because they can code. They are smart because they are kind and gracious with their communication. They are smart because they build community in the work that they do.

If your community is a developer of 1 and nobody wants you around, it doesn't matter how good of a coder you are. You have failed at one of the core tenants of your job. In the real world, with real stakes, real bosses, real accountability, you would be fired. And that would be the correct outcome.

The power of OSS is the fact that it's many developers working on a thing. We all witness the power of this every day, but still cling to this fantasy that it's one smart asshole that keeps the whole thing together.

We are all replaceable in OSS. That's the beauty of it. It will outlast every once of us.

If you run an operation that pays freelance authors for articles, you get a *lot* of people trying to sell you the output from their slop factory of choice. These pitches far exceed the legitimate ones at this point.

Today we got a pitch for an article about the load-balancing scheduler regression caused by the sched_ext framework in the 6.11 release. Somebody has clearly put a bit more than the usual amount of attention into the sort of topic that might appeal to @lwn. There is only one little problem... that regression had nothing to do with sched_ext, which was merged in 6.12. The pitch was a bunch of authoritative-sounding bullshit; the article would surely have been more of the same.

Sometimes I truly lose hope about humanity's ability to keep its head above the flood of this stuff.

I love how Apple will now be repeating every security mistake by writing their own container runtime. I thought we're past all that but hey, let's have some more path lookup CVEs. @cyphar

https://github.com/apple/containerization/pull/173

In the i686 discussion in #Fedora we currently hear quite a lot of voices in support for the Steam client, but not that much of other use cases.

If you have anything specific using i686 packages on Fedora, which is _not_ Steam, this is a good time to mention it, so that your use cases are not lost.

https://discussion.fedoraproject.org/t/f44-change-proposal-drop-i686-support-system-wide/156324

And please do not panic, it is a discussion, nothing is decided yet :)