What C++26 disapproval vote tells is that C++ is a funtional language ecosystem where language features don't appear like mushrooms after the rain :-) I.e., it is a language that does not require dep-a-bot.

The integer ceiling (e.g. to GiB's) of RAM + sqrt(RAM) was what you needed for hibernate, wasn't it?

Puu OS installer will not have a field for swap size or possibility to self-create swap partitions because I don't see no point. There's a check box for hibernate and based on that either a swap partition will be created or ZRAM will be configured. Both are capped to the size given by the formula above because it decouples swap size from the option, and leaves room for pivoting, if there is ever need.

It's always nice when different areas of my work cross paths, and this time it happens with the installer for Puu OS, which is my operating system for LLM inference appliances 🙂

With the Puu OS installer v1.1 release, which I will publish soon, the installer is no longer included in the live image. Instead, it will be turned into a precompiled AppImage with binaries distributed from NPM, and can be run simply with "npx @puu/installer".

The installer has been fully decoupled from Puu OS with a single YAML file describing the installation, including the branding and other hard-coded assumptions. The Puu OS installer has also gained optional hibernate and swap partition support for the installation.

The work began a few weeks ago when Matthew Garrett sent kernel patches for review enabling hibernate support for secure boot and lockdown; a limitation which has kept hibernate out of the product space for a multi-decade period of time [2]. Without going into further detail, the patches are based on the use of the TPM PCR 5 register as the security anchor.

Matthew's patches have also caused some refinement of my Linux kernel test harness so that it builds a bootc container and a live image, which can then in turn be installed using the Puu OS installer [1]. It is complicated, but at the same time the simplest thing possible for verifying hibernate, given how complicated a feature it is.

I'm promoting this because some might have missed that the beef here is that when these have been merged, it will be possible to use hibernate at all in product creation. And it could even be that Linux is the first major OS to re-enable hibernate. This should really gain more interest than it does right now:

https://lore.kernel.org/linux-integrity/20261008132532.1155166-1-matthewg@nvidia.com/

The comments I've made so far (please don't read them) are not too great, but that will be addressed as soon as I'm running the thing :-)

#linux #kernel #hibernate @mjg59

Great dns_resolver and AF_RXRPC circular dependency issues sorted out that were blocking my patch set, which migrate key types to use the kernel module binding 🥳

David had a patch for RXRCP that does the split and based on that I rewrote the changes for dns_resolver, which now has a submodule dns_resolver_key.ko

#linux #kernel #keyring

Maybe unorthodox and I don't know if it is possible but I'd like most if I could take Time Machine storage format compatible system backups from Linux machines.

My bet is that AI regulation, when it concerns copyright, trademarks etc., will be initiated from Washington DC. There is probably already lobbyists from Disney, Nintendo and many other companies preparing for the post-Trump era.

**** ***! 😠

https://www.ign.com/articles/openai-ceo-sam-altman-thinks-its-terrible-for-you-to-have-ram-in-your-gaming-pc

I’m working on getting key_type_dead wiped off from Linux.

This changes behavior from rmmod always succeeding into returning -EBUSY if callers have the LKM pinned, which is what any normal LKM does.

So while this would be so much better it might require tweaks to the user space. I have no idea. I will test the changes with SystemD at least, which I already have as part of my regular kernel test image.

This will be bundled into keyring GC sanitization patch set that I’ll send later today. It also includes a patch that amortizes work items into 64 key chunks in order to resolve workqueue lockups (with only ~2% added to the time taken by serial tree traversal).

EDIT:

v2: https://lore.kernel.org/keyrings/20261103030226.2685251-1-jarkko@kernel.org/

#linux #keyring #systemd @pid_eins

Signal is more secure than Protonmail than any of the similar services.

I don't understand the concept of secure email. If you want it secure, use PGP 🤷 Otherwise, it is insecure.

If (which is a long stretch) a government wants to spy on you, they don't have to target your inbox. They target SMTP nodes, root routers or other infrastructure assets. It's more transparent, trivial and invisible. If I send an email without encryption, I send it with an assumption that anyone could read this.

#email #infosec

93% drop in the variance of the time spent on a single keyring_garbage_collector() call with only 2.2% increase in the total time spent on processing the full serial tree 🥳

The serial tree is now processed in 64 keys per invocation chunks instead doing the full traversal at once. The combined average time on my laptop's CPU (== shitty Zen 2) is 0.154 ms per chunk.

I guess this should put an end to the reoccuring theme of workqueue lockups (and LLM bug fixes that come along with it).

https://lore.kernel.org/keyrings/20261029172918.2118600-1-jarkko@kernel.org/

#linux #kernel #keyring #ebpf #bpf

I made a new benchmark: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd-test.git/tree/package/keygcbench

Other than AI slop appearing in the Asustor's ADM, their security is broken too.

Or at least the password dictionary attack block is not exactly working :-)

#infosec #asustor

Probably in most countries once few years pass by, slop is the standard of public IT services. What is cheapest wins despite the quality.

In private sector the market balances its use.

I can feel that I'm somehow "back" with actual focus into kernel for the first time this year.

And I only noticed it now when looking back. During the course of the Spring there was a period when the shit happening around was so crazy that it really put some weight on my mental capacities at least.

I think it was a smart decision to remove "Assisted-by" tag because it actually encourages for patch spamming, and everyone in the field knows this. We know how to dig out the dirt ourselves and removal of that tag actually underlines the responsibility of an invidiual contributor more than anything else.

Me vs Sashiko 4-1

Sent a kernel patch: "KEYS: key_garbage_collector(): process in chunks"

https://lore.kernel.org/keyrings/20261027235820.2002072-1-jarkko@kernel.org/

At least I got two additional 4 TB WD drives for my NAS so hooray for RAID-5 / EXT-4 with four drives :-)

And f*** Amazon.

I have a fix already that can be formally said to actually fix this bug but I can't get over it before I have A/B test that is fairly reliable: https://syzkaller.appspot.com/bug?extid=c15de43f1e7fffbb7b9b

It's still cool to show with and without...

Landstrip 0.20.x was purposely a large feature pack and I've been fixing what broke down since. I thought that it is better to do one such major push and then just focus more on stabilization (up until one day there is 1.0). Have some patience please :-)

Up until 1.0 I neither call Landstrip as "secure" nor stable but 0.20.x changes definitely will eventually start to decrease the variance on both of these aspects.