@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.

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
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...

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)

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, (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.

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)

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

This of course makes the tool a bit more comfortable to use, since you don't have to figure out the backing block device of your encrypted volume first. But it's actually a security measure too:

On Linux referencing block devices by their device names such as "/dev/sda" is a bit problematic when it comes to security, since these names are reused on unplug/replug. Thus, there's a good chance that various security-relevant operations executed on disks can be tricked, …

pid_eins,
@pid_eins@mastodon.social avatar

… by quickly removing one disk, and plugging in another, so that the device node goes away, and comes back under the same name, but suddenly referring to a different device.

There has been work on addressing this problem, specfically there's now a "diskseq" counter exposed on Linux block devices that changes on every media change and device unplug. Thus, if on first use of a device the diskseq number is stored away, and then verified on each subsequent operation it's possible to…

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!

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

@kccqzy yes.

pid_eins,
@pid_eins@mastodon.social avatar

@shoragan ssh over rs232, eh?

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