[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    Re: [qubes-devel] Linux kernel security updates
From:       Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek () invisiblethingslab ! com>
Date:       2016-12-11 19:46:59
Message-ID: 20161211194659.GS16264 () mail-itl
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Dec 11, 2016 at 01:23:48PM -0500, Chris Laprise wrote:
> On 12/11/2016 03:16 AM, Andrew David Wong wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> > 
> > On 2016-12-10 19:23, Chris Laprise wrote:
> > > Given the increased interest in securing domU where possible, I'd
> > > like to know if Qubes Project will be making upstream security
> > > updates to the Linux kernel available to Qubes users on a timely,
> > > regular basis.
> > > 
> > > Kernel updates are an issue because users expect to update their
> > > templates to avoid security pitfalls--and most updates from
> > > upstream do come through without issue--but kernels are a different
> > > matter because they are maintained in Qubes dom0 repositories.
> > > 
> > > It seems like Qubes could use some improvement in this area, and
> > > I'd like to know what can be done to help it along.
> > > 
> > > Chris
> > > 
> > So, the problem is that kernel updates are only coming through after
> > a long delay? Have you been monitoring the delay? How long is it, on
> > average?
> 
> I haven't taken notice until recently. But it seems there was no recent
> update to kernel-qubes-vm from July until mid-November.
> 
> What piqued my interest was this bug filed in mid-October, and patched Nov.
> 30...
> 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8655
> 
> The build date for the most recent "current" kernel is Nov. 10. I would have
> hoped for an update for this, but I'm not seeing that happening. I'm not
> 100% clear if the lag is in Qubes Project or because of something I'm not
> aware of.

Mostly lack of resources for constantly testing (and fixing regressions)
in new kernel releases (see below).

> FWIW, I did install kernel 4.8.9 from unstable on Nov. 29, but looking at
> what's available in the repos I doubt this affected my system updates thus
> far.

There is also 4.8.12 in unstable repo.

> > How much work is required from the devs in order to make each kernel
> > available to users? Does it vary depending on the situation, or is it
> > a fairly routine matter each time? In other words, is the delay because
> > hard work needs to be done each time, or simply because it only happens
> > when the devs remember to do it, and they're usually busy with other
> > things?
> 
> One would hope that most of the work is being done upstream, and any
> Qubes/Xen specifics would only pose minor difficulties.

That would be the case in ideal world... In reality, besides just
bumping the version, it requires some testing, and often fixing
regressions ourself. The later is really unfortunate and mostly result
of using uncommon configuration in Qubes - for example PV backends in
non-dom0 (aka "driver domain"), using xenstore tools in domU, using
shared memory for various interfaces, etc.
For example there were regression between 4.4.16 and 4.4.17[1] making Qubes
VMs mostly useless (qrexec, gui agent and qubesdb didn't worked), fixed
only after 4.4.28 or so.

Or xen-netfront crash since 3.9.2[2], which I spend a lot of time
to debug (continued later on 4.4.x), but apparently no non-Qubes user is able to
reproduce it and also no one is interested in a patch I've provided.

Or regression somewhere between 4.4 and 4.8[3], also quite trivial to
reproduce on Qubes and apparently not happening elsewhere. This one
fortunately received some attention and was timely fixed after reporting.

This all results in a lot of frustration...

> > If it's the latter, we can set up a reminder system of some sort, or
> > we can appoint someone to be the "VM kernel manager" who submits a PR
> > for each new kernel update.
> > 
> > Realistically, what kind of improvement would you like to see? In other
> > words, what is the scenario that you would like to see become reality?
> 
> I would like to see a more concerted effort to forward security updates for
> the pv/domU kernels, as distributed by the upstream distro(s). This means
> more frequent updates to kernel-qubes-vm, at least in the security-testing
> repo but probably for current as well.

I think the ultimate solution should be to use distribution provided
kernel (using pvgrub). And this is what we want to have by default in
Qubes 4.0.

> (The user should also be able to find
> the 'parentage' of the kernels, i.e. 'this is a Fedora kernel from Nov. 30,
> 2016 with Qubes/Xen patches added'.)

This is easy to answer: it's vanilla kernel with few patches (mostly
backported fixes from newer versions). Details:
https://github.com/QubesOS/qubes-linux-kernel

> The reasoning for this is that domU updates are still more than a vehicle to
> install new programs; There is some expectation that timely security updates
> are important to these network- and risk-facing components.
> 
> This is something I would be interested in contributing time toward,
> although I'd want to discuss here further to be sure there actually is a gap
> to be filled and that I'm not just missing something on my end. I can also
> see such a role evolving to begin accommodating coldkernel betas in a
> user-selectable Qubes repo, if it turns out I could help in that respect.

Some help here would be really appreciated. Even just testing.

[1]
https://groups.google.com/d/msgid/qubes-devel/378bac7f-ed4c-40c3-ae08-c2fafbeea92c%40yahoo.fr
 [2] http://markmail.org/message/4csjowtrkidg6pe7
[3]
https://groups.google.com/d/msgid/qubes-devel/20161115231812.GN17458%40mail-itl

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYTa0zAAoJENuP0xzK19csG18H/irxMFEIzLPh1PiHYjjC5mHO
Hyp7csfyss7YjxsahGrkmRboFeDPKF6/ez7+6QfsrCCLB2jhcZiSgnYHJOS/9GDs
5N8E4icDj2hwsqyJefl3F2BQG6gXU0RCBT7+kixANYx6eMazXlV4ATod9rPWr1TP
Fp7B9Pl1B76Tx/JulIkSxIxRL52fLBEZaOPsaNhKblSHO/98p7pElTuPpWFpiswT
HhNz5cvSF4bmvC86He65UEDTz+pfG1OLC2/vWm9lk6n0rIt2Q0Z0bvOcpZYQCoT4
SaJm/wxQjQvgoVYOKpxZFhb//jjEllcR7Ced5u/X0Sni33colNdKIMhFMN66wzU=
=pTli
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/20161211194659.GS16264%40mail-itl. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]