I don't think it is as clear cut at all, but that makes it much more interesting. I left a comment there, but it bears some repeating I think
ESXi's kernel does not bootstrap itself from Linux at all.
There is no linux kernel as such 
ESXi does reuse linux kernel drivers ... a lot of them. But the way this happens is through a well-defined API provided by (proprietary) vmkernel called vmkapi. What you are seeing in the code above is the mapping between various Linux API's and these calls to the vmkernel.
I have no idea about the complaint. VMware's position is probably that anyone can go and write anything they want against the vmkernel's vmkapi interface. Indeed some vendors ship drivers written espeically for this API.
VMware have chosen to write a linux<->vmkapi interface, which then allows them to re-use many linux drivers. All of the linux<->vmkapi interface is released, along with the drivers and any modifications and this is considered sufficient. My guess is that the software conservatories position is that it is not.
Note exactly the other thing happens on the "other" side -- between user-land and the vmkernel. ESXi uses glibc ... but of course that interfaces to vmkernel via standard system calls. Maybe that's part of it too, I don't know.
So this may be a fight over API boundaries and where the GPL starts and stops. That's quite interesting...
 There was with the ESX product, which shipped a version of Red Hat. That hasn't been around for ages
I worked at VMware for over 11 years and was one of the first dozen or so people on the vmkernel team (which produced ESX and later ESXi), although I left several years ago.
If I recall correctly, the source tarball was created from a simple script which pulled in a bunch of open source files which were stuck into their own separate branch in the source repository.
To my knowledge, there wasn't any linux source in the vmkernel. We did use plenty of open source code, such as busybox, but my understanding was it was always in user space and the source was always published.
It's possible that Christoph's code was just pulled in and published with a bunch of other crap that wasn't actually in the product, but someone had checked it into the open source part of the source tree.
From reading the linked article, it read to me like the complaint asserts that VMKernel itself is a violation of the GPL. If I'm wrong, please feel free to correct me, but these statements seems to point in this direction
Conservancy discovered that VMware had failed
to provide nor offer any source code for the
version of BusyBox included in VMware's ESXi products
But ESXi is not a purely open-source product;
it also contains a proprietary component called
VMware's developers appear to have taken a
substantial amount of kernel code, adapted
it heavily, and built it directly into
If so, that would be like me finding some code on Github, changing it a little, and then including it in my own closed source application, clearly a violation of the GPL.
Obviously though, I'm not sure how to prove that without the source of VMKernel
Again, this is honestly just how I'm reading it, if I'm wrong feel free to correct it.
It’s not clear, this really is an interesting case. From the description in the comments here, it seems that the GPL code from Linux, together with the code to interface with vmkernel is published, complying with GPL for that part.
My guess is that VMware considers vmkernel to be the operating system (which it is, albeit a minimalistic one, just the barebones hypervisor) and regard it as GPL code from Linux linking with the glue layer and the vmkernel system library. Which, if it provides some generic interface that the glue uses, arguably is.
I am just guessing here, but seen like this, VMware’s position makes sense. I would be surprised if they all-out violated GPL, Linksys-style, to be honest, because some competent FLOSS folks work(ed) there.
This sounds more like Oracle vs Google regarding Java, where VMWare, like Google, is stating that APIs are not copyrightable, and the SFC, like Oracle, is claiming that even those APIs are copyrightable.
There is a huge difference: in this case the Vmware product does include linux kernel code. So there's definitely some reproduction and distribution of copyrighted parts even excluding the use of APIs.
I don't see the commonalities except that both are about copyright. Has there been any information that the kernel API is being claimed to be copyrighted, or header files, or are VMWare claiming that no copyrighted code has actually been distributed?
The above extract mention "substantial amount of kernel code". If that code is implemented algorithms, data structure or full kernel features, then this case has nothing in common with the core issue between Oracle and Google.
Thank you, that makes a lot of sense. I can see now how VMware can believe in good faith that they're in compliance (and in fact did a fairly major move towards compliance with ESXi) and Conservancy can believe in good faith that they're not.
Re:  There's an argument that ESXi was released to handle these concerns, which predate ESXi's release. I ran venturecake which first published the story, showing how the Linux kernel started vmkernel, not the other way around. Proprietary kernel modules are considered derived works unless they can run independently (eg, nvidia.ko isn't generally considered to be a derived work because it's largely code ported from other platforms). However retrospectively making something portable doesn't change it's previous status as a derived work, and ESXi wouldn't be popular without ESX, which wouldn't exist without Linux booting vmware (despite vmware's protestation otherwise - load ESX and watch the boot process).
I dunno, a bootloader seems like the most clear-cut example of something not being a derived work you could get - it doesn't care about the code being bootloeaded and vice-versa, and the API between the two is about as trivial as it can get. What matters according to the GPL isn't whether the code runs on other platforms but how deeply intertwined it is with the kernel; for most Linux drivers, whether it runs on other platforms is a good rule of thumb for determining this, but it kind of breaks down for ESX.
Also, "retrospectively making something portable doesn't change it's previous status as a derived work" was if I'm not mistaken SCO's argument for why it should be illegal for customers to run software they'd developed on SCO Unix under Linux. It's not something we should be supporting because it'd a really dangerous tool for locking users into a particular OS. (Fortunately, SCO lost.)
> nvidia.ko isn't generally considered to be a derived work
That's far from clear. Many core developers (including Torvalds, IIRC, but correct me if I'm wrong) are on the record that they consider Nvidia to violate the spirit and/or the letter of the GPL there. It's just that nobody cares enough to litigate.
I think the fact that this leaks DNS lookups is really quite key because that gives away a huge amount about what you're looking at over your "vpn", not to mention services like netflix that are pointing you to different responses based upon the source of your dns lookups.
In firefox you want to go to about:config page and turn on network.proxy.socks_remote_dns
I believe that Mac OS X does tunnel DNS when you configure the proxy through Control Panel -> Network. I used this when I was in the Army and lived in housing whose internet connections were managed by a crappy ISP that did DNS-based filtering of sites they deemed objectionable.
When I wrote this, I'm not sure if the iPhone had been released; certainly at that point if you were carrying around something computer-like in your (large :) pocket (more powerful than a PalmPilot) it was something like a Jornada http://en.wikipedia.org/wiki/Jornada_(PDA)
To me "palmtop" strongly connotes something handheld, with a clamshell or a slide-out keyboard, and running a desktop-style OS. That HP 95LX is a good example; the OQO was a more recent one (2005 ish?).
Funny you mention that Petzold book; I read that as an IT student doing airy courses about software requirements and design and realized I had to get across to the electrical engineering building. I didn't have the prereqs for the OS course, so I did the first assignment from the previous year and sent it to Gernot and begged to be let in. He ended up my thesis supervisor.
(The other person I remember not being totally thrilled with the IT courses was Scott Farquhar, of billionaire Atlassian fame)
So that book can change your life, and is the first thing I tell people to read who show an interest in the systems area
This book was created both from my experiences and the experiences of teaching 3rd year operating systems classes.
Students came in to that class having done a 2nd year class (data structures and algorithms I think) that was done with a lot of C. They really learnt "high-level" C, enough syntax to get by in the their course, but most didn't really understand it -- not enough to read the source to any kernel at any rate. I don't imagine it's done like that today; this was a long time ago.
And most didn't really understand binary and hex, and how it relates to code either. You'd be amazed most 3rd year students didn't know how 2^10, 2^20, 2^30 relates to kilo, mega, giga bytes.
The book needs a lot of editing, something I occasionally get to. But apart from the odd times someone posts it to here or reddit and people consider it like a text book, it's really only ever accessed by people googling for a specific topic. But suggestions are welcome and I'll consider it when I get some time.
And on the "it's not computer science". The first commit was 10 years ago and people have been telling me that ever since. It was originally dreamed up as a course I'd teach to high-schoolers over 10 weeks to prepare them better for university -- the "computer science" degree they were planning to take. Yes, the book is really more about what would be called "systems" in the outside world.
> I don't imagine it's done like that today; this was a long time ago.
Sadly, it still is in many (most?) places' CS curricula.
> And most didn't really understand binary and hex, and how it relates to code either. You'd be amazed most 3rd year students didn't know how 2^10, 2^20, 2^30 relates to kilo, mega, giga bytes
I've worked with graduates who didn't know binary, didn't understand signed/unsigned overflow and how integers wrapped around, and perhaps even more disturbingly, had never used a command line or knew how to do a lot of other things that could be called "basic computer literacy for CS students"... because almost all they were taught were mechanised steps on how to open an IDE, write some code, and click the Build/Run buttons. I think your book would be suitable for those students.
> But suggestions are welcome and I'll consider it when I get some time.
I think for the purpose you created the book, the organisation is fine; it appears to be a collection of selected topics instead of one meant to be coherently read from start to end.
It's great work, but the title is still misleading. Computer Science deals with more than just operating systems. I'd have expected at least some more discrete mathematics before it could be called "computer science".
This criticism, by the way, should not be seen as in any detracting from the amazing job you have done there! Thank you for publishing this.
A review by a security engineer would have prevented a false sense of security
Everyone involved in this, from the people who wrote the heartbeat code, the people who committed the code, the people at Akami who wrote this patch, this poster ... all would describe themselves as security engineers. Is everyone but Willem Pinckars incompetent?
I think the one lesson to learn is to treat crypto just like you do cloud providers. Make sure you have an exit strategy from day one; the ability to push a button to roll keys, switch algorithms, switch cert providers, etc.
There's been a lot of overly-confident statements about Heartbleed not being a big deal from apparently competent people these last few days. I'm not sure what it is about it that causes security professionals to spout off without testing their assumptions, but...
I don't think I've worked anywhere where there was a simple way to switch cloud providers with the push of a button. Even migrating to different locations within a cloud provider isn't trivial. You'd have to invest a lot of engineering time from the beginning to get this kind of capability, and you may never realize any value for all the pain.
But the whole episode, and this post in particular, highlights the issue that enough review is never enough. When is the the code secure? When it is written by someone with a good track record? When it gets reviewed and committed by knowledgeable parties? When it's been running for several years without incident? When it passes coverity? When Willem has time to review it?
When I just think about the embedded ssh keys I've got in my few toy systems; if I discovered ssh was broken (and it's happened; look at the Debian bug) I'd be sinking a lot of time figuring out just how to change the keys everywhere. I should have designed for this from the start; lesson learnt. I bet there's lots of admins out there who wish they had better ways to update certs on a moments notice over the past week...
I think it's reasonable to disagree with the part he quoted. "A review by a security engineer ..." Well, it was reviewed by security engineers, and the false sense of security remained. The rest seems fine though.
We're still evaluating some of his arguments. I still believe some of them are true in the general case, but do not apply to our specific embedding of this code. I say that aware that I was mistaken 12 hours ago, and so very well could be mistaken now.
But I am reasonably convinced that the CRT values are loaded into the normal heap, where they're available to a normal Heartbleed attack. Pinckaers doesn't have to be right about all his points to be right---just once---and I'm pretty sure he's right at least that once.
If the tone of my message was a bit harsh, it was mostly to reflect his, and thankfully I do not have a life boring enough that this is "my moment".
Still, I stand by my point of view that at the time of writing, akamai's POC was presented neither as an absolute final fix nor as their own production version of it, and judging it as such was misplaced.
That akamai realized the flaws he noted in their patch also applies to the real world code doesn't change that.
I never said the flaws he pointed were not real flaws nor unimportant ones, I merely disliked the ridiculous and unjustified tone he used to to destroy a proposal and used the same against him.
Sources close to the issue, in touch with SiliconAngle, have confirmed that more than 700,000 bitcoins are indeed missing from MtGox’s coffers as has been rumored during the history running up to this shutdown.
for anyone catching up, gox.com seems to be sold to mtgox.com in the last few days