Greetings!

and thank you for qubes 4.0 which seems to be even better for every day usage 
than 3,2 :-). 

I am aware that usually, distributions are prudent to use latest kernels for 
some reasons, however, for an ultra security conscious project like qubes the 
trade off of not inszalling latest kernels is that you miss the security fixes 
they include.

 so it is already a great step forward for me that qubes 4 uses the latest 
„stable“ kernel 4.14, at this moment, even distributions that try to be 
bleeding edgr, like arch/manjaro offer 4.14 as current default kernel.

however, kernel 4.15 and 4.16 were specialy focussed on protection against 
spectre and meltdown, which are both a threat to the complete qubes concept, as 
they operate a level deeper (bios level/hardware level) than qubes, if i 
understand correctly. So wouldnt this special circumstance not justify to use 
the newsüest kernel 4.15 and 4.16 at least as an option? (btw, on my x220 
thinkpad, i was able to use 4.16 with manjaro withot problems, as it is also 
optimized for notebooks/better battery life, it seems to work even better than 
4.14 in every day life so far. however only worked with it for a few days so 
far).

i see that qubes indeed offers the possibility to use even newer kernels, so i 
tried this:
https://www.qubes-os.org/doc/managing-vm-kernel/

however, the information is not completly finetuned for qubes 4.0. e.g. in 
order to see aal kernels available, i needed
to issue
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable --action=list kernel*

from the result i got yesterday (tuesday, April 3rd 2018), that at the moment 
we have only kernel 4.15 as an option (i guess bevause 4.16 is so new, not even 
a week old, so i hope 4.16 will come as an option in the near future).

i was also able to download 4.15 kernel in dom0, following the instructions on 
the url given above.
(basically, using
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel-latest
i am not 100% sure about the kernel name in the last word of the aboce command 
line, i used the shortest name for 4.15 from the list output from the previous 
step).

however, i was not realy able to follow the instructions for the remaing steps 
in the articke, in order to actualy use the kernel in dom0 and/or the other 
vms, most probably due to my limited level of linux expertise. what i found is 
that some of the steps in the article were nit appropriate for qubes 4.0, e.g. 
installing qubes-kernel-vm-support grub2-tools in the fedora and/or debian 
vms/templates semms no mire necessary, because they are already included.

so, beside giving some hopefully helpfull hints, my message boils down to this 
question/request:

* what is the opionion of the qubes developers on kerbel 4.15 and 16? would 
they provide extra security for qubes users? or is everything they provide 
against spectre and meltdown either already included in qubes or not necessary 
when using qubes? (from the security advices, i get the impression that this 
might be the case at least for some aspects, but so far i found no information 
that gave me the security that indeed nothing from kernel 4.15 and/or 4.16 
could improve further the security of qubes)

in case that indeed security could be improved by usung kernel 4.15 or even 
4.16, i have these further questions/requests:
- couldnt you include an option or at least an updated documentation in the url 
above, so that „normal“ user can use this option safely/without problems (other 
than the possibility of breaking sonething due to the bleeding edge kernel)?

thank you and all the best
kai
http://kai.froeb.net

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4b579c8b-405d-4a59-9c10-e2a5af59b5c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to