Skip to content

Security Fiasco: Why small is necessary but not sufficient for security

“Small is beautiful” is nowhere more true than it is in security. The smaller a system’s trusted computing base (TCB), the more feasible it is to achieve a reasonable degree of security. The TCB is the part of the system that must be trusted to perform correctly in order to have any security in the system. It includes at least parts of the hardware (processor, memory, some devices) and the most privileged part of the software, i.e. the operating system (OS) kernel, and, for virtualised systems, the hypervisor.

This is one of the strongest justifications for microkernels: you want to absolutely minimise the OS part of the TCB, by using a kernel (the part of the OS running in privileged mode) that is kept as small as possible. Kernel size is minimised by only including the minimum functionality, i.e. fundamental mechanisms, and leaving implementation of other functionality, including all policy, to (unprivileged) user-mode software.

We have built the seL4 microkernel on this insight, and taken it to its logical conclusion, by mathematical proving the correctness (“bug freedom”) of the implementation, as well as general security properties. These proofs are critically enabled by seL4’s small size (about 10k SLOC).

But while (barring dramatic technological advances which are many years away) security requires small size, this doesn’t mean that a kernel is secure just because it’s a microkernel!

A case in point here is the Fiasco.OC microkernel (also called the L4Re Microkernel – Fiasco.OC is the kernel and L4Re is the userland programming environment built on top). Some propagate Fiasco.OC as the core of a national security competency and advocate it as the base for the development of a national security infrastructure. Sounds like a good idea, after all, it’s a microkernel?

Turns out, it’s not. Turns out, Fiasco.OC (besides being not all that “micro”, weighing in at about 20–35k SLOC depending on configuration) isn’t secure after all, and most likely can’t be made secure without a comprehensive re-design.

Details are provided in a paper by researchers from the TU Berlin (and interestingly the lead author is a former member of the Fiasco.OC team). It shows that Fiasco.OC’s memory management functionality provides covert storage channels of significant bandwidth.

The mechanisms underlying those channels are the result of design flaws of Fiasco.OC’s memory management, which, on the surface, is driven by security needs. Specifically, Fiasco.OC provides an abstraction of per-partition memory pools. However, these are part of a global management structure that breaks isolation. In short: Fiasco.OC’s “partitioned” memory pools ain’t.

The deeper cause for this breakdown of security is that Fiasco.OC violates a core microkernel principle: that of policy-mechanism separation. The microkernel is supposed to provide policy-free mechanisms, with which policies are implemented at user level. In contrast, Fiasco.OC’s memory management encapsulates a fair amount of policy, and it is exactly those policies which the TUB researchers exploited.

This is a nice example that demonstrates that you’ll pay eventually when deviating from the core principle. Usually the cost comes in the form of restricting the generality of the system. Here it is in the form of a security breakdown. (Ok, for purists, that’s also a form of restricting generality: Fiasco.OC is restricted to use in cases where security doesn’t matter much. Not very assuring for those propagating it as a national security kernel!)

Given the size of Fiasco.OC (2–3 times that of seL4) and the lack of understanding of security issues that seems to have affected the design of its memory management, one must suspect that there are more skeletons hiding in the security closet.

This all is in stark contrast to seL4, which has been designed for isolation from the ground up, including radically eliminating all policy from memory management. This approach has enabled a mathematical proof of isolation in seL4: In a so-called non-interference proof that applies to the executable binary (not just a model of the kernel), folks in my group have shown that a properly-configured seL4 system enforces isolation. The proof completely rules out attacks of the sort the TUB researchers have levelled against Fiasco.OC!

To be fair, seL4’s security proofs only rule out storage channels, while leaving the potential for timing channels. This is, to a degree, unavoidable: while it is, in principle, possible to prevent storage channels completely (as has been done with seL4), it is considered impossible to completely prevent timing channels. At least seL4 has a (still incomplete) story there (see our recent paper on assessing and mitigating timing channels), with more work in progress, while Fiasco.OC has known unmitigated timing channels (in addition to the storage channels discussed above).

Building security solutions on secure microkernel technology is good, and I am advocating it constantly. But it will only lead to a false sense of security if the underlying microkernel is inherently insecure. seL4, in contrast, is the only OS kernel with provable security. Use it as the base and you have at least a chance to succeed!


Cyber-security: We must and can do better!

Security, especially of embedded/cyber-physical systems, including cars, aeroplanes, communication devices, and industrial control, has become a hot topic this year. For example, a  report on the state of IT security recently published by the German BSI (Federal Office for IT Security) lists, among others, a targeted attack on a German steel mill that led to massive damage of the facility (p 31 of the report).

Such attacks are only going to become more frequent, and people are looking for solutions. Increasingly, people are starting to realise that the existing cyber-security “solutions”, such as software patches and malware scanners, are just doctoring with symptoms. (Very lucrative business for the “solution” providers: they know that there are lots of bad guys out there who find new compromises all the time, forcing their customers to keep buying the latest security “solution”.) The “catch, patch, match” approach advertised by the Australian Signals Directorate (ASD) is in line with this approach, and scary in its naïveté! (The description of threats is reasonable, but the proposed “solution” is amazing. And they mean it: I attended a talk given by an ASD general at a cyber-security conference, and the message was essentially “catch, patch, match and you’ll be fine”!)

In contrast, ASD’s colleagues at the BSI take a more active role, including working with industry to provide secure core technologies (Sect 4 of the above report). They note that there is a fair bit of indigenous cyber-security capability, which needs to be coordinated and supported to provide more comprehensive security solutions for German industry.

It would be nice if there was a similar realisation in the Australian government. With the seL4 microkernel we have developed at NICTA, we have unique expertise in the world’s most secure operating-system kernel and the associated verification technology. There is a significant number of NICTA alumni out there who are familiar with the technology, including some who are running their own businesses (e.g. Cog Systems). Together with them we’d be in the perfect position to develop really strong cyber-security solutions, and build a local, export-focussed cyber-security ecosystem.

But it seems others may beat us to it. For example, DARPA has just issued a SBIR call (SIBRs are research grants for small business) aiming at developing a security ecosystem around seL4. Other governments may follow (eg Germany is a prime candidate.) Much of this development will be open-source, and thus re-usable locally. But without government support for the local ecosystem, we’ll lose the massive head start we’re enjoying at the moment.

OK Labs Story Epilogue

What did I learn from this all?

Clearly, OK Labs was, first off, a huge missed opportunity. Missed by a combination of greed, arrogance and stupidity, aided by my initial naiveté and general lack of ability to effectively counter-steer.

That arrogance and greed is a bad way of dealing with customers and partners was always clear to me, although a few initial successes made this seem less obvious for a while. In the end it came back to haunt us.

Strategically it was a mistake looking for investment without a clear idea of what market to address and what product to build. We didn’t need the investment to survive, we had a steady stream of revenue that would have allowed us to grow organically for a while until we had a clearer idea what to grow into. Instead we went looking for investment with barely half-baked ideas, a more than fussy value proposition and a business plan that was a joke. As a result, we ended up with 2nd- or 3rd-tier investors and a board that was more of a problem than a solution. But, of course, Steve, being the get-rich-fast type, wanted a quick exit.

A fast and big success isn’t generally going to happen with the type of technology we had (a very few extreme examples to the contrary notwithstanding). Our kind of technology will eventually take over, but it will take a while. It isn’t like selling something that helps you improve your business, or provide extra functionality for your existing product, something that can be trialled with low risk.

Our low-level technology requires the adopter to completely re-design the critical guts of their own products. This not only takes time, it also bears a high risk. Customers embarking on that route cannot risk failure. Accordingly, they will take a lot of time to evaluate the technology, the risks and upsides associated with it, trial it on a few less critical products, etc. All this takes time, and It is unreasonable to get significant penetration of even a single customer in less than about 5 years.

So, it’s the wrong place for a get-rich-fast play. But understanding that takes more technical insight than Steve will ever have, and executing it requires more patience then he could possibly muster. And, at the time, I didn’t have enough understanding of business realities to see this.

What this also implies is that for a company such as OK Labs, it is essential that the person in control has a good understanding of technology (ours as well as the customers’). This is not the place for an MBA CEO (and Steve is a far cry from an MBA anyway). Business sense is importance (and I don’t claim I’ve got enough of it), but in the high-tech company, the technologist must be in control. This is probably the most important general lesson.

Personally I learnt that I should have trusted my instincts better. While not trained for the business environment, the sceptical-by-default approach that is the core to success in research (and which I am actively baking into my students) serves one well beyond direct technical issues. The challenge is, of course, that people not used to it can easily mistake it as negativity – particularly people who are not trained for or incapable of analysing a situation logically.

I’ve learnt that, when all a person says about stuff you understand well is clearly all bullshit, then there’s a high probability that everything else they say is all bullshit too. I should have assumed that, but I gave the benefit of the doubt for far too long.

As mentioned earlier, I also learnt that it was a big mistake to be a part-timer at the company. This could have worked (and could potentially be quite powerful) if the CEO was highly capable, and there was a high degree of mutual trust and respect and we were aligned on the goals. But I wasn’t in that situation, unfortunately, and my part-time status allowed me to be sidelined.

Finally, I always believed that ethics are important, in research as well as in business. The OK experience confirms that to me. Screwing staff, partners and customers may produce some short-term success, but will bite you in the end.

© 2014 by Gernot Heiser. All rights reserved.Permission granted for verbatim reproduction, provided the reproduction is of the complete, unmodified text, is not made for commercial gain, and this copyright note is included in full. Fair-use abstracting permitted.


OK Labs Story (9): The End Game

My October ’09 report to the Board was basically ignored. The more critical one of the investors was initially interested in following up, but in the end nothing happened. Steve obviously worked on him, but we also got, at a perfectly inopportune time, two deals which seemed to prove me wrong.

The AMSS disaster

One had started earlier, an Asian phone manufacturer wanting to build a “mass-market smartphone”, i.e. Android and modem stack on the same low-end (ARM9) processor core. I never understood why, and I was kept away from the customer or any real information from them, so I can only suspect that they were after an iPhone lookalike on the cheap (where looks would be more important than functionality).

So, we actually build a new product specifically for outdated hardware (the successor core ARM11, an ARMv6 implementation, was already in widespread use then). Technically it was a fun challenge. The project, code-named Marvin (the paranoid Android, paranoid because he’s never run on an ARM9 before) back-ported Android to ARMv5. The interesting bit was to get performance on the processor, which features a virtually-indexed, virtually-tagged cache. Windows as well as Linux deal with this cache by flushing it on every context switch, a performance killer. However, we had many years ago invented an approach to fast context switching on ARMv4/5, which made Linux faster by virtualising it; we used the same approach on the original virtualised phone, the Motorola Evoke. So we could run Android on that processor pretty much as fast as it could possibly be, and our engineering team made it work, of course.

The catch was that the customer was using Qualcomm chips, and was therefore running Qualcomm’s AMSS modem stack. So we had to port AMSS to the Microvisor. Technically this was not a big problem for our engineering team (and they did it just fine), but there was a legal issue: we did not have a source license to AMSS. The customer claimed that they had the rights to sub-license for the purpose. I voiced concerns at the board, resulting in a supposedly thorough analysis of the legal situation, which supposedly showed it was allright.

Obviously, the clean thing would have been to simply talk to Qualcomm, as they were bound to find out eventually. But for some reason Steve thought he could get away without telling them. (This is consistent with Steve’s 90-day horizon, he routinely goes for short-term gains even if this seriously damages long-term prospects, while my attitude is exactly the opposite.) It beats me why the rest of the Board followed.

Of course, Qualcomm eventually found out, and sent us a cease-and-desist letter, with which we complied. That (which happened after the presentation of my market analysis) was the end of this deal, but also of our once-great relationship with Qualcomm.

The poisonous Dash deal

There was another project which seemed to undermine my analysis, the only one that ever came through one of our investors. One of the directors had long-running high-level links with a major US network operator, let’s call them “Dash Mobile”. He got them to contract us for a prototype “mass-market smartphone”, running Android on an ARM9-based, single-core phone provided by another Asian manufacturer (not involving Qualcomm IP). Again, I never got enough information to understand why Dash was interested in this and whether their reasons added up. But, given the small size of the contract, it might be them just using some spare cash to investigate something which could be seen as having the potential for some market disruption, which Dash urgently needed (they weren’t going so great at the time).

Needless to say, the project went no-where (although that didn’t become obvious until after my departure). OK engineering delivered, as usual, and our overheads were low enough to be in the noise margin. But running a smartphone OS on the low-end processor did simply not result in a satisfying user experience (even with zero virtualisation overhead). But for a long time it seemed like a great project totally in line with Steve’s PR, contrary to what I was saying, and thus undermined my credibility. By the time I was proven right, it was too late. The timing of the Dash deal was disastrous.

In the end, the Marvin project was damaging in several ways. On the one hand we wasted a year or so, and millions of dollars, on developing a product for which there was no market, it was a complete waste. On the other hand it was a serious hit on morale in the engineering team: people had worked their asses off for many months, including regular work on week-ends, to meet the schedule. And in the end they saw that, while the work was technically good, the resulting product was useless. Several of the top people left after that.

Blood in the Board Room

Eventually I realised that I was powerless to do anything constructive in the company. Furthermore, 90% of frustration in my live originated from OK – in the mornings I dreaded looking at my email, which was full of shit having come in from Chicago overnight. At the same time, most of my fun came from research and working with bright students, and I was doing less and less of it. I decided I was too old to play such a masochist game and had to get out.

However, I thought I owed it to the many great OK engineers to at least make one more attempt to change things, unlikely as it was to succeed. So, in May 2010 I forced a bloodbath in the boardroom, and, predictably, the blood was mine, as the investors backed the CEO. Note that to this date we had a single quarter where company revenue and booking performance had matched the goals, and that was only because a large Motorola deal had come in late and spilled into a quarter that had low expectations; the sum of the two quarters was still well below expectations. But, of course, salvation was just around the corner, and we would soon be profitable. I have no idea why the VCs kept buying this…

The exit

I was given a face-saving 12-month consulting deal for leaving at the end of June ’10, and remained on the Board.

Incidentally, Benno left at the same time, voluntarily. The fundamental reason was the same: he couldn’t stand the bullshit and daily frustration any longer. (Benno and I are great friends again, I was invited to his wedding the following year, and his new startup Breakaway Consulting is a close partner of NICTA. We’re jointly developing eChronos, a verified unprotected RTOS which is already being licensed for medical implants. And he founded Cog Systems, the moral successor of OK Labs.)

The internal announcement of the departures was telling. I was asked to draft my own “to ensure it’s correct”. I kept it brief and focussed on simple, public facts, and, of course, didn’t praise myself, that would be the job of others. Steve mailed it out as is, with no attempt to mention my contributions to the company. In contrast, what Steve wrote about Benno was full of praise.

Nevertheless, were also both asked to pack up our desks after hours to avoid “unsettling” people. Steve has always under-estimated the intelligence of our engineers, and generally has no clue how they tick. People were already fairly unsettled, and the way I was farewelled clearly looked like a sacking to everyone. Given that the majority was there because of me, this obviously didn’t help morale at all.

While following Steve’s instructions to the letter, I did my best to counteract the effects on morale in engineering. I met up with them for lunch, putting up a cheerful face and taking positively about the whole development. Not sure how much this helped in the end, but it would certainly have been better than just vanishing the way Steve wanted me to.

The sale

With Benno and myself gone, the company had no-one left with a technical vision. All they could do from now on was implementing the designs Benno had made before leaving, and do whatever Chicago dreamt up. Needless to say, the company’s performance didn’t improve. The investors lost patience and wanted an exit: OK Labs was put up for sale.

The search for a buyer dragged on and on. Hardly surprising, of course, given that the “business plan” was a joke that didn’t hold up to scrutiny by anyone with technical insight. The “business plan” was built around our “enterprise strategy”, which basically meant “we’ll sell to enterprises” without any clue why they would buy from us, there was no value-add anyone could formulate in a way I could understand. Any real opportunities were outside that “strategy”.

Ironically, although maybe not surprisingly, by the time the company was finally sold, the only royalty deals we ever made were exactly in the two areas I had championed: automotive (where we may be in cars by now) and security (where there is at least one product in use by the military of a NATO country, probably more). But never a cent in royalties in consumer/enterprise mobile!

The strategy for the sale could only be to find someone interested in buying the engineering team (no longer the A team, a few individuals notwithstanding, but still very good) or the existing customer relationships.

What amazed me (despite all I had seen in the past) was the slide deck which was used to shop the company around. As part of the second investment round, OK Labs had acquired all rights to seL4 and its verification, and NICTA had delivered it sometime in 2010. Yet the sales deck didn’t mention seL4 a single time! The only obscure reference was the highly-misleading bullet point “World’s only fully verified Microvisor” (it’s seL4 that was verified, not the OKL4 “Microvisor”).

This is truly stunning! In 2011, MIT Technology Review listed seL4 in its “TR10”, what it judges the ten most important breakthrough technologies. So, OK sat on this truly unique technology, and the CEO had no clue what to do with it! Steve simply never understood seL4 and its potential. Which must make OK Labs the only company ever that owned a TR-10 technology but didn’t know what to do with it!

The way he came to his assessment that seL4 wasn’t of any use was a “market validation” exercise we had done earlier. It used the process Rob had used in the past at Wind River: You’ve got some ideas on how to evolve your product, so you go to all your customers and ask them what they thought about it. Which is a perfectly fine approach for a company with an established products it wants to improve, and an established, large customer base. In our case (where we had no relevant customers) we went to potential customers, all established players in their field and, effectively, asked them “hey, we’ve got this great technology that will completely disrupt your business, are you interested?” Can anyone guess the answer? But this is how strategy was decided at OK Labs.

The spoils

In the end, the company was sold to General Dynamics in August 2012, for a price that gave our investors more or less their money back.  None of the common shareholders saw a cent. In the dying days of the company, the investors had doubled as loan sharks, bridging the company at incredible interest rates, making double sure that there was nothing left for anyone else. (Actually, I was offered $1000 for signing away some irrelevant rights, which I declined, as being below my dignity.)

The only person who made a profit was the one who comprehensively fucked it up. Steve got about $900k in a combination of completion and retention bonuses (and on top of that may have retained the full-year separation pay he had written into his own employment contract). Isn’t the world of business wonderful?

© 2014 by Gernot Heiser. All rights reserved.

Permission granted for verbatim reproduction, provided the reproduction is of the complete, unmodified text, is not made for commercial gain, and this copyright note is included in full. Fair-use abstracting permitted.


OK Labs Story (8): Competitors and Markets


Early on we found that we were competing with two other players: Jaluna, later renamed VirtualLogix, and Trango, both from France (although Jaluna was headquartered in California).


Jaluna goes back to the early microkernel days: INRIA-spinout Chorus Systèmes, who prided themselves of having the first commercial microkernel (in the 1980s). Like other microkernels of the first generation, its performance sucked and it was practically unusable. They early on virtualised Unix on Chorus, but due to poor performance moved the Unix kernel into the Chorus kernel (like these days BSD is co-located with Mach in the Mac OS X kernel), which is no-longer virtualisation. Liedtke’s original L4 (in 1993) out-performed Chorus by a factor of ten!

Chorus had some deployments in the network-infrastructure market, and were eventually bought by Sun, but later closed down, and bought out by the original founders as Jaluna. 20-30 years after the original Chorus, their technology was still essentially Chorus, they don’t seem to have learnt much. They were “virtualising” Linux now, still by putting it into the kernel, something I call pseudo-virtualisation. In an earlier blog I joked about them taking my Advanced OS course so they could learn how to build performant microkernels… At some time they changed their name to VirtualLogix.

Their most noteworthy “achievement” was to demonstrate their loserdom with an incredibly shoddy paper published in the IEEE CCNC conference. They “showed” that their performance was way better than ours, which I knew not to be true (plenty of potential customers did their own evaluation showing this). I had fun in a series of blogs ripping that paper to pieces, and students in my Advanced OS course did similar. That paper was so full of fairly obvious defects, it should never have passed peer review. Needless to say, the conference is on my blacklist.

What almost certainly happened with their “performance” measurements is that they took our open-source version as is and built it blindly. The release had debugging and profiling enabled by default, which, of course is a performance killer. Any ethical comparative benchmarking would have disabled that.

VirtualLogix were later bought by Israeli device-management-software provider RedBend.


The other was Trango Virtual Processors, founded by a bunch of ex-ST Microelectronics employees. Trango was a hypervisor for ARM (and MIPS) processors. Their performance was much better, but bought with a 100% assembler implementation! This is good for performance, but implies huge costs for maintenance and adapting to changing conditions. And, while their founders might have been good hackers, they weren’t technology leaders the way we were.

Trango was later bought by VMware. I never understood why, and I don’t think VMware did. In fact, I believe they soon realised they bought a lemon. They marketed the Trango technology for a while as MVP (mobile virtualisation platform) but then went quiet, and about a year later came out with a new product under the same name, which shared nothing (probably not a line of code) with the original. It was essentially turning the Android Linux kernel into a hypervisor (KVM-style), to support running a second OS in a virtual machine. This was targeted to the “BYOD” business market, where enterprises would install a VM with the business (logical) phone on an employee’s handset. The problem is that this adds very little to security over just using the vanilla phone for accessing the enterprise IT infrastructure: As the hypervisor is the Android OS of the private (logical) phone, compromising it will automatically compromise the VM in which the business phone runs. They used encryption of data at rest to mitigate this, but that’s not really much more than window dressing.


Neither VirtualLogix nor Trango ever were a real threat: We never lost a deal we were directly competing with either of them (they may have won some we didn’t know about).


And we had many opportunities. Basically none were created by our (overpaid) sales force (except for Motorola deals generated by Tony/Josh). Instead, people were approaching us, from across a range of industry sectors. Some of them, especially automotive, appeared to me as great opportunities from the beginning. Of course, a startup has to focus, and Steve decided to focus on mobile. Why? There were no technical reasons, no real analysis of our value add, it was a simple calculation of >1 billion devices sold worldwide each year, if we can get on 20% of them and get $1 per unit, we’re rich. There was never any justification of why these figures were realistic, but Steve told the investors what they wanted to hear, and they lacked the insight to realise it was all bullshit.

For a while almost the whole marketing of our competitor VirtualLogix was directed at “single-core feature phones”, i.e. running a simple application OS and the modem stack on the same core. It was obvious that this would be, if at all, a very short-lived niche, given that the incremental cost of an additional core trended towards negative. In fact, I joked internally that if I was them and it’s all I had, I’d be very worried. Imagine my dismay when, about a year later, our marketing homed in on exactly that use case! Except we called it “mass-market smartphone”. The “mass-market” bit was to refer to the simple ARM9-based hardware of the then feature-phones, and the “smartphone” on the ability to run a smartphone OS (Android).

The thought that smartphone apps (even ignoring OS overheads) require grunty processors, and that it made no sense to share those with the baseband, wasn’t understood in Chicago (and, as I mentioned earlier, critical thinking was treason).

In this context I did a study of industry sectors, the role virtualisation could play in them, and attempted to quantify the value-add. I presented this at a phone conference of board members in October 2009. The conclusions I drew was that I could not see a significant value-add for our technology in mobile, no killer apps, and a low bar for entry for competitors, resulting in very low margins. In addition, VMware had it in their hands to reduce these margins to zero: royalties from the mobile hypervisor could hardly be central to their business model, so they could afford giving it away for free, and thus eliminating our margins. And soon a new competitor appeared: an approach from Columbia University to virtualise Android at the OS ABI level, which has the advantage of simplicity (the paper was published at SOSP in October ’11 and I had in fact reviewed and shepherded it, so I knew all about it). They created a startup going after the same market.

In my analysis, I concluded that I could not see the total addressable market exceeding $100M/a in this space, and that would be shared between many competitors with shrinking margins. Not an attractive place to be.

Instead my analysis identified two promising areas: automotive and strong security.


At the time we actually had traction in automotive: several component manufacturers had approached us. Despite Steve’s best attempts at chasing them away, some were highly persistent. I was particularly excited about one potential partner: OpenSynergy, a startup in Germany that came out of the research lab of a major car manufacturer. They had approached us and I had visited them as far back as July ’07. They started developing an automotive virtualisation product on top of our open-source microkernel and tried to negotiate a partnership agreement with us. Steve’s idea of “partnership”, however, was indistinguishable from “customer”: you pay and we deliver something to you (and that after long and painful negotiations Steve-style). They were perfect as a real partner: they had all the domain knowledge as well as excellent networks in the industry, both of which we were lacking.

Steve stuffed them around for two full years until they finally decided to go with someone else: German Sysgo (now bought by Thales) who had an aerospace (DO178-B) certified L4 clone named PikeOS. They would hardly have been happy with that marriage: I knew that PikeOS’s performance was miles away from ours, and we also knew from other engagements how performance-sensitive the automotive use cases were. Nevertheless, we managed to create a competitor out of nothing in a space we could (and should) have owned! Clearly this takes a special kind of talent.

Actually, in my “bullshit” mail folder I still have the mail Steve sent around OK Labs when OpenSynergy’s partnership with Sysgo was announced. He mailed around their press release with the subject line “1 Loser + 1 Loser makes for the Biggest Loser!” The conclusion was correct (although not as intended): the Biggest Loser was us, and that was immediately clear to me.

Our other engagement in the automotive space was with a company called ADIT, which is a joint venture of the two biggest automotive suppliers Bosch (Germany) and Denzo (Japan). Their German arm was developing integrated infotainment head units for Bosch, and they needed virtualisation to run automotive real-time components (with very strict real-time and performance requirements) concurrently with Linux-based infotainment stuff. Again, OK head office stuffed them around, apparently trying to make them feel that we’d be doing them a huge favour by engaging. Even when we had a development contract, they were not taken seriously, and insufficient resources allocated.

I still vividly remember one of the few customer meetings I had at that time. I was in Germany for CeBIT representing NICTA, and Abi thought I could really help rescuing the ADIT project, so I joined him for a half-day meeting in Hildesheim. The meeting superficially went fine, but during a break, ADIT’s Chief Purchaser took me aside and gave me (in German) the most serious dress-down I had experienced in my business career, calling OK Labs “the most unreliable outfit he’s ever dealt with”. This hurt deeply, because on the one hand I could see he was right, but on the other hand I knew that Abi (the technical sales guy whose project it was) as well as our engineers were doing their very best. In fact, ADIT engineers held ours in high regard (a recurring pattern). It was just head office fucking them around endlessly. Fortunately, things improved a lot after that meeting, and the project was, in the end, completed on schedule and to spec, and ADIT was happy with the outcome.

In automotive I could clearly see the value-add, and, while total numbers were less than in mobile, the addressable market looks way bigger. (Also, there’s a place for more than one hypervisor per car, which changes numbers significantly.) So I recommended making this area a main focus (despite having already missed the chance to own this market outright).


The second attractive space was strong security. Not the soft notion of “security” enterprises seem to be content with, where there are lots of simple “good-enough” approaches, such as VMware’s MVP, but the more paranoid groups like the national-security sector. This is where strong isolation, as we provided it, would matter. A typical use case (but there are others) would be to turn a more-or-less COTS phone into a secure communication device, a secure (logical) phone running on the same hardware as a soldier’s or emergency responder’s personal phone.

While this is a market with established suppliers (Green Hills, Wind River, LynuxWorks) I knew from what I could gather about their technology (as well as learning about evaluations from customers) that their hypervisors were unable to deliver the performance required, whereas we could. Obviously, in this space the number of sold units is much smaller than automotive (leave alone consumer mobile), however margins are much bigger. And we also had a number of exploratory projects, so there was clearly interest. Also, this was the space for which NICTA’s seL4 was made and would give us an unmatchable advantage, and a close collaboration with NICTA was core to my strategy.

Hence, my conclusions for the OK strategy were clear: avoid being trapped in a market with dubious value-add and shrinking margins (consumer mobile) and focus on the two domains where I could see an addressable market of significant size and we had significant competitive advantage: automotive and security.

© 2014 by Gernot Heiser. All rights reserved.

Permission granted for verbatim reproduction, provided the reproduction is of the complete, unmodified text, is not made for commercial gain, and this copyright note is included in full. Fair-use abstracting permitted.


OK Labs Story (7): The Investors

We had a total of three investors: In the first round we got an Australian VC. In the second round we got a US-based VC, plus Citrix as a strategic investor. Citrix only had observer status on the Board.

Fundamentally, the Board was weak.

One thing I learned is that Australian VCs have severe limits. Australia is a small pool, and VCs have to be very broad, which means they lack the technical expertise to really understand what they are investing in. In contrast, the top-tier Silicon Valley (“Sandhill Road”) VCs operate in a huge market, and specialise on particular segments, where they build up considerable expertise. Also, they have their Stanford and Berkeley professors at hand for in-depth technical assessments.

I saw this at play when we tried to raise a B round. None of the top-tiers wanted to bite, for obvious reasons: Our business plan was a combination of bullshit and wishful thinking. We had the best technology, but no inherent reason why it couldn’t be replicated (in fact, I knew I could take a half-dozen of the latest student generation and do it). And we had no convincing story of the value-add we were providing in the area we were targeting.

So, we ended up with a second- or third-tier VC, and it wasn’t a B round either, but a re-opening of the A round.

A top-notch VC not only brings in money, but also market insights and connections leading to deals. We didn’t get any of that from our VCs.

Steve had one of our directors eating out of his hand from early on, to the very end that person thought Steve was the greatest thing since bottled beer. He was a total walk-over for Steve. The other one was more critical, but didn’t really add much either. He probably noticed that there was a lot of BS, but couldn’t really dig deeper to keep the CEO honest. Which is actually quite an achievement by Steve, that they kept backing him despite never delivering on any of the sales or revenue targets. But the breakthrough was always around the corner, with all those great deals about to happen, and we were really just a couple quarters away from being cash positive…

The only deal our VCs ever got us was the fatal Dash one, but that’s for a later section. In the end, they were no more effective in holding Steve to account than I was, and they didn’t help develop the business at all.

Citrix should have been a chance, but they were restricted to observer status, and therefore couldn’t do much. Martin, the head of the Citrix CTO office who was the Board observer, saw through a lot of the bullshit, but wasn’t empowered to do much. Maybe it would have helped if I had built a closer relationship to him earlier.

© 2014 by Gernot Heiser. All rights reserved.

Permission granted for verbatim reproduction, provided the reproduction is of the complete, unmodified text, is not made for commercial gain, and this copyright note is included in full. Fair-use abstracting permitted.


OK Labs Story (6): The Management Team

Steve is an incredible networker (which helps collecting intelligence, he’s got an excellent machine for picking up market rumours). His network also includes a lot of people whom he can draw on as consultants or employees.

Early in the life of the company he moved back to Chicago, to set up the company headquarters there. We needed a US presence (and parent company) and Steve initially ran it from his home. He soon got an excellent deal for office space in the heart of the Chicago CBD, exactly opposite the Willis Tower. Chicago isn’t the most obvious place, and time-zone wise, the West Coast would have been better, but in the end I don’t think it mattered. Chicago is well-connected and Motorola’s mobile business (who should have been a major customer) was there.

He also went on to hire an executive team: CFO, VP Product Management, VP Marketing, all based in Chicago. The VP Sales (eventually also Chicago-based) took years, including some false starts: one resigned within 2 weeks for family reasons, and a French guy resigned after the first phone meeting (never met either, but maybe they sensed more issues than I thought?) Together with Benno and myself this comprised the initial executive team.

Generally the executives Steve hired in the first round were nice and decent folks, I liked working with them. Rob, the VP Product Management, was a much better choice for talking to engineers than Steve, he didn’t rub them the wrong way and didn’t bullshit. Dennis, the CFO, was a voice of sanity. Marti, the VP Marketing, built a great 3-body marketing team that achieved amazing visibility with a very small budget, they were full of cool ideas and executed quickly and effectively.

A clear issue was the lack of domain knowledge in the executive team. Some of the false-start Sales VPs had it, the eventual Sales VP didn’t (but tried to made up for it by Steve-style bullshitting). Rob came from Wind River and as such the embedded systems domain, which is at least related. He had held a senior position at Wind River, but that didn’t prepare him for defining a product strategy for a startup. In the end he mostly managed the product development process, while the actual product strategy came from Benno.

But the most crucial shortcoming of the executive team was that all but Benno (and me, and maybe Dennis in his quiet way) were yes-men/women, who didn’t ever challenge Steve, and this presumably is why they were picked. No-one who is willing to form and express their own opinion, or dares to confront wishful thinking with facts, is welcome in the Steve world. Such a person would have to go (as it happened with a number of non-executive staff, see Tony and Josh).

Chicago head office was this bizarre perfect world, where everything went to plan and everything always looked good. Benno called it the “reality-distortion field” that was created there, with all those fantastic deals that were just about to happen.

Obviously, such an environment, where fantasy is reality and critical thinking is treason, is a recipe for disaster. It is also extremely painful for someone who spends considerable effort developing bullshit detectors in his students. Unfortunately I had to get used to muting my bullshit detectors whenever I went into a meeting with Steve. Meetings in Chicago were this roller-coaster of having fun catching up with folks, especially our marketing team, and facing this deluge of bullshit. Can’t imagine how others survived that on a daily basis.

The obvious question is, why didn’t I try to do something about this earlier on? It’s a question I still struggle with, I can’t find an easy answer. I can’t claim that I didn’t see the problems, but somehow I felt too insecure to react properly. I also didn’t know how to react, and I didn’t have good mentors to turn to. And I was isolated on the Board.

© 2014 by Gernot Heiser. All rights reserved.

Permission granted for verbatim reproduction, provided the reproduction is of the complete, unmodified text, is not made for commercial gain, and this copyright note is included in full. Fair-use abstracting permitted.