| Spectre and Meltdown Patch ASAP Please [message #53068] |
Thu, 04 January 2018 09:04  |
vztester
Messages: 19
Registered: August 2008
|
Junior Member |
|
|
RHEL already has a patch out and this may be the most important patch for OpenVZ.
On that note it sounds like it would be impacted, can any OpenVZ devs comment if they know for sure Spectre and Meltdown apply here?
AFAIK I would expect and assume so and this is a so-called doomsday scenario if an attacker can gain access to other containers' or hostnode memory.
rtt
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Spectre and Meltdown Patch ASAP Please [message #53077 is a reply to message #53076] |
Fri, 05 January 2018 17:16  |
samiam123
Messages: 15
Registered: March 2017
|
Junior Member |
|
|
As far as I know there are no known exploits in the wild. So no need to panic just yet. Also, the KernelCare people still have not released a patch and they are usually on top of things. So it must be a complicated one that will take some time. OVZ has been pretty good at security updates so I am sure they will be coming out with a patched kernel soon enough.
That link someone posted further up indicates they are already testing a patched kernel. The fact it has not made it to OVZ kernel yet is not necessarily a bad thing. That means we will probably eventually get a more well tested kernel. There will probably be more kernel updates as changes are better tested. There is also a microcode update from Intel coming so that will be more testing and maybe another patch once that is out. So it's not a quick fix update the kernel and you are done thing.
https://www.cloudlinux.com/cloudlinux-os-blog/entry/intel-cp u-bug-kernelcare-and-cloudlinux
[Updated on: Fri, 05 January 2018 17:56] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Spectre and Meltdown Patch ASAP Please [message #53088 is a reply to message #53081] |
Sun, 07 January 2018 03:45 |
snajpa
Messages: 8
Registered: December 2007
|
Junior Member |
|
|
diff -ruN ./arch/x86/mm/pgtable.c ../linux-16-to-vz/arch/x86/mm/pgtable.c
--- ./arch/x86/mm/pgtable.c 2018-01-07 04:22:45.057056298 +0100
+++ ../linux-16-to-vz/arch/x86/mm/pgtable.c 2018-01-05 08:13:54.251837657 +0100
@@ -325,8 +325,8 @@
pgd_mop_up_pmds(mm, pgd);
pgd_dtor(pgd);
paravirt_pgd_free(mm, pgd);
- free_pages((unsigned long)pgd, PGD_ALLOCATION_ORDER);
mm->nr_ptds--;
+ free_pages((unsigned long)pgd, PGD_ALLOCATION_ORDER);
}
int ptep_set_access_flags(struct vm_area_struct *vma,
Well, that ^ is the difference between OpenVZ team's patch and mine, otherwise I'm at the same code now, to the last whitespace. I was too lazy here to reorder the lines to make more sense, I knew about this one while I made it.
Hm... OK, next time I surely won't spend the day waiting for OpenVZ team and I will rather get to the porting of RHEL 6 changes right away.
|
|
|
|
|
|
|
|
|
|
| Re: Spectre and Meltdown Patch ASAP Please [message #53094 is a reply to message #53068] |
Sun, 07 January 2018 16:26 |
 |
curx
Messages: 739
Registered: February 2006
Location: Nürnberg, Germany
|
Senior Member |
|
|
Hi,
please take a lool at the Announce:
OpenVZ project released an updated RHEL6 based kernel.
Read below for more information. Everyone is advised to update.
Changes and Download
====================
(since 042stab126.2)
* Rebase to RHEL6u9 kernel 2.6.32-696.18.7.el6
* [Important] CVE-2017-5715 triggers the speculative execution by utilizing branch target injection. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall and guest/host boundaries and read privileged memory by conducting targeted cache side-channel attacks. (CVE-2017-5715)
* [Important] CVE-2017-5753 triggers the speculative execution by performing a bounds-check bypass. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall boundary and read privileged memory by conducting targeted cache side-channel attacks. (CVE-2017-5753)
* [Important] CVE-2017-5754 relies on the fact that, on impacted microprocessors, during speculative execution of instruction permission faults, exception generation triggered by a faulting access is suppressed until the retirement of the whole instruction block. In a combination with the fact that memory accesses may populate the cache even when the block is being dropped and never committed (executed), an unprivileged local attacker could use this flaw to read privileged (kernel space) memory by conducting targeted cache side-channel attacks. (CVE-2017-5754)
* A null-pointer dereference in net/rds/rdma.c:__rds_rdma_map() could allow a local attacker to cause denial of service. (PSBM-79750)
* Start of a container with NFS server inside could result in node crash due to a bug in auth_domain_put(). (PSBM-80028)
For more info and downloads, see:
https://openvz.org/Download/kernel/rhel6/042stab127.2
See also
========
https://access.redhat.com/errata/RHSA-2018:0008
https://www.redhat.com/security/data/cve/CVE-2017-5715.html
https://www.redhat.com/security/data/cve/CVE-2017-5753.html
https://www.redhat.com/security/data/cve/CVE-2017-5754.html
Bug reporting
=============
Use http://bugs.openvz.org/ to report any bugs found.
Regards,
OpenVZ team
|
|
|
|
| Re: Spectre and Meltdown Patch ASAP Please [message #53095 is a reply to message #53092] |
Sun, 07 January 2018 17:25 |
vaverin
Messages: 708
Registered: September 2005
|
Senior Member |
|
|
Dear Pavel,
we do not 'just repack' stable RHEL kernels, we add own functionality,
we have own original usecases that are out of focus of Red Hat.
We regularly found and report issue affected RHEL and sometime mainline linux kernels.
Last RHEL6 patch was 250+ kB size and changed 180 files,
it was not cosmetic changes that cannot affect our functionality.
We have detected such troubles before.
For example recent stackguard fix broke CPT in vz6 kernel
http://www.openwall.com/lists/oss-security/2017/06/22/6
we timely detected the problem and released fixed kernels
so our users was not noticed it.
This time our testing found that last Red Hat changes broke CRIU,
that's why my collegians have still not released update for Vz/OpenVz 7 (I hope they will finish soon).
The same issue affects vz6 kernels too however our carefull testing did not detected any (new) troubles,
seems criu usecase is really very special.
So please, say thanks to our glorious QA for their hard, important and almost invisible work.
Thank you,
Vasily Averin
|
|
|
|
| Re: Spectre and Meltdown Patch ASAP Please [message #53096 is a reply to message #53095] |
Sun, 07 January 2018 17:54 |
snajpa
Messages: 8
Registered: December 2007
|
Junior Member |
|
|
Thank you Vasily for your answer!
Now, I know that at times like this, there's too little time to do PR and communicate all of what is going on internally to the outside, but you see...
There's this board, Twitter, IRC, MLs, wiki and I don't know how many other channels, I've monitored most of them, but there was literally no message from you guys in the critical time window for me - I'm sitting on 1700 production containers and have to keep them reasonably up & secure. So when 696-18.7 came out, I became really anxious about not knowing whether I should start porting and testing myself.
I've been running OpenVZ 6 long enough to have approximate knowledge of how it works internally and how it evolved over time, back to 2009, when we started with OpenVZ, which shipped with Debian.
Since then I have even built a start up company based on vz6, which failed to make it commercialy, but we did have vz6 and ZFS integrated the Kubernetes way for our internal deployment back 5 years ago.
I think we share a common vision, how containerization on Linux should be done and how it should be used and deployed.
But I can't agree with the way you're handling it as an open-source project. The world around you guys has moved and now there's a whole bunch of successful open-source based companies, which model you could follow - Jira doesn't quite cut it these days.
I would appreciate to see the QA results live and everything, you're doing basically behind closed doors, to be an open process too. Where money lies in and what I would pay you for, is for ability to have my ticket in a public standard open-source friendly bugzilla (well, or Github...) prioritized. But the way it was with the vz 6 support program...
I think it's not impossible to be fully open, yet commercially successful project - when you let the right people go after selling just what the heck you would do anyway for free. Wouldn't you want to help guys over here while merging and testing the patches together with the community? Could you imagine what we could do if every one of us power vz users had cooperated with you on QA? Shared tests in git repo, deployed in labs all over the planet? I would certainly participate.
But for that, vz7 would have to stay vzkernel+vzctl+libs combo of repositaries, not a complete bundle of heavily modified EL.
I can definitely understand the desire to integrate all to a bundle like that, but that shouldn't come at cost of being able to at least build your stuff from scratch - and create a custom bundle of heavily modified VZ.
vaverin wrote on Sun, 07 January 2018 12:25
[...] that are out of focus of Red Hat.
I definitely know what you're talking about, at 120+ CTs per node and those CTs load variability and their ever increasing size and demand for resources, I can feel the use-cases Red Hat doesn't test.
Or at least didn't with EL6.
But since things are the way they are, we are forced to build our own custom repack of something, with the same goals in mind as you guys.
So we're choosing to do that based on a distro, which is defined declaratively, can be QA-d from scratch on-commit out-of-box; a distro which can be bent so much, we don't have to run along with the inustry's madness with Systemd, LXD, Docker and other bad practice example collections.
So in the end I have much to thank you guys for.
Firstly, for much of the code which is upstream now and which I can now rely and build upon;
secondly, for pioneering containers the right way;
thirdly for CRIU,
and lastly, but this is most important - by publishing your technology as open-source (regardless my reservations here), you've enabled me to pioneer and build
a community-based way of sharing hardware, some would say a community alternative to commercial hosting; vpsFree.cz (https://vpsfree.org website in English).
It wouldn't exist without OpenVZ, certainly we wouldn't be able to fit so much so comfortably on so little HW, compared to fullvirt-ers.
So there is a lot of things I'm thankful about.
|
|
|
|
|
|
| Re: Spectre and Meltdown Patch ASAP Please [message #53099 is a reply to message #53068] |
Sun, 07 January 2018 20:41 |
vztester
Messages: 19
Registered: August 2008
|
Junior Member |
|
|
Thanks OpenVZ team for the patch. I want to say the positive is that we do have an active community and this issue got more people active here in the forums that have been lurking.
It would have been nice for some communication or announcement/timeline, normally I would not be so impatient but in this circumstance it is urgent.
With that said I think we should express more appreciation, OpenVZ is free of charge and has enabled us all to do a lot of amazing things and has been a very rock solid solution that I've used for basically 13 years.
rtt
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
) I miss that. A lot!
