Not true that 16GB DDR3 is only ECC - the Lenovo 03X7015 fits the bill.
Micron also had a module.
It’s rare, incredibly expensive new, but you will find it if you look.
Thanks. The lowest price for the lenovo one i see is $135 for one stick on ebay, haha.
I just installed Qubes 4.1.0 on a used Lenovo T430, no problems at all.
I did upgrade the RAM to 16gb (2x8). There’s also a youtube video shows how to replace the CPU with a faster one. I might try that some day.
I also bought one of those dvd-bay caddy where you can use the dvd drive bay to hold a ssd or hdd. Works great.
https://www.amazon.com/gp/product/B01MRI8YFN/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1
1 Like
Would you mind sending in an HCL report for it?
Does it match these criteria?
- Qubes OS installs without any workarounds
- Graphics, networking, audio & suspend work without troubleshooting
If so it could be the first machine to make it back on the list of community recommended computers.
Sure. Haven’t tried audio or suspend yet, but will do.
I would like to amend two of the criteria for inclusion:
- add “suspend” to “Graphics, networking & audio work without troubleshooting”
- allow a machine to be added with only one (1) community report IF it was previously already included on the list
The first is driven by discussions on this list, the later one by the desire to populate the R4.1 list without delay. I consider those common sense and move ahead assuming the community is fine with it. Should I be wrong, I volunteer to roll back my changes. … again, in the interest of time / speedy progress.
2 Likes
I have the exact opposite opinion. The list is about computers that work well with Qubes OS and are in use by the community. That includes the certified and developer tested machines. I see no reason to separate them from the list. I also don’t think it looks better or more structured – quite the opposite actually it adds complexity and visual noise.
I also think this point was already discussed multiple times in the past and my impression was the consensus to include those machines in the list.
However, that is just my opinion and this is a community project.
I share your view, that it was the consensus, and that it is the right thing to do.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
In light of QSB-081, should the inclusion criteria be expanded to require that the device’s CPU continues to receive microcode updates? Unfortunately, it looks like this would eliminate all but two of the recommended 4.1 models…
Related, more general discussion:
4 Likes
I understand the concerns about (the lack of) microcode updates, but have a few questions:
-
If we make the ability to receive microcode updates a requirement, why didn’t we make the ability to remove ME a requirement too? … funny enough that would leave us with exactly zero machines.
-
What about certified hardware?
At this point one pretty much has to choose:
-
(minimized) ME and microcode updates
-
no ME, no microcode updates
Maybe instead of a requirement, we can document the trade-offs and indicate in the table which category the machine belongs to?
1 Like
Because there is no evidence of active, widely available, serious exploits (at least without the AMT)? Because Intel supposedly only give the access to ME to NSA? (And if NSA is in your threat model, then you’ve got many more problems…)
I guess it should have a disclaimer, otherwise people might be deceived, thinking that it’s more secure than it actually is.
This might be an interesting read. Currently I don’t understand how to use a vulnerable machine, where any website could read all my passwords in RAM, including my HDD encryption password (if I understand the problem correctly). Never load any JavaScript?
Meanwhile, I guess more attention needs to go to this issue: Port Qubes to ppc64 [3 bitcoin bounty] · Issue #4318 · QubesOS/qubes-issues · GitHub.
Not an expert, but I may argue that probably yes.
Time to starting digging aroud SElinux in order to use it in HVM mode qubes (at least sys-net). Maybe grapheneos sys-net? Maybe i am digressing…
@fsflover it really doesn’t matter (to me) in the least that there is no published remote exploit for ME. When ME is present, there is an always on computer running proprietary code on my motherboard with full access to all hardware and completely transparent to any code running on the CPU.
QSB-081 starts: an adversary who controls a VM with an assigned PCI device can infer the memory content of other guests or Xen itself. So one would need to assign a PCI device to an HVM qube and then use it for web browsing to be vulnerable the way you indicated. If anything QSB-081 reinforces what should by now be a best practice among Qubes OS users due to the multitude of discovered and undiscovered side channel attacks on x86 CPU: when handling high value data, do so in an offline qube while all less trusted qubes are shutdown.
I fully agree with you that we desperately need a better computing platform for Qubes OS.
@qubicrm could you please explain why running an Android-based smartphone OS in sys-net would be an improvement? Or how SELinux would protect from QSB-081 or really any side-channel attack?
2 Likes
I don’t think you do understand the problem, although never loading
JavaScript is probably a Good Thing ™
The most recent QSB describes a situation where a compromised qube with
PCI may access data in RAM that pertains to Xen or some other qube. It
has nothing to do with websites leveraging JavaScript,( unless you
habitually browse from sys-net, which is probably a bad idea anyway).
Here is one way you could use a vulnerable machine to reduce the risk
somewhat.
-
sys-usb:
Disposable.
Only run when needed: shutdown when finished.
Shutdown sensitive qubes before starting sys-usb. -
sys-net:
Disposable.
Only run when needed: shutdown when finished.
Shutdown/pause when performing sensitive operations in other qubes, as
far as possible.
Consider moving all possible activities away from sys-net ( date/time,
updates, etc), and reduce profile as far as possible. -
General activities:
Perform sensitive operations offline. (E.g use of GPG)
Shutdown secure qubes when not in use.
There are some activities which require sys-net to be active: e.g.
email, ssh sessions. Restart sys-net before these activities to minimise
the risk of leakage and compromise. Shutdown sys-net as soon as
possible.
openssh protects private keys in RAM. Use split-ssh-agents.
Use split-gpg.
Encrypt data at rest.
Use qubes-shutdown-idle (with short time out) to make sure that qubes
close when not in active use.
Users may be doing some or all of this already.
I never presume to speak for the Qubes team.When I comment in the Forum or in the mailing lists I speak for myself.
8 Likes
At this point, microcode update seems like a euphemism, the reality is that it is (critical) security updates.
I don’t think QSB-081 is the end of the world, but how unsafe can a CPU get before it’s a disservice to recommend it?
For the latest QSB, you are of course right. Are all other vulnerabilities were fully fixed for all Community-recommended laptops?
So, no usb mouse should be used. I guess we should use MacBooks, otherwise the touchpad may not be good enough for a daily driver…
We do not disagree here. I dream of a truly free machine, too. However, a machine that can be hacked by anyone vs a machine that can be hacked by NSA is not a hard choice I would say. Latest QSB can be somewhat mitigated as @unman explained, but what about earlier Intel vulnerabilities?
-1 Asus X540LA for Qubes4.0, everything works. Upgrading to 4.1 worked too. But only Max. 8GB RAM.
-2 NH5x_NH7xHP works with Qubes4.1, impossible to install 4.0 on it. And kernel-latest needed in Qubes4.1 on NH5x_NH7xHP