GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Notices by Lennart Poettering (pid_eins@mastodon.social), page 2

  1. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 21-Aug-2025 11:22:20 JST Lennart Poettering Lennart Poettering

    4️⃣2️⃣ Here's the 42nd post highlighting key new features of the upcoming v258 release of systemd. #systemd258

    Part of the protocol spoken between service processes and the service manager (if it is systemd, that is) are a number of environment variables. Specifically, $MAINPID and $MANAGERPID are two variables that have been part of the protocol for a long time: they contain the PID numbers of the main service process and of the service manager itself.

    In conversation about 6 months ago from mastodon.social permalink
  2. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Wednesday, 13-Aug-2025 00:51:55 JST Lennart Poettering Lennart Poettering

    3️⃣6️⃣ Here's the 36th post highlighting key new features of the upcoming v258 release of systemd. #systemd258

    systemd tries to bridge the gap between being modular and flexibily supporting a wide range of systems and devices on one hand, and being somewhat quick and efficient to boot up on the other. These two goals are sometimes opposing forces: on many systems step X has to be done on boot, but each such step X costs dearly on other systems where X is not needed.

    In conversation about 6 months ago from mastodon.social permalink
  3. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Tuesday, 12-Aug-2025 16:09:39 JST Lennart Poettering Lennart Poettering

    3️⃣5️⃣ Here's the 35th post highlighting key new features of the upcoming v258 release of systemd. #systemd258

    In various stateless situations it makes sense to boot directly into a root file system that is downloaded as part of the boot process and placed into system RAM. With v258 there's now native support for this: a new rd.systemd.pull= kernel command line option may be used to download DDIs or tarballs into a tmpfs, optionally authenticate them, and then boot into them.

    In conversation about 6 months ago from mastodon.social permalink
  4. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Saturday, 12-Jul-2025 14:31:24 JST Lennart Poettering Lennart Poettering

    3️⃣1️⃣ Here's the 31st post highlighting key new features of the upcoming v258 release of systemd. #systemd258

    In v256 we added "systemd-ssh-generator", which – among other things – would bind sshd to an AF_VSOCK socket if that is supported on the system, i.e. if booted inside a VMM that supports AF_VSOCK communication. It greatly simplifies talking to a VM from the host, in environments that support this.

    Except of course, it's not quite as easy as it might appear conceptually:

    In conversation about 7 months ago from mastodon.social permalink
  5. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:52 JST Lennart Poettering Lennart Poettering
    in reply to
    • Klaus Frank
    • Timothée Ravier

    @agowa338 @siosm not sure what you are going on about, but the way the trust chain concept works on modern computers is that you boot up in a trusted state, and then chain everything else from there. Hence of course, you reboot to reset the state, to get your trust chain into a clean state again?

    Note that all of systemd's factory reset work actually runs from the initrd, i.e. under the assumption of an UKI world in a fully vendor signed part of the OS with only minimal input from elsewhere.

    In conversation about 8 months ago from gnusocial.jp permalink
  6. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:50 JST Lennart Poettering Lennart Poettering
    in reply to
    • Timothée Ravier

    @siosm you definitely need to reboot, to get back into an unbroken chain of trust. Now you have two ways to ensure this works. First of all you physically request the reset early during boot. That's why we have this in the boot menu. Or you ask for the reset from the compromised running system, and then use some form of attestation to validate that the reboot was genuine. The latter is stuff bigger deployments (i.e. companies which actually do attestation) can do, …

    In conversation about 8 months ago from gnusocial.jp permalink
  7. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:48 JST Lennart Poettering Lennart Poettering
    • Klaus Frank
    • Timothée Ravier

    @agowa338 @siosm sure, if you can afford to dump all hw on the trash and never use them again, if you have the suspicion that they got compromised, knock yourself out. Not cool for the environment, kinda wasteful, but whatever.

    I am pretty sure most people outside your bubble probably prefer a reasonable mechanism to maybe not waste all those resources, and get a clear and reasonably secure way to get the systems back to work.

    In conversation about 8 months ago from mastodon.social permalink
  8. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:47 JST Lennart Poettering Lennart Poettering
    in reply to
    • Klaus Frank
    • Timothée Ravier

    @agowa338 @siosm

    also, it's actually mostly fine to boot from a compromised disk as long as every resource involved is properly authenticated. Of course, the less you boot the better, but again when resetting the disks like this we do this from the initrd, i.e. from the signed, vendor-supplied UKI in a short-lived environment, not from the rootfs that might be user (and thus attacker) controlled.

    But I think ultimately we can just agree to disagree on the security model, no?

    In conversation about 8 months ago from gnusocial.jp permalink
  9. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:46 JST Lennart Poettering Lennart Poettering
    in reply to
    • Klaus Frank
    • Timothée Ravier

    @agowa338 @siosm

    we are dumping the *state* on the trash. But a signed UKI isn't precisely "state". It's firmware-authenticated immutable vendor code.

    But dunno, I think we should end this here. You have your security model, I have mine, let's just agree to disagree on it.

    In conversation about 8 months ago from gnusocial.jp permalink
  10. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:45 JST Lennart Poettering Lennart Poettering
    • bluca
    • Klaus Frank
    • Timothée Ravier

    @agowa338 @bluca @siosm you can store the UKI signing key on any pkcs11 device btw, i.e. a yubikey if you like. An attacker who takes over your system shouldn't be able to get to that, if you lock it with pin + fingerprint.

    In conversation about 8 months ago from mastodon.social permalink
  11. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:45 JST Lennart Poettering Lennart Poettering
    in reply to
    • Klaus Frank
    • Timothée Ravier

    @agowa338 @siosm sure if you make your UKI signing keys accessible to an attacker then of course there's no way to recover. Maybe don't do that then...

    In conversation about 8 months ago from gnusocial.jp permalink
  12. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:44 JST Lennart Poettering Lennart Poettering
    in reply to
    • Klaus Frank
    • Timothée Ravier

    @agowa338 @siosm if you compile your own kernels you are your own OS vendor. In that case you better take care of your signing keys.

    But this is not how most Linux distros or big installs are set up: they run kernels put together and signed on build systems, and those are distinct from the systems they are run on, and the signing keys are not available there.

    In conversation about 8 months ago from gnusocial.jp permalink
  13. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:23 JST Lennart Poettering Lennart Poettering

    1️⃣2️⃣ Here's the 12th post highlighting key new features of the upcoming v258 release of systemd. #systemd258

    I believe a fundamental aspect of OS security must be a secure way to return the OS into a well-defined, secure state if a compromise has been identified.

    Fending of an attacker is one thing, accepting that it might happen anyway and that you can recover from that in a reasonable way is another. And that's the case not only if you think about "cattle" style installs…

    In conversation about 8 months ago from mastodon.social permalink
  14. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:22 JST Lennart Poettering Lennart Poettering
    in reply to

    But only to some point. First of all "reinstalling your Linux" is not precisely a trivial operation, and secondly, in today's world it's actually not really going to suffice in many ways. That's because it's not sufficient to erase your HDD an reinitialize it. There's more state to reset. One of them in particular is the TPM: local key material is derived from or protected by a "seed" key stored on the TPM.

    In conversation about 8 months ago from mastodon.social permalink
  15. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:22 JST Lennart Poettering Lennart Poettering
    in reply to

    … (i.e. lots of similar systems running the same OS image), but equally on "pet" style installs (i.e. your personal device).

    Or to turn this around, a system that doesn't come with a clean, well defined mechanism to reset it fully, erase all unauthenticated data and return it to a vendor image without any local modifications, is highly problematic I believe.

    Now you might say: "I can always reinstall my Linux" and start from scratch. And to some point you are right even.

    In conversation about 8 months ago from mastodon.social permalink
  16. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:21 JST Lennart Poettering Lennart Poettering
    in reply to

    And once the system comes back again the system is fully reset.

    This currently does not cover EFI var NVRAM reset natively, but there's a clean plugin interface now to do that eventually (two actually: one place where you can plug in such code *before* we reboot, and one place *after* we reboot). [I'd expect that in one of the next releases we'll add another plugin for this, that erases certain EFI vars in NVRAM].

    In conversation about 8 months ago from mastodon.social permalink
  17. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:21 JST Lennart Poettering Lennart Poettering
    in reply to

    With v258 we considerably extended this work.There's now a well defined way to extend the factory reset logic so that other subsystems can be reset too. And we do ship one plugin for that (which is enabled by default), that requests a TPM reset from the firmware.

    If your OS is properly set up for that you can now issue "systemctl start factory-reset.target". This will initiate a reboot, but a special one, where first the firmware will reset the TPM, and then the OS will reset its own state.

    In conversation about 8 months ago from mastodon.social permalink
  18. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:21 JST Lennart Poettering Lennart Poettering
    in reply to

    If you do not invalidate the old seed key and generate a new one, then all secrets associated with the compromised install (and thus tainted) will remain valid.

    And there's more: there are various bits stored in EFI vars NVRAM that need to be reset too (shim keys for example).

    systemd for a longer time has had really nice support for resetting your HDD (i.e. securely erase partitions, via the systemd-repart FactoryReset= knob) if a factory reset is requested.

    In conversation about 8 months ago from mastodon.social permalink
  19. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:20 JST Lennart Poettering Lennart Poettering
    in reply to

    There's also now a Varlink based API to query the current factory reset state (i.e. is a factory reset pending for the next reboot, or are we currently executing one for the current boot, or did we already finish one for the current boot, or is none pending nor executing).

    If you want to learn more about the factory reset concepts in systemd, there is a new document for this:

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

    In conversation about 8 months ago from mastodon.social permalink
  20. Embed this notice
    Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:05:23 JST Lennart Poettering Lennart Poettering
    in reply to

    In v258 we updated this area substantially. There's now a Varlink IPC call to subscribe to all DNS configuration changes (io.systemd.Resolve.Monitor.SubscribeDNSConfiguration() on /run/systemd/resolve/io.systemd.Resolve.Monitor).

    If you issue this you'll get a stream of updates of the DNS configuration as they happen.

    Why is this useful? This is used by systemd-networkd-wait-online's new --dns switch. If specified it will not only wait until a suitable network interface with…

    In conversation about 8 months ago from mastodon.social permalink
  • After
  • Before

User actions

    Lennart Poettering

    Lennart Poettering

    ⛵ I write software. ⛵

    Tags
    • (None)

    Following 0

      Followers 0

        Groups 0

          Statistics

          User ID
          92094
          Member since
          26 Jan 2023
          Notices
          215
          Daily average
          0

          Feeds

          • Atom
          • Help
          • About
          • FAQ
          • TOS
          • Privacy
          • Source
          • Version
          • Contact

          GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

          Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.