41–50 of 50 posts
Why do the major Xen providers get advance access to the patches while my machines have to sit vulnerable for over a week?
Earlier quoted context omitted.
realize that there's Xen HVM and Xen PV. there have been significantly more security issues in HVM than there have been in PV.
Do we know why HVM/hw-virt has had more security issues than PV/sw-virt?
Xen's hypervisor would seem to be a great place to implement live patching like KSplice/kGraft/Kpatch does for the Linux kernel. Presumably that stuff still works on KVM host machines with live guests.
Amazon's security advisory seems to indicate that they have this capability for 90% of EC2 instances (leaving 10% that must be rebooted). https://aws.amazon.com/premiumsupport/maintenance-2015-03/
This is why SEL4 is awesome. http://ssrg.nicta.com.au/projects/seL4/ First kernel with certain security guarantees formally proven; now open source. It can be used as a hypervisor which seems like its most obvious first use case. At least until there is enough middle-ware to build full systems directly with it.
Hardware support is up to you. I think you can boot it on x86, but that's just the microkernel -- you have to add all the hardware support. I don't think seL4 is meant to run on servers either.
Why do the major Xen providers get advance access to the patches while my machines have to sit vulnerable for over a week?
Two working weeks between issue of our advisory to our predisclosure list and publication.
When a discoverer reports a problem to us and requests longer delays than we would consider ideal, we will honour such a request if reasonable. If a discoverer wants an accelerated disclosure compared to what we would prefer, we naturally do not have the power to insist that a discoverer waits for us to be ready and will honour the date specified by the discoverer.
Naturally, if a vulnerability is being exploited in the wild we will make immediately public release of the advisory and patch(es) and expect others to do likewise.
This is an extraordinarily aggressive (in a good way) and transparent process. Big commercial vendors routinely sit on vulnerabilities for months.
Xen's hypervisor would seem to be a great place to implement live patching like KSplice/kGraft/Kpatch does for the Linux kernel. Presumably that stuff still works on KVM host machines with live guests.
Amazon's security advisory seems to indicate that they have this capability for 90% of EC2 instances (leaving 10% that must be rebooted). https://aws.amazon.com/premiumsupport/maintenance-2015-03/
Just received a message from Rackspace cloud regarding theses, it seems like they will have to reboot all instances. See https://community.rackspace.com/general/f/53/t/4978
Yet linode is still silent...
Earlier quoted context omitted.
Amazon's security advisory seems to indicate that they have this capability for 90% of EC2 instances (leaving 10% that must be rebooted). https://aws.amazon.com/premiumsupport/maintenance-2015-03/
Not really - to me, it implies that 90% of EC2 instances are not running on a vulnerable version of Xen...
> While all instance types need to be updated, we have developed the capability to live-update instances running on newer hardware. The vast majority of the EC2 fleet will be live-updated, but a portion of instances (less than 10% of customer EC2 instances) running on older hardware will require a reboot to complete the update process.