Does the latest Linux kernel improve security for qubes?
fiftyfour...@gmail.com
dhorf-hfre...@hashmail.org
> Quick question: In terms of security, does it matter if I install and use
> the latest Linux kernel (5.4) or not?
> the potential instability, if there is any?
see the current 4.0.2 discard drama.
even a stable branch kernel can be a lemon.
make sure to always keep some back versions installed.
so the newest kernel doesnt work in some way?
just boot the one from last week, and file an issue report and/or complain
on mailinglist and/or irc.
> Also, is there a quick diagnostic tool to check if a new installation on a
> new laptop have all functions working? (like sound, SLAT, TPM, etc.)
if it doesnt like your hardware, it will tell you.
that covers at least slat(+iommu).
"sound" and "tpm" are simply a question of "is this supported by linux",
nothing qubes-specific about it.
tpm has the additional problem of ...
aeh, what do you want to use a tpm for anyways?
unless you have an actual usecase in mind, just ignore the tpm entirely.
fiftyfour...@gmail.com
Claudia
> On Sat, Jan 04, 2020 at 09:01:35AM -0800, fiftyfour...@gmail.com wrote:
>> Also, is there a quick diagnostic tool to check if a new installation on a
>> new laptop have all functions working? (like sound, SLAT, TPM, etc.)
qubes-hcl-report checks for the basics, like SLAT, TPM, VT-x, VT-d. Beyond that...
I sort of wondered about that too. However there's probably no way to fully automate it. E.g., most hardware can't resume itself from suspend, the user has to press a key. Same goes for things like external USB device detection, HDMI ports, ethernet ports, and so on - you have to physically connect it. And e.g. the code wouldn't know if audio is actually coming out of the speakers, even if it's writing to the sound card (see below for a real world example). Same goes for things like the screen brightness, framebuffer corruption, and so on. So at best, a diagnostic tool could only guide the user through the process, which would still be helpful but I don't know of any such tool, other than what qubes-hcl-report does.
https://www.qubes-os.org/doc/hcl/
> "sound" and "tpm" are simply a question of "is this supported by linux",
> nothing qubes-specific about it.
Well, for the most part, but there are some edge cases. For example in several versions of Qubes/Xen my sound card would show up, no errors, but would not play any sound other than some slight static. When I booted Qubes without Xen, sound worked fine. It turned out it was because the USB controllers are IOMMU-grouped with the sound card, so passing one without the other causes undefined behavior. I had to disable sys-usb and remove rd.qubes.hide_all_usb. Actually I just realized I never followed up on that thread with the actual solution.
https://www.mail-archive.com/qubes...@googlegroups.com/msg31105.html
fiftyfour...@gmail.com
However there's probably no way to fully automate it.
Claudia
It would be helpful, sure. I'd also even be interested in outputs like lspci, lsusb, dmesg, alsa-info.sh, /proc/cpuinfo, iommu_groups, xl demsg, pm_trace, and so on for different machines. But then again, most people are just going to test what they actually need and leave it at that. Probably only a small minority of Qubes users even submit an HCL report, and even a smaller fraction of them troubleshoot issues and update their reports. Fact is, testing and troubleshooting can take a lot of time, effort, expertise, and sometimes additional hardware. My HCL report for this machine is now almost six months in the making, all told.
The HCL doc mentions some of the basics like video, networking, and sleep. Also the remarks column of the HCL page is a great place to look for ideas. However, I'd say if you can suspend and resume in the middle of a youtube video without any noticeable problems, you've already hit all the features for 90% of use cases. And keep in mind you can always add to your report later.
fiftyfour...@gmail.com
My HCL report for this machine is now almost six months in the making, all told.
Claudia
It's not the HCL report that takes that long. When I first installed Qubes I had my initial HCL report done in a couple of minutes. It's all the troubleshooting, much of which is optional depending on your needs. I've been continuing to update my report as I fix things, which is why it's taking so long. Like you said, there's a lot of luck to it. I had pretty bad luck initially, although I've been able to fix a lot of the problems with time. In your case, for example, you may find that pretty much everything just works, and you can have a fairly complete report done in no time. And if something doesn't work, you can just put down "doesn't work," you don't have to fix it unless you need to or want to.
Of course, the more thoroughly you test the machine, the more time it will take. For example things like setting up AEM, flashing Coreboot, setting up LUKS to work with a USB keyboard, can be non-trivial even if you're successful on the first try. Even little things can add up: UEFI mode, secure boot, firmware updates, wifi, audio, bluetooth, touchscreen, keyboard backlight, HDMI video and audio, DisplayPort, USB passthru, USB 3.0 support, wired networking, SD card slot, screen power management, webcam and microphone, headphone jack, lid switch, multimedia keys, accelerated graphics, WWAN etc.
Like I said, if you suspend/resume with a youtube video playing, you've already tested all the most commonly used features. Also you don't have to test everything at once. You can always update your report later. On top of that, keep in mind everything is subject to change with every update you install.
My advice is don't worry too much, and don't let yourself get discouraged. Do what you can, and when you've had enough, just submit what you have so far and come back to it later.
fiftyfour...@gmail.com
Claudia
> Seems like you're taking the super-comprehensive route (including flashing Coreboot) on a
> low-compatibility machine. Maybe one day I'll have enough proficiency to really make a machine
I personally haven't gotten anywhere near that far with this machine, I was just giving you some general examples. I don't think it's even supported by Coreboot or AEM. You're right though, is definitely a low-compatibility machine. It's also a somewhat new model, so some of the hardware support hasn't necessarily made it to Qubes yet.
> mine.Out of curiousity, what model are you working on?
Inspiron 5575, AMD 2500U
> I'll give the Youtube Suspension Test a try once I connect my machine to the net. I'm one step away
> from that, but I'm stuck--I'm trying to follow the instructions on the Qubes site to randomize my
> MAC address, but the fedora-30 template seems to be locked with a password that isn't mine. From
> all that I've read (including Joanna's explanation in the sudoers folder), I'm not supposed to be
> prompted for a password, yet here I am.
>
> Don't want to make a thread for what could be a trivial Linux mistake that isn't specific to Qubes.
> Would you happen to know anything about this?
Hmm, that's odd. I would recommend starting a new thread. Include the terminal output you're seeing, or a screenshot, and what steps got you there.
fiftyfour...@gmail.com
Inspiron 5575, AMD 2500U
Hmm, that's odd. I would recommend starting a new thread.
Claudia
>> Inspiron 5575, AMD 2500U
>
> A newly-released machine with an AMD CPU and GPU? Are you a masochist or someone who's looking to
> perform feats of strength? (Like climbing Everest). Or is Intel really that unpalatable for you?
> From what I've read, AMD's PSP is much more opaque and questionable compared to Intel's ME. Is this
> true?
Now you understand why it's taken me this long! What can I say, I like doing things the hard way.
I went with it mainly for cost reasons. The 2500U is roughly equivalent to the i5-8250U performance-wise but seems to run about $200 cheaper. And at the time I thought Qubes compatibility was about the same for AMD and Intel, which may be true for most product lines but not for Ryzen apparently. I don't know much about PSP, or ME for that matter, but it seems to me you're mostly screwed either way, so I figured I might as well save some money while I'm at it. This was even before the recent Intel shit show. Plus, I got a really good deal on this particular machine (so admittedly a bit of an impulse buy). And I have to say, despite a lot of troubleshooting and a few remaining glitches, it actually runs Qubes surprisingly well, all things considered. But... yeah, kids, don't try this at home.
fiftyfour...@gmail.com
What can I say, I like doing things the hard way.
I don't know much about PSP, or ME for that matter, but it seems to me you're mostly screwed either way, so I figured I might as well save some money while I'm at it.
Claudia
>> What can I say, I like doing things the hard way.
>
> Some might say it's good for character building--like climbing Everest with minimal assistance when
> you can instead just hire a bunch of Sherpas to carry you.
>
>> I don't know much about PSP, or ME for that matter, but it seems to me you're mostly screwed either
>> way, so I figured I might as well save some money while I'm at it.
>
> Well, if the motivation is money then I think the amount of time someone with your level of
> knowledge has put into fixing the machine has gone way past $200 by now. I think you're in it for
> the journey.
Looking at it that way, you have a good point. I'm certainly no expert though. I've only been using Qubes about three years, and only tinkering with it less than a year at most. I've learned a *lot* in the last six months, and I still haven't even scratched the surface. I wouldn't have been able to do it without the help from the mailing list.
> I was going to say "why not an ARM computer" when I realised that a) there isn't a single non-Intel
> or AMD PC on the HCL, and b) ARM computers are hard to come by.
Non-Intel/AMD x86 machines suitable for Qubes are probably just as hard to come by, I would imagine. But besides the issue of trust/transparency with regards to AMD and Intel, I think much of the problem is also rooted in the design and cruft of the x86 architecture itself (read Joanna's "x86 Considered Harmful").
There has been some talk about porting Qubes to other architectures like ARM and POWER9, both historically and recently, but I haven't been following it at all and I don't know how realistic any of it is. For example: https://www.mail-archive.com/qubes...@googlegroups.com/msg31704.html
I seem to remember an FSF-approved ARM laptop made by some Chinese company with a funny name a long time ago that ran Debian or something. But yeah, I don't think ARM desktop/laptop computers are going to catch on any time soon. And from what I understand porting to ARM is a little more complicated due to lack of ACPI and all that stuff. Even if there were ARM options, I don't know if the Qubes development community could really handle it.
fiftyfour...@gmail.com
I'm certainly no expert though.
I wouldn't have been able to do it without the help from the mailing list.
I seem to remember an FSF-approved ARM laptop made by some Chinese company with a funny name a long time ago that ran Debian or something.
Even if there were ARM options, I don't know if the Qubes development community could really handle it.
Chris Laprise
> I don't know much about PSP, or ME for that matter, but it seems to me you're mostly screwed either way, so I figured I might as well save some money while I'm at it. This was even before the recent Intel shit show.
try to answer the question: Can they be properly deactivated?
Given everything else, its possible the answer is 'no' for Intel (we
already know this) and 'yes' for AMD.
> Plus, I got a really good deal on this particular machine (so admittedly a bit of an impulse buy). And I have to say, despite a lot of troubleshooting and a few remaining glitches, it actually runs Qubes surprisingly well, all things considered. But... yeah, kids, don't try this at home.
misconfigure advanced features like the IOMMU as the firmware isn't
carefully managed. Dell describes Inspiron models as "Home and Home Office".
The Lenovo G505s I have is also consumer grade and can't easily run
Qubes bc they stopped updating the firmware in 2015(!) and IOMMU is
present but won't work. Only thing that will fix this is flashing it
with Coreboot.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Claudia
> On 1/5/20 11:30 PM, Claudia wrote:
>
>> I don't know much about PSP, or ME for that matter, but it seems to me you're mostly screwed either
>> way, so I figured I might as well save some money while I'm at it. This was even before the recent
>> Intel shit show.
>
> Indeed. These management engines are ubiquitous, so I think we should
> try to answer the question: Can they be properly deactivated?
>
> Given everything else, its possible the answer is 'no' for Intel (we
> already know this) and 'yes' for AMD.
>
>> Plus, I got a really good deal on this particular machine (so admittedly a bit of an impulse buy).
>> And I have to say, despite a lot of troubleshooting and a few remaining glitches, it actually runs
>> Qubes surprisingly well, all things considered. But... yeah, kids, don't try this at home.
>
> I tend to shy away from 'consumer' models, bc they almost always
> misconfigure advanced features like the IOMMU as the firmware isn't
> carefully managed. Dell describes Inspiron models as "Home and Home Office".
On top of that, though, IOMMU problems and ACPI bugs and such appear to be widespread in the Ryzen family, across different computer makes and models, including higher-end ones and motherboards. I think there are some links about it in some of my other threads. That's what makes me think Ryzen itself has some problems of its own, or at least certain generations or something. Bad firmware can break good hardware, but good firmware can't fix bad hardware. Other AMD product lines though like Threadripper for example don't seem to be any worse than Intel from what I've heard. But like I said, it's really not that bad, all things considered -- I now have fully working suspend/resume which is more than a lot of Qubes users can say.
Chris Laprise
AMD Inspiron. Since I'm behind with the HCL list and you put so much
work into your report, I'll move yours to the top of my queue. It should
get listed sometime this week. Thanks for the detailed reporting!
Claudia
One correction I thought of: A lot of motherboards have three options for IOMMU: enabled, disabled, and auto (default). Changing it from auto to enabled sometimes makes the grouping more granular (but not always, and usually not by very much). A lot of consumer BIOSes, including mine, only has two modes: enabled and disabled, though I think my "enabled" is really just "auto". So that might be one aspect where firmware is to blame. It's hard to say, unless you can collect detailed information on a lot of different hardware. I'm just going by the vague and scattered reports that I've come across.
> That's good to know. I just noticed your long HCL update thread for the AMD Inspiron. Since I'm
> behind with the HCL list and you put so much work into your report, I'll move yours to the top of
> my queue. It should get listed sometime this week. Thanks for the detailed reporting!
No rush. I still have a few changes to make to the report itself, including the fix for suspend. I'll go over it again and post an updated copy. Do you prefer updates be posted in a new thread or the same thread? Also, some things like USB Qube are still a work in progress... or at least I haven't totally given up yet. A recent finding makes me think it could be a PCI reset problem. But that stuff can be updated again later if/when I have a fix for it.