@pid_eins@mastodon.social
@pid_eins@mastodon.social avatar

pid_eins

@pid_eins@mastodon.social

⛵ I write software. ⛵

This profile is from a federated server and may be incomplete. Browse more on the original instance.

pid_eins, to random
@pid_eins@mastodon.social avatar

1️⃣3️⃣ Here's the 13th installment of posts highlighting key new features of the upcoming v256 release of systemd.

ssh is widely established as the mechanism for controlling Linux systems remotely, both interactively and with automated tools. It not only provides means for secure authentication and communication for a tty/shell, but also does this for file transfers (sftp), and IPC communication (D-Bus or Varlink).

pid_eins,
@pid_eins@mastodon.social avatar

@shoragan ssh over rs232, eh?

kernellogger, to linux
@kernellogger@fosstodon.org avatar

Jeremy Allison writes:

'" The data shows that “frozen” vendor kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux created by Greg Kroah-Hartman. '"

https://ciq.com/blog/why-a-frozen-linux-kernel-isnt-the-safest-choice-for-security/

pid_eins,
@pid_eins@mastodon.social avatar

@kernellogger @bluca sure, but then the rule is not "we never break userspace" but more "move fast and break things, and sometimes revert where people protest too loudly".

I mean, that's fine by me, but maybe they should communicate it like that then.

The thing is that removing a widely documented mount option is very obviously a compat breakage. You cannot discount that. It's not just a "mistake" to remove something like that, it's an obvious attempt to break compat.

pid_eins,
@pid_eins@mastodon.social avatar

@kernellogger @bluca

Actually, the exact relevant rule is "WE DO NOT BREAK USERSPACE", all in uppercase.

https://lkml.org/lkml/2012/12/23/75

I find the sound of that mail quite different from your much weaker "let's maybe undo the worst shit if people complain too loudly"... And of course "uh, sometimes we fucked up so hard, we cannot fix it anymore, let's add a new api instead" (which is what happened in the block device capabilities/media change api).

pid_eins,
@pid_eins@mastodon.social avatar

@kernellogger @bluca

(again, I actually find it OK if API is broken from time to time, just be honest about it, and communicate properly, and do a bit of research first. Don't claim that uppercase extremism and then do not even superficially follow through)

pid_eins, to random
@pid_eins@mastodon.social avatar

5️⃣ Here's the 5th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.

I am pretty sure all of you are well aware of the venerable "sudo" tool that is a key component of most Linux distributions since a long time. At the surface it's a tool that allows an unprivileged user to acquire privileges temporarily, from within their existing login sessions, for just one command, or maybe for a subshell.

"sudo" is very very useful, as it…

swsnr, to Steamdeck
@swsnr@mastodon.social avatar

My laptop screen broke, so I figured I could use my #SteamDeck as replacement. Didn't want to loose Steam OS, though, it's a gaming device after all.

So I bought a SanDisk SD card for 35€, and used #mkosi to flash a #fedora workstation disk image onto it. Took a few days to understand what #fedora packages I need for the full workstation experience, but in the the end the process was surprisingly smooth.

pid_eins,
@pid_eins@mastodon.social avatar

@triskelion @swsnr building initrds with mkosi is a thing. And what i'd recommend.

pid_eins, to random
@pid_eins@mastodon.social avatar

Kernel breaking userspace episode nr. 43858262:

https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66

Hacking around it:

https://github.com/systemd/systemd/pull/32892

pid_eins,
@pid_eins@mastodon.social avatar

And yes I am pretty sure they should revert the kernel change. Departing needlessly from the option name the other file systems give this is already wrong. But breaking all current systemd versions on new kernels just for the fun of it is extra wrong.

Note that I actually do think it's ok if kernel folks break interfaces every now and then if done for a good reason and if userspace is prepared. But here neither is the case. And my main beef here is that they claim they wouldnt do it ever...

pid_eins, to random
@pid_eins@mastodon.social avatar

Did you know you could control brightness of the red dot on the i of the "ThinkPad" on the top-side of your thinkpad? I sure didn't:

this turns it off:

echo 0 | sudo tee /sys/class/leds/tpacpi::lid_logo_dot/brightness

and this turns it on:

echo 255 | sudo tee /sys/class/leds/tpacpi::lid_logo_dot/brightness

I don't really know what this information is good for, but hey, isn't it awesome to have a 1px display on the outside of your laptop?

hyc, (edited ) to random
@hyc@mastodon.social avatar

Gag, puke, retch... This sample code for communicating with is abominable. https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html

From gratuitous use of superfluous language features (a cleanup handler, for a single fd, srsly?) to inappropriate use of standard POSIX APIs (using connect+write on a socket that only sends one message and then gets closed, really?) Older compilers don't even support a cleanup attribute, and this code is used as a model of portability??

's version is better.

pid_eins,
@pid_eins@mastodon.social avatar

@hyc @wednesday well, any compiler used on any Linux from the last decade or more supports the cleanup stuff. And that pretty much matches systemd's intended audience.

pid_eins, to random
@pid_eins@mastodon.social avatar

1️⃣5️⃣ Here's the 15th installment of posts highlighting key new features of the upcoming v256 release of systemd.

systemd integrates with many components of the OS. Due to this it links against various external libraries. Generic distributions – which typically enable all features a package provides – usually have to deal with relatively large dependency trees in cases like this.

pid_eins, (edited )
@pid_eins@mastodon.social avatar

systemd is often used in smaller environments, i.e run in containers, or in the initrd or similar. Hence a large dependency tree is problematic.

Because of that in systemd we started to turn a large number of our dependencies from regular ones to dlopen() ones: instead of always requiring some shared library we only load it the moment we need it. This means we can gracefully degrade our feature set if certain libraries are not available.

pid_eins,
@pid_eins@mastodon.social avatar

We have been doing this since quite a while, so that in v256 22 of our dependencies have been reworked like that.

This has the benefit that on a typical system the systemd binary itself only pulls in the C library (including libm), libmount, libselinux, libaudit and libseccomp.

Net result: we have a tiny required dependency footprint, but can still provide a large feature set, if the optional deps happen to be installed.

pid_eins,
@pid_eins@mastodon.social avatar

This comes at a price though: since our library dependencies are now dlopen() based they do not show up in the ELF metadata of our binaries anymore. And package managers such as dpkg/rpm generally look at that, and automatically translate those ELF dependencies into packaging dependencies.

Hence: at first glance, this means that we regress on this front: previously automatically determined dependencies have to be encoded manually again.

With v256 we are doing something about this.

pid_eins,
@pid_eins@mastodon.social avatar

For now the spec sits in systemd's repository. We intend to add it to the uapi group's repository soon though, as this really is supposed to be something not only systemd provides, but any software that is in a similar situation and uses dlopen() to gracefully import a fixed set of external libraries.

And that's all for now. Stay tuned for episode 16 soon.

(Sorry for not keeping up the pace btw, currently at a conference)

pid_eins, (edited )
@pid_eins@mastodon.social avatar

All our binaries now contain an ELF "note" describing these "weak" deps that can be processed in a similar way as regular ELF dependencies.

The format of these notes is described here:

https://github.com/systemd/systemd/blob/main/docs/ELF_DLOPEN_METADATA.md

There's now work ongoing to process this data automatically at rpm and dpkg build time, so that we get the best of both worlds: "weak" dependencies and proper metadata to declare them consistently.

kernellogger, to linux
@kernellogger@fosstodon.org avatar

The TPM bus encryption and integrity protection changes prepared by @jejb and @jarkko were merged for 6.10: https://git.kernel.org/torvalds/c/b19239143e393d4b52b3b9a17c7ac07138f2cfd4

"[…] The key pair on TPM side is generated from so called null random seed per power on of the machine [1]. This supports the TPM encryption of the hard drive by adding layer of protection against bus interposer attacks. […]"

[1 https://lore.kernel.org/linux-integrity/20240429202811.13643-1-James.Bottomley@HansenPartnership.com/

pid_eins,
@pid_eins@mastodon.social avatar

@jarkko @kernellogger @jejb systemd's disk encryption stuff actually has been using encrypted sessions for a long long time.

pid_eins, (edited ) to random
@pid_eins@mastodon.social avatar

1️⃣4️⃣ Here's the 14th installment of posts highlighting key new features of the upcoming v256 release of systemd.

This one is going to be quick one. Previously, you had to specify a block device name when invoking systemd-cryptenroll, to specify which encrypted volume to enroll your PKCS11/TPM2/FIDO2 device to. This is now optional. If no device is specified, then the tool will now automatically look for the device behind the /var/ directory and operate on that.

pid_eins,
@pid_eins@mastodon.social avatar

… detect such tricks, and refuse operation. In systemd we thus started to make more and more use of diskseq, for example via /dev/disk/by-diskseq/ device symlinks, or by referencing block devices via their diskseq numbers whenever possible. This works is incomplete currently, there are gaps at various places (for example, there's no userspace API to query the diskseq number from a mounted file system that is backed by a block device).

pid_eins,
@pid_eins@mastodon.social avatar

By automatically detecting the right block device the attack window for enrollment operations becomes a lot smaller, and once the last gaps in the diskseq kernel apis are fixed we can fully lock down things so that we can guarantee that it's really the right device we operate on and not some trick device.

You might wonder why we are derive the backing device of /var/ rather than the root file system for this automatic mechanism: that's because we generally focus on two ways to set up a system:

pid_eins,
@pid_eins@mastodon.social avatar
  1. you have a fully encrypted root fs, with /var/ being placed on the root fs too
  2. you have an immutable root fs, but /var/ is mounted writable.

In both these cases using /var/ as the path to search the backing block device for will work, while using / instead would not work for the 2nd case.

Also note, that this mechanism is automatically disabled when a destructive operation is used (i.e. an existing key slot shall be wiped), for robustness reasons.

pid_eins,
@pid_eins@mastodon.social avatar

And that's all for now, stay tuned for episode 15 soon.

pid_eins,
@pid_eins@mastodon.social avatar

@marie indeed! fixed!

pid_eins,
@pid_eins@mastodon.social avatar

@neingeist indeed! fixed!

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • rosin
  • thenastyranch
  • ethstaker
  • DreamBathrooms
  • osvaldo12
  • magazineikmin
  • tacticalgear
  • Youngstown
  • everett
  • mdbf
  • slotface
  • ngwrru68w68
  • kavyap
  • provamag3
  • Durango
  • InstantRegret
  • GTA5RPClips
  • tester
  • cubers
  • cisconetworking
  • normalnudes
  • khanakhh
  • modclub
  • anitta
  • Leos
  • megavids
  • lostlight
  • All magazines
    •