In January, I made a seed investment in a company called Standing Cloud. My premise was that as “cloud computing” proliferated, it’d be a total mess for the typical application developer and ISV. Over the past six months a small team of super talented long time software developers and system architects have been exploring a wide variety of cloud services, OS instances, and popular open source software packages to understand where the “extremely broad painful problem that no one is addressing” is going to be.
Dave Jilk, Standing Cloud’s founder, and I are going to hike Mount Bierstadt as part of our annual tradition of climbing a 14er together (this will be #4). We’ll have each other trapped together for 5+ hours to consolidate our thinking on what we’ve learned so far this year and which particular angle to position Standing Cloud on the launch pad.
In the meantime, one of the other Standing Cloud founders – Joel Wampler – wrote a guest post on ElasticVapor titled Fixing Major Linux Kernel Vulnerabilities in the Cloud. If you are interested in this type of thing, it’s a good hint about the types of things that Standing Cloud is uncovering every single day. For example:
“Last week, a Linux kernel vulnerability that allows for local privilege escalation through a NULL pointer dereference was announced. Many of the major Linux distributions are still working to provide updated kernels, and a few already have. Once updated kernels are released, applying the patches should be straightforward. But for systems running in the cloud, additional complexities and delays may arise.
Most providers of on-demand cloud servers require the use of custom kernels, which are tuned for the provider’s specific virtualization implementation. These custom kernels significantly change the upgrade path, and may even affect the short-term workarounds provided by the upstream distribution.
For instance, the Ubuntu bug report for this issue states the following:
Ubuntu 8.04 and later have a default setting of 65536 in /proc/sys/vm/mmap_min_addr. When set, this issue is blocked.
However, if a system is running Ubuntu 8.04 on Amazon EC2, the underlying kernel is likely based on a Fedora Core 8 Xen kernel. This is one of the kernels Amazon provides to those who create boot images for their service, and most such images use this kernel regardless of the distribution running on top of it. Thus the default setting of 65536 cannot be relied upon; and worse, this proc setting does not even exist in the Fedora kernel, so there is no way to repair the image to match this workaround.”
Lots more coming soon – get ready for it. In the mean time, I hope there are no clouds on my hike tomorrow.