Linux kernel security updates
69 views
Skip to first unread message
Chris Laprise
Dec 10, 2016, 10:23:43 PM12/10/16
to qubes...@googlegroups.com, Marek Marczykowski-Górecki
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
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
Andrew David Wong
Dec 11, 2016, 3:16:50 AM12/11/16
to Chris Laprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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?
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?
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?
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJYTQtaAAoJENtN07w5UDAwx0YP/RhE2rSsgh8B2QWc/+4g+E2d
bRkVHn2TpPpr0MZwQNsBPkR0qnXSk1DIt35lgvjjA3nSZxxi2GhPiHvQyWgS155f
Sh/IV2k70T9uW4h2e0bIscvoNTKBcZtHNIek7Mi3UcE+eX6O86CwfE7dKg1m39lA
OsgA8eVhOse1VqOVvllPu5bp5ZDowFqfFBgk1uBmC/xzqegMFEgkeSWMj4UKMR3p
YDVWJdNVTOepGZe+uuMdPBsN1cpDTgZgIFTSTtEHp5B60UMfDdzmGAWuAK+Pw8xo
BLM9+ajn9UuXBEFNjkkNcIhiTalzqMWSgqRoI/7mBusY3+V8e2pqhEDrjK//TUiF
M+EmTtiJLab/6ncqSd9SopqkZHQj37Ln4AtRyhVtNInm2Fz13E01sjaNDTkeBS75
uBHp8xRiM9/+/e6TJxbBXbfIJPysYqaM2MXW+Lr4GtqgD2eLAsrskXWS0Q3PkV/h
kpK2t2rfCsSC+xgNmV7GANQ4GmxhjQkNjor/4WOMvnulY3bJYtVqk+hWKeNUp8Ge
+YYIPqbwwG4ldKgI0hQ8+FER4ZjeTBUgqd+1Yvb0SXLPCNVv2QsThM0TXkUSnPQ0
NVg4ailjCi4XM5Xo04IsWqe6m/ulUt0bTAgqAS+Z9WeGCBVo9vBWAT39DCfGekDQ
bQ1OGLnQBfpIq9nWP3uk
=L7tQ
-----END PGP SIGNATURE-----
Hash: SHA512
a long delay? Have you been monitoring the delay? How long is it, on
average?
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?
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?
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJYTQtaAAoJENtN07w5UDAwx0YP/RhE2rSsgh8B2QWc/+4g+E2d
bRkVHn2TpPpr0MZwQNsBPkR0qnXSk1DIt35lgvjjA3nSZxxi2GhPiHvQyWgS155f
Sh/IV2k70T9uW4h2e0bIscvoNTKBcZtHNIek7Mi3UcE+eX6O86CwfE7dKg1m39lA
OsgA8eVhOse1VqOVvllPu5bp5ZDowFqfFBgk1uBmC/xzqegMFEgkeSWMj4UKMR3p
YDVWJdNVTOepGZe+uuMdPBsN1cpDTgZgIFTSTtEHp5B60UMfDdzmGAWuAK+Pw8xo
BLM9+ajn9UuXBEFNjkkNcIhiTalzqMWSgqRoI/7mBusY3+V8e2pqhEDrjK//TUiF
M+EmTtiJLab/6ncqSd9SopqkZHQj37Ln4AtRyhVtNInm2Fz13E01sjaNDTkeBS75
uBHp8xRiM9/+/e6TJxbBXbfIJPysYqaM2MXW+Lr4GtqgD2eLAsrskXWS0Q3PkV/h
kpK2t2rfCsSC+xgNmV7GANQ4GmxhjQkNjor/4WOMvnulY3bJYtVqk+hWKeNUp8Ge
+YYIPqbwwG4ldKgI0hQ8+FER4ZjeTBUgqd+1Yvb0SXLPCNVv2QsThM0TXkUSnPQ0
NVg4ailjCi4XM5Xo04IsWqe6m/ulUt0bTAgqAS+Z9WeGCBVo9vBWAT39DCfGekDQ
bQ1OGLnQBfpIq9nWP3uk
=L7tQ
-----END PGP SIGNATURE-----
Chris Laprise
Dec 11, 2016, 1:24:03 PM12/11/16
to Andrew David Wong, qubes...@googlegroups.com, Marek Marczykowski-Górecki
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
> -----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?
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.
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.
> 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?
Qubes/Xen specifics would only pose minor difficulties.
> 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?
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. (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'.)
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.
Chris
Marek Marczykowski-Górecki
Dec 11, 2016, 2:47:05 PM12/11/16
to Chris Laprise, Andrew David Wong, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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-----
Hash: SHA256
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.
> > 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.
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.
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'.)
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.
[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-----
Reply all
Reply to author
Forward
0 new messages