Presentation (at correct time): https://www.youtube.com/watch?v=xj0PBFjLm1U&t=5730s

Slides: https://linuxplumbersconf.org/event/11/contributions/947/att...

Article mentions fs-verify, which I'd never heard of and sounds interesting!

I always found it a bit odd that Linux doesn't have a standard binary signing mechanism, like Windows does through Authenticode (well, and Catalog signatures, and now a different scheme for UWL apps too).

I guess it's not quite as necessary, since on Linux you typically get apps from trusted package repositories, but personally it's still something I'd like to see, so file integrity could be verified later (even offline if wanted).

Btw rpm package manager keeps track of checksums of metadata and content for all installed packages, so that one can verify integrity of all (rpm -Va) or a particular package (rpm -V foo) later.

Ah, cool, I didn't know that. Do you know if it uses public key signatures, or if it's simply a list of known hashes for each file of each version?

This applies to almost all modern linux package managers.

PGP is typically used to sign a collection of hashes (and other metadata). PGP is generally only used at package install/build time, and the subsequently installed/generated manifest is used when you ask the package manager to verify the package.

It just compares expected checksum from rpm database with actual state in the system.

That said, rpm supports package signing, so that it can catch a package which was tampered with and prevent it's installation.

so IIUC it's an os level tripwire ?

Yes. But I guess that tripwire has more features.

I guess the argument would be that your package manager checks the gpg trust chain provided by your repo -- but I totally understand that doesn't prevent a binary being modified once it's there on disk. Some level of protection about that is that typically apps aren't user writeable on *nix -- app signatures deal with a subtly different threat model (and arguably one in which sometimes the user is part of the threat...)

Prelinking can change binaries as well. A combination of a Mandatory Access Control system (SELinux, AppArmour) and a Host Based Intrusion Detection system (like AIDE) could respectively help prevent and detect changes to binaries.

I'm not entirely sure if techniques such as ASLR are fool-proof enough to prevent changes to binaries in memory - I haven't studied enough about ASLR yet.

Minor nitpick: it's fs-verity. As a non-native English speaker I walked into that one many a time.

It kind of does - you can use IMA to enforce signature validation, even including an x509 chain. But it using extended attributes for this results in a bunch of difficulties, and there's no good distro support for it at present.

Some of the most interesting BPF applications seem to be these tools here: https://github.com/iovisor/bcc

If I could combine something like Pin and BPF I'd be golden.

eBPF is great for tracing but there's only so much you can do without really injecting yourself into the target binary.

What would you do with such a combination?

A specific example: At [NDA-ed work project] we compile a lot of templates in our D code. I was using a uProbe to hijack the semantic analysis in the D compiler to count how many and where the templates where from.

All good so far, but the moment I wanted to do a little bit of non-trivial work (collect some metadata which is not a memory access away) I would've had to switch to some other much more complicated system. I don't think Pin is that complicated but it's not really intended for "infra" programming like eBPF.

I have no idea what BPF is, and couldn't deduce it from the first three paragraphs.

it refers to eBPF: https://en.wikipedia.org/wiki/Berkeley_Packet_Filter

If you're reading LWN over the last decade then BPF is implicitly understood at this point. Expanding the acronym is actually incredibly useless in this case.

Additionally, the technology behind BPF changed significantly in the last years to the point where the original meaning (Berkeley Packet Filter) doesn't really have anything to do with BPF anymore. BPF is not limited to network sockets anymore (or something else associated with Berkeley), it is not limited to packets anymore and filtering is not the only use case anymore. The reason that the BPF acronym stuck all those years is that the new BPF features were introduced gradually, there was no particular kernel release introducing a BPF version 2 with all the new features (a release which could have been used for changing the name).

In theory, the kernel people could come up with a new acronym (something like Kernel Bytecode Language might be appropriate), but at this point it's probably too late.

At some point, you have to accept that on a technical site like this, there is going to be jargon used (including abbreviations) with furtjer explication of meaning. Would you complain about using DNS? Or HTTP?

That is a good point. I'm not convinced I'm incorrect, but you are also correct.

Normally I’d agree, but in this case the meaning of the acronym tells you nothing (it stands for Berkeley Packet Filter. Make sense?) and BPF is easily googleable.

Also, it’s safe to assume that regular readers of LWN will know a little about BPF. Though obviously in this case it rose to the top of HN where it’s likely to be seen by a wider audience.

I agree with you.

It's was originally eBPF and that doesnt really tell you any more. Now we've dropped the 'e' and its turned in to an initialism unrelated to the original network related only functionality as others have said.

Im curious what others would call these if they could rename them...

Kernel Plugins?

Kernel Spies?

Advanced observability operators?