[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

[Help Welcome] KVM Development - staying the course

KVM
#479

This is important.

Could you please re-read from here, follow all links? [Help Welcome] KVM Development - staying the course - #468 by Patrick

There has been a malicious / nonsense / trolling edit. These two:

It’s a breach of wiki review security. The impact is tiny. That edit should have never gone public. You shouldn’t have confirmed that edit. Should have been rejected. If not completely understood, please either ask and/or reject.

Also that edit is yet to be reverted.

Makes no sense to ask who made what edit as it can be seen in the wiki history. Link to wiki history:
Permission error - Whonix

#480

In the wiki history link https://www.whonix.org/w/index.php?title=KVM&action=history…

There every wiki version can be compared with every wiki version and it will show exactly what was changed (added text, removed text, edited text) as well as show which wiki account made the edit if any. Otherwise

Example wiki diff (these are easily accessible from the wiki history):
https://www.whonix.org/w/index.php?title=KVM&type=revision&diff=83136&oldid=82487

On that link…

Take special note to:

Top left, base revision to compare:

Revision as of 22:04, 9 March 2022 (edit) 127.0.0.1

Edit by 127.0.0.1 - localhost (because the server doesn’t store IPs). = anonymous edit, no wiki account.

Top right, target revision to compare:

Revision as of 07:47, 19 April 2022 (edit) (undo) HulaHoop

Contains your user name.

As for the first malicious wiki edit:

https://www.whonix.org/w/index.php?title=KVM&type=revision&diff=82455&oldid=82310)

Left top side, previous version by 127.0.0.1 (no wiki account, anonymous). (That’s just the last edit that was accepted. Not necessarily an issue.)

Right top side, changed version also by 127.0.0.1.

So 100% confirmed it was a anonymous edit.

1 Like
#481

Sometimes I make edits when I’m too lazy to sign in, that’s why I assumed that’s what happened here. Thought it was coming from a trusted source.There’s no excuse for this lapse though and it’s the first time I encounter this.

Keep or discard? Can this have security consequences?

1 Like
#482

Great that this is resolved now.

I guess the user who posted Initial setup Whonix-Gateway might have added this trying to be helpful.

Discard if not reproducible.

No security issue.

#483

Since the wiki has a chapter:
Why use KVM over VirtualBox?

It begs the question:
Why use KVM over Qubes?
Currently undocumented.

Other related new wiki chapters:

1 Like
Long Wiki Edits Thread
#484

Does Whonix KVM require VT-d?

1 Like
Error installing KVM on Debian 11
#485

No only VT-x. Only hardware passthrough like GPUs woudl need VT-d but this is unrecommneded for security reasons and virtio devices should be used whenever possible if high performance is needed.

2 Likes
#486

I thought for a long time VT-d was a required feature…

In qubes saying:

“required for effective isolation of network VMs”

Maybe they are talking about Xen design but not the same case in KVM?

#487

Qubes network VM = sys-net, which has a physical device(s) attached (LAN card and/or WiFi).

#488

Added VT-x vs VT-d to wiki:
Difference between revisions of "KVM" - Whonix

#489

invalid argument: could not find capabilities for domaintype=kvm is in the wiki to be documented under troubleshooting probably for ages but never had any content. Could you remove or document please?

Is above older / similar / same as the VT-X issue invalid argument: could not get preferred machine for /usr/bin/qemu-system-x86_64 type=kvm?

#490

For new KVM builds, temporarily, please note this Special Notice.

1 Like
#491

Not even Xen, this is a Qubes only hard requirement to enforce a design decision.

1 Like
#492

Yes seems like it. Both error messages should be merged under a common heading IMHO

1 Like
#493

Not a hard requirement, not enforced. As correctly quoted…

…“required for effective isolation of network VMs”. Hardware without IOMMU are still reported to run Qubes on the same website but these then don’t have “effective isolation of network VMs”.

Well, then if not having IOMMU, then don’t use Qubes because it then doesn’t have “effective isolation of network VMs”? No, that would also be wrong. No operating system would provide “effective isolation of network VMs” without IOMMU. So no Qubes specific disadvantage here either.

So yeah. Computer security. Complicated. Even a short and correct statement actually describing a feature/advantage (“with IOMMU you get effective isolation of network VMs”) with “required for effective isolation of network VMs” can be misunderstood in two negative ways which are false.

#494

Please do as you see fit.
If the older one doesn’t come up anymore, it could even be completely removed.
If users using older systems still run into it, might be useful to keep the error message inside the text.

#495

I stand corrected though in my defense, the last time I checked years ago when 4.X debuted, they implied that they won’t make exceptions for Vt-d-less hardware and reading the hardware reqs seems to imply this by listing this feature as a min req.

1 Like
#496

Please kindly subscribe here:

#497

Yes, the minimum system requirements implies this is a hard requirement. Created a Qubes documentation bug report for it just now:

1 Like
#498

IOMMU (VT-d) was a soft requirement until Qubes R4.0 but is a hard requirement since Qubes R4.1 as per:
https://github.com/QubesOS/qubes-issues/issues/7581#issuecomment-1160426503

Another ticket to clear up confusion created just now:

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]