| vzkernel-3.10.0-x releases stopped since Sept? [message #53463] |
Fri, 30 November 2018 19:22  |
wsap
Messages: 56
Registered: March 2018
Location: Halifax, NS
|
Member |
|
|
Hey OpenVZ devs... where are the security patched kernels for OpenVZ 7?
We get regular email alerts about security patches to both OpenVZ 6 and 7, yet only the OpenVZ 6 kernels have been released in the repos since September, despite multiple patches having been developed for the OpenVZ 7 kernel.
It's one thing to block the open source community's access to the ReadyKernel patches (even though many of us would surely pay for a KernelCare-like licensing structure for this feature), but a whole other, much more serious, thing to not even release security-patched kernel versions...
What's going on here?
And while we're on the topic, shouldn't these OpenVZ 7 kernel updates that never actually get compiled and released to the repos be set up with an RSS feed on openvz.org like the OpenVZ 6 kernel updates are?
|
|
|
|
|
|
| Re: vzkernel-3.10.0-x releases stopped since Sept? [message #53465 is a reply to message #53464] |
Mon, 03 December 2018 15:13  |
wsap
Messages: 56
Registered: March 2018
Location: Halifax, NS
|
Member |
|
|
So you're essentially saying:
1. The Virtuozzo devs only care about the security of OpenVZ 6 because you're stuck patching it still, and
2. The Virtuozzo devs think it's acceptable to leave their kernel vulnerable on countless OpenVZ 7 systems because the people that are using it should be paying you for a full Virtuozzo license if they want security.
That's pretty absurd. If I were running KVM on a CentOS 7 box, I would receive kernel patches as they are released by the CentOS 7 development team. At bare minimum Virtuozzo 7 should get a similar kernel patch/release cycle as CentOS 7 to apply the upstream kernel patches, even if that doesn't include OpenVZ 7 specific patches.
All that this policy does is serve to push people away from OpenVZ 7 to alternate platforms that don't treat security so poorly, which means your team's possibility of upgrading OpenVZ 7 users to a full Virtuozzo 7 license gets even slimmer. Why would you want to encourage that?
[Updated on: Mon, 03 December 2018 15:14] Report message to a moderator |
|
|
|
| Re: vzkernel-3.10.0-x releases stopped since Sept? [message #53466 is a reply to message #53465] |
Mon, 03 December 2018 16:10 |
khorenko
Messages: 533
Registered: January 2006
Location: Moscow, Russia
|
Senior Member |
|
|
i'm essentially saying that Virtuozzo devs work on Virtuozzo - payed version - and do as much as they can to make OpenVZ users happy, but with no additional devs/QA efforts (which are unpayed, sorry).
And building stable kernels + readykernel patches - are efforts, it cannot be automated.
And TESTING them are BIG efforts, because tests do fail and QA (humans!) have to investigate issues.
Quote:2. The Virtuozzo devs think it's acceptable to leave their kernel vulnerable on countless OpenVZ 7 systems because the people that are using it should be paying you for a full Virtuozzo license if they want security.
Surely not. i personally just think that people who use OpenVZ (and want to save their money) are quite experienced (otherwise how do they run business without support?).
And if so, they can build kernels with security fixes themselves. This is a payment for saving money.
And again - this is my personal opinion only,
and people who make business decisions might have different ones.
If your problem is solved - please, report it!
It's even more important than reporting the problem itself...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: vzkernel-3.10.0-x releases stopped since Sept? [message #53472 is a reply to message #53468] |
Wed, 19 December 2018 10:23 |
khorenko
Messages: 533
Registered: January 2006
Location: Moscow, Russia
|
Senior Member |
|
|
devnull wrote on Thu, 06 December 2018 01:55Just one question, is there somewhere a guide (even a short note would be fine) to build a kernel - marked as stable - plus security fixes?
i'd say the easiest way is to
* get src.rpm of the latest stable kernel,
* unpack it "# rpm -ihv vzkernel-...src.rpm",
* get patches you want to apply (for example take from the devel email list or from vzkernel git tree)
You can also take a look at the list of issues listed at ReadyKernel site - just for the reference which are worth to apply.
* put additional patches to apply into ~/rpmbuild/SOURCES/ and edit ~/rpmbuild/SPEC/kernel.spec to apply new patches
(take a look how it's done for linux-kernel-test.patch kernel.spec, do it similarly)
* don't forget to add some suffix to "%define ovzver" in kernel.spec
* and finally compile the kernel, command example:
# cd ~/rpmbuild/SOURCES/ && rpmbuild -v --define "_sourcedir $PWD" -ba ../SPEC/kernel.spec
Or you can
* clone vzkernel git tree
* checkout latest stable by tag
* apply new patches you want (may be just cherry-pick them from later branches)
* prepare a cumulative patch using a command for example:
# git diff rh7-3.10.0-862.14.4.el7 | filterdiff -p 1 --clean -x configs/\* -x config.OpenVZ\* | xz > ~/rpmbuild/SOURCES/patch-ovz.xz
(instead of "rh7-3.10.0-862.14.4.el7" you should use a tags for RHEL kernel which your stable kernel is based on)
For example for vzkernel-3.10.0-862.11.6.vz7.64.7.x86_64.rpm the RHEL tag is "rh7-3.10.0-862.11.6.vz7.64.7.el7"
* don't forget to add some suffix to "%define ovzver" in kernel.spec
* and finally compile the kernel, command example:
# cd ~/rpmbuild/SOURCES/ && rpmbuild -v --define "_sourcedir $PWD" -ba ../SPEC/kernel.spec
If your problem is solved - please, report it!
It's even more important than reporting the problem itself...
|
|
|
|
|
|
|
|
| Re: vzkernel-3.10.0-x releases stopped since Sept? [message #53475 is a reply to message #53466] |
Fri, 28 December 2018 02:30 |
wsap
Messages: 56
Registered: March 2018
Location: Halifax, NS
|
Member |
|
|
khorenko wrote on Mon, 03 December 2018 12:10i'm essentially saying that Virtuozzo devs work on Virtuozzo - payed version - and do as much as they can to make OpenVZ users happy, but with no additional devs/QA efforts (which are unpayed, sorry).
And building stable kernels + readykernel patches - are efforts, it cannot be automated.
And TESTING them are BIG efforts, because tests do fail and QA (humans!) have to investigate issues.
I do actually completely understand that you'd want to invest as little time as possible into maintaining the open source base systems. This is why I suggested keeping these types of releases strictly to security patches released to the upstream CentOS kernel, and nothing more.
My suggestion is that *after* these patches have been tested as readykernel patches (which the dev team has to do anyway for commercial customers), the same patches/diffs be applied to the currently stable kernel release, compiled, then quickly tested to confirm the kernel boots successfully, then released to the repo (or perhaps the testing repo for a week before being moved to release).
To further save time investment, every time a ReadyKernel patch is created, the same diffs could be quickly applied to the stable kernel on a test box. Then once a month, a cron script could freshly compile and install the testing kernel and reboot the box. Upon successful reboot it would upload the new kernel release to the repo. If the automated compiling and reboot fails, then it seems plausible the failure could be helpful feedback for devs and likely for ReadyKernel commercial customers as well.
A couple notes on this:
- Doing this should be considerably more stable for end-users than suggesting that they use factory kernel versions. And it would be much more secure for end-users than not getting security patches for 60+ days as it will result in a security patched kernel release roughly once a month. End-users can then choose whether they want to reboot into it immediately or a bit later to keep their reboots to a minimum.
- Ultimately, devs already have to do the work of testing the exact same patches via ReadyKernel, so this work does not need to be duplicated or wasted time. The only additional dev time would be the act of applying the patches to the current release kernel. Even the act of installing the kernel on a test box and rebooting the box to ensure it comes back online could be automated as described above. A seasoned kernel dev would take probably 15 minutes to do this with automation and 60 minutes without automation each month.
Yes, this means a small amount of additional dev time monthly, but it also means you're sending important messages:
1. When users of OpenVZ 6 need to make the decision to choose either OpenVZ 7 or move to a different virtualisation system (which is going to happen en masse in the next year due to OpenVZ6 EOL Nov 2019), that the OpenVZ 7 transition is the simplest and optimal way forward because it does not present them with new security challenges, as compared to vz6.
2. That Virtuozzo Linux 7 is at least on par security-wise with CentOS 7, which nobody can say is the case at the moment since security patches for Virtuozzo 7 are often delayed by months as compared to CentOS 7.
I've heard that Virtuozzo is preparing for stand-alone release of ReadyKernel and regardless of whether the Virtuozzo devs decide to do any of the above, I'll be first in line to purchase and use ReadyKernel on our OpenVZ 7 nodes. I do, however, still hope that you'll do something like what's described above to ensure that those who do not opt for a ReadyKernel subscription can best maintain the security of their nodes.
While I don't think this is nearly as comprehensive a solution, I'm grateful that @khorenko provided the rough steps to download the kernel sources, apply security patches, and compile the patched kernel. If that could be expanded into a more comprehensive wiki entry, I think that would be a great, albeit somewhat less useful, alternative.
[Updated on: Fri, 28 December 2018 02:32] Report message to a moderator |
|
|
|
|
|
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
