Season of Docs - What could be done

[Lukas à Porta]

Hello everyone,

I have been selected to write documentation for Qubes OS during the Season of Docs. I am glad to have opportunity to contribute to this project.

During my time as a technical writer for Qubes OS, I intend to work on creating a guide for firstboot users, among other things (please have a look here for other ideas submitted by the Qubes OS team.)

The community bonding phase will last until beginning of September. After that, I will start to work on creating documentation. During the community bonding phase, I intend to do the following :

• Review other Season of Docs projects submitted by technical writers
• There are great projects over there. I intend to get ideas and inspiration from them.
• Review current QubesOS documentation
• There is already quite a bit of documentation : I don't intend to reinvent the wheel. I will try to spot gaps and areas in need of improvement.
  
• Review current user and devel Qubes OS lists.
• Is there any pattern appearing ? What is causing the most headache amongst users ?
• Ask the community what they would like to see improved
• You know it better than I do :)
  
• Find a stable configuration under KVM
• Aside from my laptop, I am using KVM to virtualize Qubes OS (although it would be neat to try to virtualize Qubes OS within Qubes OS). It will help me to document the early steps of the installation process and experiment (= do stupid things you shouldn't do on a production system).
  
• [DONE] Review GitHub issues related to documentation
• I will write a summary and share it with you
  
• Submit my first PR
  

A few points of discussion

• Is there anything else you believe I should be doing during this phase (or shouldn't be doing)?
• What is the most up-to-date diagram of Qubes OS ?
• Should I set up a form and ask the community what they would like to see improved ?
• Is there a place Qubes technical specifications can be found ? (ASLR; Spectre mitigation ; Kernel hardening ; and so forth)
• Would it be nice to have comparaison between Qubes OS and other operating systems ? (Like Windows; ChromeOS ; Ubuntu ; Tails ; Genode; Subgraph; Alpine; and so forth)
• Would it make sense to try to make a comparaison between AppVMs, lxc and docker containers, snaps, solaris jails, etc ?

[Steve Coleman]

On 8/15/19 10:22 AM, Lukas à Porta wrote:
> Hello everyone,
> I have been selected to write documentation for Qubes OS during the

> Season of Docs <https://developers.google.com/season-of-docs/>. I am

> glad to have opportunity to contribute to this project.
> During my time as a technical writer for Qubes OS, I intend to work on
> creating a guide for firstboot users

First, I would like to thank you for even taking on this monumental
challenge. Qubes is a hugely complex system, with lots of technical
knowledge required just to get started. Anything that you can do to
lower the bar of entry into Qubes is truly worthy of my admiration.

One area I feel that needs improvement, and admittedly is probably out
of scope for your current project, is to simplify what one needs for the
proper hardware selection and/or testing of a usable machine. The HCL
page itself has grown fairly large while most of the entries found there
are not even relevant to a new user. This is because that user will
likely only be trying to install the latest (R4.x) baseline release. The
historical information on that page just makes it that much harder to
see what systems are actually known to work with R4.x. Few of the R4.x
entries are even green all the way across, and of those that are, they
will likely need to be purchased second hand with exception of some
current laptops. The fully functioning R4.x desktop systems are clearly
under-reported, and as of the last time I checked all of them were
discontinued models.

All the other historical 2.x/3.x entries are just clutter to a new user
and make the overall process much more intimidating than it needs to be.
A shorter and more consolidated list of systems working with just the
*latest* baseline (R4.x) would make it much easier to grok the
possibilities. My suggestion would be to either have the HCL main page
display only the current systems on the current baseline, with a
historical link for those who wish to see that older information. Or to
have an active web page filter based on selectable system attributes
(laptop, desktop, system board, Qubes version, max memory, tpm, CPU,
chipset, video controller) so you can skip what is not important for the
current baseline or even the users own requirements. Even being able to
download a CSV file so you can manually filter out everything without
R4.x would be an improvement.

In a perfect world, one would be able to just go to the HCL page, click
a link, and download and burn to a USB/DVD, a live system test image
that will boot and non-destructively test a physical machine for
properly functioning hardware. Upon passing that first-pass hardware
test, the user could then be able to click a link to directly submit
that first-pass HCL report for that particular hardware configuration.
Even if that system fails the test, that might still be valid
information, providing that it is not due to some BIOS settings causing
the problem. Armed with that live USB/DVD image, even a novice could
literally run around and boot any and all available machines and get a
first-pass check to see if the proper hardware and BIOS is installed and
functional before ever wiping a machine. Nobody wants to buy and wipe an
expensive machine only to find out that Qubes will not even work on it.
If that newly purchased machine fails to boot Qubes, good luck at ever
returning that machine after having wiped the system disk.

That hardware issue is a major barrier to entry for Qubes. Granted that
first-pass hardware check could not *guarantee* that _all_ functionality
is present, such as the sleep/wake-up or internal peripherals will all
work properly, but you could at least be reasonably sure that the core
hardware and video will function before taking that major step of wiping
that machine. But this way, one could reasonably think to walk into a
showroom of machines, or even borrow a friends machine, and
non-destructively test it to see if that model machine is risk-worthy
enough to buy or not. Identifying what not to buy is equally important
information, and a list of non-working hardware to steer clear of, or
require significant work-arounds might be good to document.

Basically anything that helps the new user find suitable hardware and
just get started on this journey will be a big help to increase the
adoption rate of Qubes.

Thanks again for your dedication to Qubes!

Steve.

[Lukas à Porta]

Hello Steve,

Sorry for the late reply and thanks for your kind message and ideas ! I know that the task is not trivial, but I also know that I am not alone and can count on the support of many bright minds and users alike :)

Thanks for bringing up the topic of hardware compatibility. I will add it to the backlog (maybe make it a GitHub issue ?) and try to gauge the difficulty of solving this problem.

I agree that the page could be redesigned with some sort of sorting mechanism. Just like you, I believe that the working hardware is underreported. Focusing on R4.X alone would also be a good idea, as it will soon become the only supported system out there.

As of today, I am running Qubes OS with a recent kernel, 4.19. It seems to me that most x86 hardware released after 2015 and perhaps before 2019 is likely to work out of the box with Qubes OS (including with IOMMU or VT-d, thanks to the fact that virtually all Intel CPUs released after 2015 does now support it*), at least on the desktop side of things, but certainly not without a few quirks (the chipset might not be compatible or the BIOS might let the user activate the said feature.)

But let's focus on laptops, which appear to be the most popular kind of machine among Qubes OS users.

1. When it comes to hardware compatibility, how does supporting Qubes OS differ from supporting a regular Linux distribution with the same kernel version ? Is there any laptop that would work with Ubuntu 18.04 or Fedora 28 (assuming they share the same kernel version as Qubes OS) but not on Qubes OS ? In other words, is there anything that bars Qubes OS from benefiting from Linux embedded hardware drivers ?

Assuming that all laptops do in fact support IOMMU, which appears to be the most important security feature out there (because it fuels Qubes OS virtualization capabilities), then the problem becomes : on what Laptop can a Linux distro work correctly ? Unfortunately, the list of candidates may not be especially long. And I have not heard of someone maintaining such a list, although there are classes of laptops that are known to work well with Linux (some Dell models, which may be ordered with Linux pre-installed)

There is another question with the HCL list. Are we looking for simple hardware compatibility (making sure that the main functionnalities are working) or hardware recommandations (making sure that the user finds the most fitting machine for running Qubes OS, which may include things like Coreboot or a TPM, which are nice to have, but are arguably outside of Qubes OS scope. The two can of course coexist.

* I wonder if it's the case for entry level AMD CPU.

[Steve Coleman]

> I agree thatthe page <https://www.qubes-os.org/hcl/> could be redesigned

> with some sort of sorting mechanism. Just like you, I believe that the
> working hardware is underreported. Focusing on R4.X alone would also be
> a good idea, as it will soon become the only supported system out there.

Its best to focus energy on what is going to actually be used. Those
running 3.x likely already know what they are doing by this point. The
goal should be helping the new users get on board easily.

> As of today, I am running Qubes OS with a recent kernel, 4.19. It seems
> to me that most x86 hardware released after 2015 and perhaps before 2019
> is likely to work out of the box with Qubes OS (including with IOMMU or
> VT-d, thanks to the fact that virtually all Intel CPUs released after

> 2015 does now support it*), at least on /the desktop side of things/,

> but certainly not without a few quirks (the chipset might not be
> compatible or the BIOS might let the user activate the said feature.)

I think BIOS support is still an issue that requires an up to date HCL,
because even with the proper CPU and chipset, while a vendor site might
list all the good features in the machines technical specs, you are
still buying a cat-in-a-bag if the bios doesn't properly support that
hardware (e.g missing interrupt remapping, tpm support, funky UEFI
bios), or if certain internal hardware is unsupported or bonded to the
wrong internal bus (some WiFi/LTE implementations), etc.

A small section on what key words (brands/models of components) to steer
clear of would extreemly helpful when looking for a new system. Bad
systems never make it to the HCL, so knowing what systems failed to even
get to the HCL test phase is missing. There is no way to report
completely broken systems. Other key words like "NVIDIA Geforce" or
"Vendor-x UEFI" on the HCL page entries could link directly to a common
solutions page with the required fix for that particular troublesome
component.

> But let's focus on laptops, which appear to be the most popular kind of
> machine among Qubes OS users.

This was actually one of my gripes that I think I did not mention. There
are LOTS of laptops on the HCL list, and not one single current desktop
system that is fully functional for 4.x. Perhaps people with desktops
are just not engaged with security as much as the people with laptops
(mobile security is important). Maybe the HCL should be an option at
install time? There are also many "system boards" on the list, but
listed as desktops, not under the system boards.

When I was trying to upgrade my home system to 4.x, and was having
problems, I was wanting to upgrade my desktop machine to one that was
known to be fully supported, but there wasn't any on the list that I
could purchase new off the shelf. I gave up and later figured out how to
make what I already had work for me.

Ironically my requirements have changed and I am now also in the market
for a laptop, in addition to the desktop system. Ok, a docking station
might suffice if the laptop has 64GB RAM and TPM 2.0. Both systems are
going to be very pricey so making a mistake will cost some serious
money. I would rather know for a fact that iw works before buying either
system.

> There is another question with the HCL list. Are we looking for simple
> hardware compatibility (making sure that the main functionnalities are
> working) or hardware recommandations (making sure that the user finds
> the most fitting machine for running Qubes OS, which may include things
> like Coreboot or a TPM, which are nice to have, but are arguably outside
> of Qubes OS scope. The two can of course coexist.

I would like to see as many of these features tested in the HCL as
possible. One of my requirements was TPM 2.0 for some development I was
planning. At work I have been due to a technical refreash (new machine)
for years, but because I have no garuntee that the new machine will
actually work I would be shooting myself in the foot to try and upgrade.
Its a catch-22 until there are more "current" machines on the HCL that
are verified to work correctly. I can not afford any downtime.

> * I wonder if it's the case for entry level AMD CPU.

I'm open the AMD but I don't know much about choosing the right hardware.

thanks,

Steve

[Lukas à Porta]

On Wednesday, August 21, 2019 at 11:53:35 PM UTC+2, Steve Coleman wrote:

> Hello Steve,
>
> Sorry for the late reply and thanks for your kind message and ideas ! I
> know that the task is not trivial, but I also know that I am not alone
> and can count on the support of many bright minds and users alike :)
>
> Thanks for bringing up the topic of hardware compatibility. I will add
> it to the backlog (maybe make it a GitHub issue ?) and try to gauge the
> difficulty of solving this problem.
>
> I agree thatthe page <https://www.qubes-os.org/hcl/> could be redesigned
> with some sort of sorting mechanism. Just like you, I believe that the
> working hardware is underreported. Focusing on R4.X alone would also be
> a good idea, as it will soon become the only supported system out there.

It's best to focus energy on what is going to actually be used. Those

running 3.x likely already know what they are doing by this point. The
goal should be helping the new users get on board easily.

> As of today, I am running Qubes OS with a recent kernel, 4.19. It seems
> to me that most x86 hardware released after 2015 and perhaps before 2019
> is likely to work out of the box with Qubes OS (including with IOMMU or
> VT-d, thanks to the fact that virtually all Intel CPUs released after
> 2015 does now support it*), at least on /the desktop side of things/,
> but certainly not without a few quirks (the chipset might not be
> compatible or the BIOS might let the user activate the said feature.)

I think BIOS support is still an issue that requires an up to date HCL,
because even with the proper CPU and chipset, while a vendor site might
list all the good features in the machines technical specs, you are
still buying a cat-in-a-bag if the bios doesn't properly support that
hardware (e.g missing interrupt remapping, tpm support, funky UEFI
bios), or if certain internal hardware is unsupported or bonded to the
wrong internal bus (some WiFi/LTE implementations), etc.

 

Unfortunately I believe that one won't be able get that kind of information before actually buying a machine. The problem seems similar to those that are looking for a machine that fully supports PCI-passthrough. IOMMU groups must be well isolated otherwise it is impossible to passthrough only a single device (say the GPU without the network card) without applying the so-called ACS override patch. With recent chipsets, the problem seems less frequent though (https://passthroughpo.st/vfio-compatibility-survey-early-insights/ & https://passthroughpo.st/tpp-hardware-survey-results-now-available/). More generally, manufacturers don't make this information easily accessible to the public, even in their "technical" manuals.

Coreboot, which may arguably solve some of the problems, is not well supported on the desktop or even server side (unless you are working at Google, whose servers' motherboards extensively rely on Coreboot). Bottom-line : Qubes OS cannot solve what motherboard manufactures haven't deemed worthy to provide to their users : to provide a decent motherboard with a battle-tested firmware and ECC-memory support, etc. SOS call : mere-mortals need open compute too... (maybe one day we will able to buy simple motherboards : are we really demanding something out of proportion here ?)

 

A small section on what key words (brands/models of components) to steer
clear of would extreemly helpful when looking for a new system. Bad
systems never make it to the HCL, so knowing what systems failed to even
get to the HCL test phase is missing. There is no way to report
completely broken systems. Other key words like "NVIDIA Geforce" or
"Vendor-x UEFI" on the HCL page entries could link directly to a common
solutions page with the required fix for that particular troublesome
component.

Sounds like a good idea to me !

 

> But let's focus on laptops, which appear to be the most popular kind of
> machine among Qubes OS users.

This was actually one of my gripes that I don't think I mentioned. There

are LOTS of laptops on the HCL list, and not one single current desktop
system that is fully functional for 4.x. Perhaps people with desktops

are just not engaged with security as much as those with laptops

(mobile security is important). Maybe the HCL should be an option at
install time? There are also many "system boards" on the list, but
listed as desktops, not under the system boards.

I like the option at the install, a bit like Debian is doing with their software survey, although in the case of Qubes OS it seems that users, for security purposes, won't like to disclose that information unless they can't be used to single-out a user or (as of now, I am not sure : to report a machine, you have to send an email and it seems that hardware identifiers might be present unless you don't send out a specific file. It would be nice to streamline the process and make it opt-in and anonymous by default). Also, one may not know if it will actually work well after the installation is done.

When I was trying to upgrade my home system to 4.x, and was having
problems, I was wanting to upgrade my desktop machine to one that was
known to be fully supported, but there wasn't any on the list that I
could purchase new off the shelf. I gave up and later figured out how to
make what I already had work for me.

Ironically my requirements have changed and I am now also in the market
for a laptop, in addition to the desktop system. Ok, a docking station
might suffice if the laptop has 64GB RAM and TPM 2.0. Both systems are
going to be very pricey so making a mistake will cost some serious
money. I would rather know for a fact that iw works before buying either
system.

On the desktop side, a good enough candidate for your need and Qubes OS in general might be Intel® NUC Kit NUC7i7DNHE and other NUC related Intel computers (and believe me, with the Intel ME and other hardware vulnerabilities, It pains me to recommend Intel...). Some users have reported them to be working with Qubes OS and the aforementioned model has TPM 2.0 and a Quad-core CPU (it is pricey too, 500 to 600 dollars bare-metal, but you can save 200 hundred dollars if you go dual-core). I haven't checked if this specific model does in fact support 64Gb of RAM but a at least a few (if not all) of NUC's models actually do (although they don't seem to be advertising it). I don't know what the state of NVMe support is for Qubes OS. And if it actually doesn't not work completely, you may repurpose this machine to host a proxmox hypervisor for instance (which I am doing with an older model).

Anyway, when you look for hardware for Qubes OS, I strongly recommend you not to buy the entire machine and components at the same time but only what is needed to boot it. Use a spare SSD and possibly a few DRAM4 DIMMs (like 2 x 2GB), and check if it does in fact work before committing yourself too much.

> There is another question with the HCL list. Are we looking for simple
> hardware compatibility (making sure that the main functionnalities are
> working) or hardware recommandations (making sure that the user finds
> the most fitting machine for running Qubes OS, which may include things
> like Coreboot or a TPM, which are nice to have, but are arguably outside
> of Qubes OS scope. The two can of course coexist.

I would like to see as many of these features tested in the HCL as
possible. One of my requirements was TPM 2.0 for some development I was
planning. At work I have been due to a technical refreash (new machine)
for years, but because I have no garuntee that the new machine will
actually work I would be shooting myself in the foot to try and upgrade.
Its a catch-22 until there are more "current" machines on the HCL that
are verified to work correctly. I can not afford any downtime.

> * I wonder if it's the case for entry level AMD CPU.

I'm open the AMD but I don't know much about choosing the right hardware.

Likewise...

 

thanks,

Steve

 

Thank you too !

Lukas

[Steve Coleman]

On 8/25/19 6:22 AM, Lukas à Porta wrote:
>
>
> On Wednesday, August 21, 2019 at 11:53:35 PM UTC+2, Steve Coleman wrote:


> Coreboot, which may arguably solve some of the problems, is not well
> supported on the desktop or even server side (unless you are working at
> Google, whose servers' motherboards extensively rely on Coreboot).

Speaking of coreboot:

"NSA researcher plans to allow everyone to guard against firmware attacks"
https://www.cyberscoop.com/nsa-firmware-open-source-coreboot-stm-pe-eugene-myers/
Yet another reason to favor coreboot capable system over a
non-corebootable system. I need to go back and revisit their supported
hardware list.


On another note, I came across this project when researching AMT a while
back:
https://github.com/intel/INTEL-SA-00075-Linux-Detection-And-Mitigation-Tools

The vulnerability check code might be a good-to-know attribute for the
HCL test page for those people that really care about this but are not
able to go as far as to install coreboot. This code is GPL'ed and has
source, so it should not be a big problem to engineer something for the
pre/post install diagnostics (see comment below). What I am not clear on
is whether the Qubes installer would need MEI kernel support compiled in
to do this "AMT test", as I think kernel support is only required for
the actual de-provisioning of AMT.

> A small section on what key words (brands/models of components) to
> steer
> clear of would extreemly helpful when looking for a new system. Bad
> systems never make it to the HCL, so knowing what systems failed to
> even
> get to the HCL test phase is missing. There is no way to report
> completely broken systems. Other key words like "NVIDIA Geforce" or
> "Vendor-x UEFI" on the HCL page entries could link directly to a common
> solutions page with the required fix for that particular troublesome
> component.
>
>
> Sounds like a good idea to me !

:)

> I like the option at the install, a bit like Debian is doing with their
> software survey, although in the case of Qubes OS it seems that users,
> for security purposes, won't like to disclose that information unless
> they can't be used to single-out a user or (as of now, I am not sure :
> to report a machine, you have to send an email and it seems that
> hardware identifiers might be present

> <https://www.qubes-os.org/doc/hcl/#generating-and-submitting-new-reports> unless

> you don't send out a specific file. It would be nice to streamline the
> process and make it opt-in and anonymous by default). Also, one may not
> know if it will actually work well after the installation is done.

May I make a suggestion on how to accomplish this? First, we need to
break down the HCL submission process into phases, base on user opt-in
during install, with the third phase being completely optional,
depending on how much information the user would be willing to share
with the community.

Phase-1: During pre-install, *if* there is a network connection, and we
have permission, we can enumerate the attached hardware, bios version,
etc, and generate a minimalist HCL report of that hardware baseline. If
the user checks an opt-in checkbox they could submit this preliminary
report anonymously before the install even takes place. This initial
report would include a cryptographic hash value of their detected
hardware/bios data as a temporary 'key' reference. The only publicly
identifying information available at this point would likley be the IP
address that the report is being submitted from, so the installer
program merely promises the the user that the Qubes HCL service will not
retain the IP address and it will not be archived along with that
report, thus assuring them of their complete anonymity. The pre-install
environment should not generally have any user specific information and
the user could even be permitted to review this baseline information
before its submission. If they opted-in, a connection to an HCL web
service will upload/push the initial yml report including this generated
hash value. On the receiving side the hash is recalculated from the
submitted data, and if it is cryptographically correct the document is
stored for later reference. This phase-1 information is not to be made
visible to the public but rather is just stored for later processing.

Phase-2: If they opted in during phase-1, and after a successful Qubes
install, a full HCL report is then be generated along with with the same
hardware baseline info and hash value, and again based on the users
opt-in this update is pushed to the HCL service. The hash value is then
used to pair the two (Phase1/Phase2) reports and thus it associates with
the same base record for that specific hardware combination. At this
point the HCL service can assign a unique system HCL-UUID for that
specific system configuration and that HCL-UUID will be used to allow
updating that specific record anytime in the future regardless of any
addition or deletion of hardware on the system. At that point this HCL
record still contains absolutely no user identifiable information. But
the new installed Qubes system also retains the unique HCL-UUID to
permit any future updates if they choose to do so in an optional Phase-3
submission. If there was no network connection during Phase-1 then this
information can still be submitted to receive the system HCL-UUID at
this time. Absence of a phase-1 report is also not treated as an error,
but since the system installed successfully and is now functioning that
report would not be interesting anyway.

The basic premise here is that, if you only receive the first HCL
report, and not the second, then that hardware was not likley capable of
running a Qubes system. A single instance of failure is not necessarily
"proof" that the hardware can not run qubes, but with multiple
submissions of similar equipment components (the hash) that increases
the confidence level that some component is indeed a Qubes show stopper.
Multiple submissions with the same hash value just means the user is
persistent in trying to install qubes. When they come asking for support
on the qubes-user list this detailed hardware information might actually
come in handy by the qubes team to make sense of why they are having
problems and be able to tell them quickly what to try.

If you do receive the second report in Phase-2 then the system is
clearly capable of running as a basic Qubes system. How well it runs
Qubes is still open to discussion because of all the non-testable
attributes of the system that the installer has no good way to test.
These extended attributes can be user provided in Phase-3. In fact an
update to the HCL program itself could start collecting new information
for older systems for those that wish to participate.

Phase-3: (optional) If the user later wants to update any untestable
attributes like the TPM, or add specific install notes or work around's
then that is just icing on the cake. Given the assigned system HCL-UUID
the user can always resubmit the system's updated HCL by manually adding
this notes, how-to, etc and push it back. Upon adding/changing hardware
which would have changed the original hash value, the HCL-UUID will
still associate to the same configuration on file. The 'who' information
would only be available on the HCL list if the user agrees to submit
this update while providing their full contact information, otherwise
the entries on the HCL list stay completely anonymous.

The HCL is much more likely to collect a complete set of system
information if the owner is permitted to do so while being completely
anonymous, and thus not resorting to the use of email for its report
submission process is a big plus. This optional third step is
potentially where all the FIXME's, 'TPM X.y supported', and 'AEM works
great' all get updated to fill in the missing bits of optional
information or add critical working notes. Because of the assigned
HCL-UUID the user can always update their anonymous record without
giving themselves away. If they loose their systems HCL-UUID, or
deliberately delete it off their system, then they will sever their
ability to update their own systems HCL record and give them plausible
deniability if they desire that. Since there is no information in the
report/server side pointing back at them. The system owners contact
information would only be part of the final HCL report if they
voluntarily add that information so that they can be contacted by the
community for questions. The best part is that the HCL records can be
updated by the owner with some future quirk or work-around that was not
known or even exercised during installation.

Processing of failed installations:

Periodically the entirety of the 'Phase-1 only' collected reports can be
data-mined to build correlations needed to determine what similar
attributes lead to most failures during the install process. With the
sufficient level of confidence that failure information can then be
promoted and added to the HCL 'steer clear of attribute X or Company Y'
on the main HCL compatibility page and listed with its ranked confidence
level. Its merely a suggestion to 'stay away' if you are buying a new
system. Those people with older system can feel free or even encouraged
to try it anyway, and that may just boost the confidence level even
further to confirm the component/bios/system failure.

If later any system with that same component is seen to correctly
install Qubes then that component should be downgraded in confidence or
removed entirely from the 'steer clear of' list. The basic idea is to
automatically calculate this level of confidence for any hardware
show-stoppers that are _never_ seen in any successful Phase-2 reports.
When some are successful and others not, that is where the confidence
level comes into play so that the user can rate the risk in buying a
particular system containing that component or not.

> On the desktop side, a good enough candidate for your need and Qubes OS
> in general might be Intel® NUC Kit NUC7i7DNHE

> <https://ark.intel.com/content/www/us/en/ark/products/130393/intel-nuc-kit-nuc7i7dnhe.html>and

Its 32GB with one SSD available for a possible RAID configuration, but
it should allow for an external USB RAID setup at a cost to some IO
bandwidth. I'm not sure about the logic or usefulness of putting a RAID
system on a single SSD device like they suggest. Overall it may be
workable, but not optimal for my desktop system needs.

I was generally looking for something more beefy with lots of empty bays
for adding double digit terabytes of internal disk space to host my many
diverse research interests (CompSci, security, RE, AI, Medical, Physics
modeling, and future theoretical physics simulations). I may be retiring
in the next year or two so this may very well be my last 'big system'
and this one will also need to last me for quite a while, I hope.

> Anyway, when you look for hardware for Qubes OS, I strongly recommend
> you not to buy the entire machine and components at the same time but
> only what is needed to boot it. Use a spare SSD and possibly a few DRAM4
> DIMMs (like 2 x 2GB), and check if it does in fact work before
> committing yourself too much.

Yes, that is sort of the mode I am in at the moment. To buy what is
upgradable enough to meet my base requirements, and grow it from there.
Unfortunately for a desktop system I sill need to buy a cat-in-a-bag to
get there. I still have time so I will continue watching the HCL for any
new, fully functional, and most importantly 'purchasable' desktop
systems to show up. But I'm not going to hold my breath.

As for laptops the Lenovo P51 isn't looking too bad (64GB), but I still
don't know what internal USB controllers might be usable/assignable for
a sys-usb and to work USB attached hardware in a docking station
configuration. If I give up on an internal RAID I can probably just use
my network RAID for off line storage, and mount what I need when I am in
my home office.


Steve