Hacker Newsnew | comments | show | ask | jobs | submit | delsarto's comments login

There is a big deal made of this in "The Men Who Built America" [1] which I started watching because it came up on Netflix. Maybe it is new there and people have started watching it

[1] http://www.imdb.com/title/tt2167393/

-----


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 [1]

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...

[1] 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
    "vmkernel."

    VMware's developers appear to have taken a 
    substantial amount of kernel code, adapted 
    it heavily, and built it directly into 
    vmkernel itself

    
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.

-----


> clearly a violation of the GPL.

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.

And that - GPL code linking with proprietary system library - is an explicitly permitted exception in GPL: http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryExcept...

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.

-----


FYI - BusyBox is just a regular application that a kernel would run. It's not part of the kernel itself.

-----


To be clear, I didn't make the above statements regarding BusyBox, they were made by the claimant, and the author of the linked article.

-----


FYI - The complaint is regarding the VMWare ESXi kernel.

-----


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.

-----


"ut the way this happens is through a well-defined API provided by (proprietary) vmkernel called vmkapi. "

From my understanding, the problem is that vmkernel directly includes linux kernel GPL code, but they do not open source it.

If that's the case, this is 100% clear cut.

IE they aren't obeying their own interface, and have shoved GPL code in the wrong side of it.

-----


Re: [1] 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.)

-----


There is no boot loader. This is the Linux kernel module interface. The boot loader used on ESX was an actual boot loader, IIRC grub.

Arguing kernel modules are derived works from the kernel is very very different from arguing user space software is derived from an OS.

-----


> 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.

-----


That sounds an awful lot like embrace, extend, and extinguish in my woefully uneducated opinion.

-----


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.

-----


I'm using the latest stable release of Firefox (34.0.5) and I see a "Remote DNS" checkbox under my SOCKS proxy configuration. Isn't that the same option in the GUI? No about:config tweaks needed?

I would think so, but everyone seems to be giving the about:config business, so maybe I am missing something.

-----


Yes, that is the same option. Toggling the option in the GUI toggles network.proxy.socks_remote_dns in about:config. As default it is, is still off though.

-----


Most probably it has been added, my notes from this are from 2008 so it's hardly cutting edge! :)

-----


Beware: https://news.ycombinator.com/item?id=8757877

-----


I have been using Chrome/FF extension called FoxyProxy, it tunnels the DNS requests through the SOCKS proxy.

-----


Nice! I've been using dnsmasq to route my DNS queries and prevent leakage. Didn't realize the nework.proxy.socks_remote_dns option existed. Thanks for sharing!

-----


"17,000 rpm with digital pulse technology" ... I guess that means a PWM DC motor controller?

-----


"Digital motor" raised my eyebrow too. Apparently it's this: http://en.wikipedia.org/wiki/Reluctance_motor

Guess marketing didn't think "Reluctance motor" had quite the same ring, and I'd tend to agree.

-----


Linked from that page is this article which goes into the design and development of the motor a bit: http://www.electronicsweekly.com/news/design/power/dyson-vac...

-----


Correction, it's a 73,000 rpm motor!

-----


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)

This sort of form-factor came directly out of things calld "palmtop pc's" like http://en.wikipedia.org/wiki/HP_95LX

-----


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?).

A device with a similar form factor but running a mobile OS would have been called a "MID" (mobile internet device) or possibly a tablet - https://en.wikipedia.org/wiki/Nokia_770_Internet_Tablet for example.

-----


(original author here)

Yeah, it was done after I was asked to run a short course on writing drivers, so the focus was on understanding that sort of layer.

But you want to know how old this is? I actually used the word "palmtop" :)

-----


(Author of the linked book)

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

-----


(author here)

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...

-----


When in doubt, always asssume a compromise of anything is a compromise of everything. Golden rule.

-----


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.

-----


Yep; not easy at all ... if it were easy everyone would do it :) I think with tools like puppet and orchestration tools like heat, etc it is getting closer to being easier.

I did got to a Netflix talk once where they said that while moving from AWS would huge, they had a plan and I think from memory they said it would take about a week.

-----


in my team we had the scripts ready for a second provider (but not the hot backups, I couldn't get that far).

-----


Which of the assertions in the post do you disagree with?

-----


None, it's good work.

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.

-----


My experience in large companies is more like this: A (security) engineer reviews, objects and management says: "Go ahead anyway you don't have the whole picture".

-----


Apparently, he is not competent enough to understand what "this is not our actual code but merely a POC" means.

-----


It's not exactly a proof of concept if it doesn't protect the keys, is it?

It strongly hints that even if this is 'only a POC' that their actual implementation is still vulnerable since their POC failed to protect against the very attack is was written to protect against.

-----


Yes. Our actual implementation was vulnerable. We disabled TLS heartbeat before 5 April 2014, so are not still vulnerable.

-----


This would have been a cutting bit of wit indeed, had Akamai not stepped on your moment by confirming Willem's central thesis. Ouch.

-----


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.

-----


Here's a patch that prevents any exploit ever occurring in OpenSSL:

    void *custom_malloc() {  }; 
It's only a POC though so you'll have to adapt it. You can go ahead and begin praising me and flaming my critics.

-----


I was trying to get a copy of my transaction history at the time, after someone mentioned it might be handy in a class action suit

First the server started responding "this page does not exist" then just blank response

---

http://data.mtgox.com/api/2/BTCUSD/money/ticker

is still online right now

---

http://www.reddit.com/user/SarahCoinBit

It was a pleasure serving this community..marion and myself just got laid off.

(very likely fake...)

---

http://siliconangle.com/blog/2014/02/24/coinbase-blockchain-....

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

http://www.domaininvesting.com/andy-booth-sells-gox-com/

---

http://www.scribd.com/doc/209050732/MtGox-Situation-Crisis-S...

likely fake "MtGox Situation Crisis Strategy Draft" suggesting coins went missing over a long period

---

http://goxbalance.com/

not scientific but interesting

---

http://support.mtgox.com/

has gone down - just a zendesk "no account" page

---

http://www.reddit.com/r/BitcoinMarkets/comments/1yuuok/daily...

good reddit overview comment

---

(11:27:31 PM EST )something changed in the output of http://data.mtgox.com/api/2/BTCUSD/money/ticker; a unicode character

  "value":"96836.53176413","value_int":"9683653176413","display":"96,836.53\u00a0BTC","display_short":"96,836.53\u00a0BTC","currency":"BTC"},"last_local
---

(11:30 PM EST) LTC/EUR showing up in https://data.mtgox.com/api/2/LTCUSD/money/ticker

  "value":"0.00000000","value_int":"0","display":"0.00\u00a0LTC","display_short":"0.00\u00a0LTC","currency":"LTC"},"last_local":  {"value":"0.00000","value_int":"0","display":"0.00\u00a0\u20ac","display_short":"0.00\u00a0\u20ac","currency":"EUR"},"last_orig"
---

http://recode.net/2014/02/24/the-mt-gox-bitcoin-exchange-has...

“Mt. Gox has confirmed it will file bankruptcy in private discussions with other members of the bitcoin community.”

(Re/code has so far been unable to independently verify that claim)

---

http://www.reddit.com/r/Bitcoin/comments/1yuyx4/hey_charlie_...

takeover rumours from Charlie Shrem

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: