Quick Quality-of-Life Improvements

It scattered all across the forum. and no slat scripts exist yet :slight_smile:

7 posts were split to a new topic: Notifications when dom0 or Xen memory is low

Couldn’t that be fixed with something like

xl list | grep sys-usb || qvm-start sys-usb

But I don’t know if that’s better or worse :slight_smile:

1 Like

I missed this post since it was hidden among all the posts about notifications

Maybe someone can run time xl list | grep sys-usb || qvm-start sys-usb vs the original code a couple of times?

Also, as @bearillo mentioned, Discourse is consistently dropping reply targets and it’s forcing me to quote.

x

I added a tip discovered by @renehoj in the CPU and Boot Time Survey thread.

Debian 12 only - [TemplateVM] Enter sudo cp /lib/systemd/system/systemd-binfmt.service /etc/systemd/system, then delete After=local-fs.target from /etc/systemd/system/systemd-binfmt.service

Let us know how much faster your boot time is before and after implementing by following instructions from that thread and entering your results. Note that data from VMs that have implemented this trick should have the “systemd-binfmt” modification.

If you are running your system with SMT enabled, you need to add the following lines to /etc/default/grub

GRUB_CMDLINE_XEN_DEFAULT="$GRUB_CMDLINE_XEN_DEFAULT smt=off"
GRUB_CMDLINE_XEN_DEFAULT="$GRUB_CMDLINE_XEN_DEFAULT smt=on"

It’s the only way to keep kernel updates from disabling smt, by automatically adding the smt=off line to the end of the file.

3 Likes

Is this for the systemd-binfmt tip or is it a whole new tip?

It’s not related to binfmt, it’s a tip for anyone running Xen with smt=on.

The Qubes OS update process will force disable smt if it doesn’t detect smt=off in grub, it’s just a way to trick the update process. Without it, you need to manually edit grub after each kernel update.

I’m on the fence about adding this as a tip.

  1. This should be part of a tip on how to turn SMT on, otherwise it just lacks context.

  2. Enabling SMT has potentially severe security implications, which is why SMT was disabled by the devs to begin with. While it’s hard to argue that increased performance is a niche desire, increased performance at the cost of security is a different matter. Tips with security implications, if allowed at all, must be marked with clear warning labels, but I fear that even when marked, just having the tip published might give the false perception that it’s less-risky.

Mods (@Deeplow @sven @gonzalo-bulnes , etc.), do you have any thoughts on the matter?

1 Like

Regarding publication of tips with clear security implications, I’ve no strong feelings either way. I think I’d default to saying that everything in the forum should be taken with caution, and that applying changes you don’t understand well is likely unwise. (:woman_shrugging:)

On whether this instamce is a tip in itself without the “how to enable SMT” context… I agree with your judgement:

Thay being said, I suspect that the trick works because the smt=off line is managed by Salt (educated guess), which has convenience functions that ensure a content is present in a file, in a way that adds it if missing and does nothing if present.

Leaving the line in the file and overriding it would work in any similar situation. So that may be a useful technique to know of.

Now, does it fit the category: “Quick Quality Improvements”? I’d say no. “Tips and tricks”? Maybe. :slightly_smiling_face:

2 Likes

Since the forum is almost entirely made up of
non-security researchers, non-developers and non-Xen experts I see no way to even begin assessing posts.

Also I don’t think it makes sense for the community to try to take user’s “at the hand”. Instead it should go like this:

If you have security concerns, use Qubes OS in its default congratulation without any modifications. Only follow instructions clearly published by the core team / official project. Expect each and every community post to be a malicious attempt to weaken your security.

If you are using Qubes OS as a hobby or to learn or you are sure you understand the implications of your configurations well enough to bet your security on it… by all means have at it.

4 Likes

Thank you mods for your input

I’ll take Sven’s suggestion and not do any hand-holding here–we can have tips that have security implications as long as they’re clearly labeled as such.

@renehoj Would you like to post a tip on how to turn off on SMT, which includes your grub modification?

1 Like

SMT is off by default

2 Likes

Typo; good catch

1 Like

Would be helpful to add Qubes version next to each tip.
Something like:
[Tested for 4.2]

Good guide.

1 Like

This is more of a “Fedora tip” than a “Qubes tip,” but it seems like a lot of people don’t know about dnf history, which is useful in dom0:

2 Likes

Good idea, but we’ll do the negative version of this to save words: Whenever a new release comes around, everything gets tagged with Untested for R4.X which get removed as tip creators/users report failure or success

Nice tip–added.

Then you’ll have to repeat it each time, for each new version.
Even more wording :slight_smile:

Good idea to leave the default line and override it! :+1:
I always add “sched-gran=core” with “smt=on”; it avoids running different VMs on the same core, mitigating some (potential) data leaks between different VMs.
So the last line would be:

GRUB_CMDLINE_XEN_DEFAULT="$GRUB_CMDLINE_XEN_DEFAULT smt=on sched-gran=core"