Qubes 1.0 Release Candidate 1!

I would like to announce the release of Qubes RC1. The installation ISO and instructions can be found here.

This release is expected to essentially be identical to the final 1.0 release, which will likely follow in the coming weeks, except for some minor, cosmetic fixes.

Comparing to the previous Beta 3 release, the major changes and improvements in this version include:

• A much improved Qubes Manager, that now allows to configure and manage almost every aspect of the Qubes system using a simple and intuitive GUI.
• All the VMs are now based on Fedora 17 template.
• Cleaned up and improved command lines tools for both Dom0 and for the VMs.
• Updated Dom0 and VM kernels are now based on 3.2.7-pvops kernel, which offer better hardware and power management support.
• Convenient menu improvements, that include e.g. a handy icon for launching a Disposable Web browser in a Disposable VM.
• Support for “yum proxy”, which smartly allows to update packages in a template VM (or other updateable VM), without requiring to grant general HTTP access for this VM. This has been a problem before, as the Fedora repos use hundreds of mirrored yum servers, and it wasn't possible to setup a single rule in the firewall VM to allow only access to the yum servers, and nothing else. Now, this is possible, and the primary application is to prevent user mistakes, e.g. against using the temaplate VM for Web Browsing.
• We also added support for an opt-in fullscreen mode for select VMs.
• ...plus lots of other improvements and fixes under the hood. As can be seen in the wiki, there has been over 200 tickets closed as part of the work on this release!

So, again, this is almost the final release, please test it and report any problems to the mailing list, so that we could fix them before Qubes 1.0 comes out officially.

Some comments on "Operation High Roller"

About a year ago I wrote about Why the US "password revolution" won't work, where I pointed out that a massive move towards two-factor authentication will not solve any of the identity theft problems that users experience today. Specifically, I wrote:

[People] don't understand that the [compromised] operating system can impersonate the user at will!

The compromised OS could have saved your PIN to this [smart] card when you used it previously (even if you configured it not to do so!) and now,  immediately, it could use the inserted card to authenticate as you to the bank and start issuing transactions on your behalf. And you won't even notice this all, because in the meantime it will show you a faked screen of your banking account. After all, it fully controls the screen.

The bottom line is that we cannot secure our digital lives, if our client operating systems could not be secured first.

But introduction of tokens won't make our operating systems any more secure!

This article sparked lots of controversy with many people, who considered it a fallacy to criticize two factor authentication...

Today, I came across the news about Operation High Roller, discovered recently by McAfee and Guardian Analytics. They released a paper with some details about the attacks and the malware deployed. Some interesting quotes:

All of the instances that involved High Roller malware could bypass complex multi-stage authentication. Unlike recent attacks that collect simple form authentication data—a security challenge question, a one-time token, or PIN—this attack can get past the extensive physical (“something you have”) authentication required by swiping a card in a reader and typing the input into a field (see Two-factor Authentication sidebar).

The attack asks the victim to supply the information required to get around the physical controls of smartcard reader plus pin pad entry to generate a one-time password (or digital token).

Having collected all the information it requires for the entire transfer, the malware stalls the user and executes its transaction in the background using the legitimate digital token.

Multiple after-the-theft behaviors hide evidence of the transaction from the user. For example, the client-side malware kills the links to printable statements. It also searches for and erases confirmation
emails and email copies of the statement. Finally, it also changes the transactions, transaction values, and account balance in the statement displayed on the victim’s screen so the amounts are what the account holder expects to see.

Defensive security is a difficult game, because one doesn't immediately see whether a given solution works or not. This is in stark contrast to other engineering disciplines (and to offensive security) where one usually have immediate feedback on whether something works well or not.

Say you want to build a redundant long-range video downlink for your unmanned, remotely operated helicopter -- you can throw in lots of money buying various high-gain antennas, circular antennas, antenna trackers, diversity systems, etc., but then ultimately you can verify your creation immediately by going into a field and trying to fly a few miles away, and see whether you loose the vision (usually in the middle of some life-threatening manoeuvre) or not. At least you can draw some lines of how good your solution is ("I can fly up to one mile away, but not more, unless there aren't that many trees around and the air is dry enough").

With security, especially with computer security, it is so different, because there is no immediate feedback. This results in various vendors pitching their products as wonderful solutions that just solve all the worlds problems, even though what they're saying in those marketing materials might be pure nonsense... (BTW, congrats to Simon Crosby for apparently creating a Windows-hosted VMM in below 10k LOC! ;)

The often made mistake is to say: "Perhaps there is a way to attack this solution, but then again, how much of the malware in the wild implements such attacks?" This is a classical thinking in our industry, and in my opinion, an inexcusable mistake! Let me say it clearly:

It doesn't matter whether what the malware in the wild does -- it matters what it could potentially do!

So, if we can do a quick brainstorming session and point out potential attacks within 1 hour against some technology/product X, then, if we don't see a solution how to prevent them generically, we should not bother and implement product X, because it will be defeated, sooner or later. Let's not waste time on useless solutions, life's too short!

Windows support coming to Qubes!

Ok, let's start with a screenshot :)

While the “Qubes 1.0” branch is currently in the final development and testing, we have already started working on the Next Big Feature, which is a support for HVM domains (hardware, or VT-x virtualized domains). This allows to run e.g. Windows VMs under Qubes. You might be wondering what so special about this, if Xen has been supporting HVM domains, and specifically Windows VMs for a long time, and Qubes uses Xen hypervisor, so why haven't we had Windows support since day one?

The are a couple of things that we don't like about HVM support in Xen (and also in other VMMs), which include: the need to run device emulator (AKA qemu) in Dom0, the need to use crappy VNC, or a similar protocol to access the VM's framebuffer, or alternatively, the crazy idea (from security point of view, that is) of using a pass-through graphics for a VM, the lack of support for disaggregated architecture where backends, e.g. network backends, run in other domains than Dom0. In fact even the Xen “stubdomain” feature, introduced a few years ago, that was supposed to be a solution allowing to move the qemu out of Dom0, in practice turned out to be quite disappointing, as the qemu in the stub domain still requires an accompanying process of another qemu in Dom0, somehow negating all the security benefits this architecture is supposed to bring... And not to mention the omni present assumption that backends run always in Dom0, hardcoded in a few places in the stubdomain code.

So, we didn't like it and that's why Qubes had no Windows support for long time. But this has now changed, as we have just finished the 1^st stage implementation of HVM support in Qubes, the way we like it, without any security compromises. In our implementation we've completely eliminated all the qemu remains from Dom0 (it's running in a micro stub domain), the graphics virtualization fully integrates with our very slim GUI daemon (we didn't have to modify our GUI daemon at all!), using our Xen-optimized, zero-copy, minimalist GUI protocol, and the networking is also fully integrated with the Qubes diaggregated networking architecture that uses isolated domains for all the networking stacks and drivers. Of course, there are still some rough edges, such as no clipboard support, and the virtualization is currently in a “per-desktop” mode, rather than in a “per-window” mode, which is used for PV domains. But, rest assured, we are working on those things right now...

This code is currently not public, and the plan is to release it only after Qubes 1.0 release, either as an upgrade, or as Qubes 2.0. All the dom0 code for HVM support will likely remain GPL, while any Windows-specific code (agent code) will likely be proprietary.

Qubes Beta 3!

-->

A new ISO with the just released Qubes Beta 3 is now available for download here.

Beta 3 fixes lots of annoying problems discovered in Beta 2 and earlier releases, and also implements a bunch of useful feature:

This includes the qvm-block tool and infrastructure for easy attachment of block devices to any AppVM, no matter which system VM is handling the actual USB controller. So, this allows to have untrusted USB domain(s), almost seamlessly integrated in the desktop system. One can consider to use it in order to prevent various USB attacks. The next release (the 1.0) will bring this feature to the Qubes GUI manager as well, making it easy to use for non-command-line users too.

Also, we have now introduced fully automatic Qubes build system, that allows to build all the Qubes packages, and also create the installation ISO, with just one command. More information on this system and on how to use it can be found in the wiki.

We have also updated to Fedora 15-based template as a default. Unfortunately F16-based template would require too much work to get all the Gnome 3 stuff working correctly. (The challenge here, is that we don't run a normal Windows and Desktop manager in every domain, in order to make the VMs light weight, and so we need to sometimes work around various problems this causes...).

Finally, we have added two new Qubes-specific applications:

• A plugin for Thunderbird (it is automatically installed in the template), that allows for one click opening of attachments in Disposable VMs, as well as one-click saving of the attachment to select VM.

• And something we call “split GPG”, that I will describe in a separate article later.

Those Qubes-specific applications are based on our Qubes RPC, introduced in Beta 2.

This is likely the last release before the “final 1.0”, that is scheduled to follow soon (TM). The only major work for 1.0 is GUI manager improvements to expose most of the Qubes functionality via clickable GUI, and command line tools cleanup and documentation. Plus testing and bugfixing :)

And then, the next thing we will be working on will be support for HVM domains, e.g. Windows. This work is starting actually just about now, but code will be released only after Qubes 1.0.

Thoughts on DeepSafe

Several people asked me recently what I though about DeepSafe. So, below I present my opinion...

First, for any AV system (or Host IPS, or Personal Firewall, etc) to work effectively, there are three problems that must be addressed:

1. How to protect the AV agent (code and data) from tampering (from the rest of the OS)?
2. How can the AV agent get reliable access to (sensitive pieces of) the system memory and registers, and/or provide reliable memory protection for the (sensitive pieces of) the OS.
3. What are those "sensitive pieces of” memory that should be monitored or protected?

From reading various PR materials, it seems like the #1 above is the primary differentiation factor for DeepSafe (DS). So, let's consider this problem in the context of e.g. a Windows OS. In order to protect its code and data, DS uses, as it is heavily advertised, Intel VT-x virtualization technology. Now, that sounds really secure -- after all what can be more secure than a hardware virtualization, right? ;)

But VT-x (including EPT) is only about CPU virtualization, which in our case translates to protecting the DS memory and registers from CPU-originating accesses. But, as every regular to this blog knows, there is also another method of accessing memory on any PC system, and this is through DMA transactions from devices. The OS (so also the kernel malware) is free to program one of the many devices in the system to issue DMA reads or writes to any physical memory it wants...

Now, in order to protect some portion of the system memory (DRAM, cache) against DMA accesses, we have the Intel VT-d technology... So, one would think that DS must be also using VT-d in order to protect itself.

Very well, let's assume then that the DeepSafe is not a total ripoff, and that it implements also VT-d protection for its agent, although I haven't found this mentioned in any of the public papers or press materials I found on the web...

This, however, would be a bit complex to do correctly, because the OS (so, also the kernel malware) still has a full control over the chipset (MCH), which is the entity... that controls the VT-d.

Now, in order to prevent the OS (or the kernel malware) from playing with the chipset for fun and profit, and e.g. disabling VT-d protection, DS would have to virtualize the chipset.

If you look at some consumer VMMs, such as VMware or Xen/Qemu, you would see that they all virtualize the chipset for their guests (of course), but that the chipset they provide this way is some kind of an ancient Pentium MCH. I don't think any of the consumers would be especially happy if they found out that after installing DS on their brand new 2012 laptop, Windows suddenly see a Pentium-era chipset... And this is not without a reason – chipsets, specifically MCHs, are one of the most complex devices, perhaps only beaten by GPUs in this category. There are virtually hundreds of configuration registers exposed by the chipset, some of them control the VT-d, some other control system memory maps and permissions, PCIe configuration, and many other things that I even have no idea about, and this all makes virtualizing the chipset a very challenging task.

So, it's either that McAfee and Intel found some interesting way of how to securely virtualize the chipset while preserving all of its (very rich) functionality, or that they... don't bother with VT-d protection and chipset virtualization at all, assuming that even without VT-d, DeepSafe is good enough and “rises the bar” anyway (sarcasm intended).

(Can somebody from McAfee or Intel confirm in the comments below what does DP really do?)

Anyway, let's assume they do have VT-d protection and they do virtualize the chipset somehow...

Now, we're moving on to the #2 point from the list of tasks above -- about the reliable

memory access or reliable protection.

So, let say that the DS agent decided that some part of the system memory, e.g. the IDT table, is sensitive and should be monitored/protected. So it sets up EPT traps to trigger an VT-x/EPT intercept on any access to that memory (or IDT base register), in order to find kernel malware that tried to modify IDT. That sounds really nice, but what if the malware uses DMA to modify IDT? DS would not be able to catch such access! (So far we considered the, hypothetical, use of VT-d only to protect the DS agent code).

One might think that DS is programming VT-d to sandbox each and every device in the system (so including GPU, USB controllers, NICs, SATA, etc) so they never be allowed to touch any of those sensitive parts of the system, such as IDT. Let's assume they do it this way...

And here we've arrived to the last point from the list at the beginning: which of the system memory constitutes those "sensitive pieces" that should be protected/monitored? IDT? Sure. What about all the code sections of the all the kernel modules? Yes. Are we fine now? Well, no, because the malware can hook some pointers other than the well known IDT. Some public NDIS data structure? Ok, we can add those to the protected areas. But, what about some undocumented NDIS structures? And this is just NDIS subsystem, one of the many subsystems in the Windows kernel... When we think about it, it should be intuitively obvious that in a general purpose Operating System like Windows, it is not possible (at least for 3^rd party) to make a satisfactory list of all the sensitive pieces of memory that should be monitored/protected, in order to detect all the system compromises.

Greg Hoglund, Jamie Butler, Alex Tereshkin, and myself, have been researching this area actively in the early years of this millennium. In addition to the Alex's paper linked above, you might also check out one of my last slides from this period.

I don't think anything has changed since that time. It was also the reason why I gave up on writing Windows compromise detectors, or forensic tools, and moved on to researching other ways to secure OSes, which finally gave birth to Qubes OS, many years later.

So, back to DS -- in order to provide a somehow satisfactory protection level for your general purpose OS, such as Windows, it would need to:

1. Use VT-d to protect its own memory,

2. Virtualize the chipset, at least some (sensitive) parts of it,

3. Program VT-d permissions for each device to exclude all the sensitive areas in the system that should be protected, and also protect one device from DMAing into/from another device memory (e.g. NIC stealing GPU framebuffer, or inserting instructions to the GPU instruction buffer, or keystrokes to USB controller buffer). Ideally, this could be done by programming VT-d to grant each device only access to its own DMA buffer, but as far as I know, this would be very hard to implement, if not impossible for a 3rd party, on a Windows OS (in contrast to Linux, which mostly support this model). Please correct me, if the recent Windows version allows for such use of VT-d.

4. Finally, and the most hard thing to solve, how to define all the "sensitive pieces of memory" in the system that should be protected and/or monitored? Although this is a somehow more generic problem, not specific to DS, but applying to any A/V, HIPS, or forensic tool.

So, is DeepSafe another piece of crap not worth any special attention, or has McAfee and Intel came up with some novel methods, e.g. for chipset virtualization, and other problems? Unless I see some technical info to backup the latter, I would have to assume, unfortunately, the former. But I would like to be mistaken – after all DeepSafe seems to be just a new incarnation of my Bluepill ;)

Trusted Execution In Untrusted Cloud

Wouldn't it be nice if we could actually own our data and programs in the cloud? By “owning” here I mean to have control over their confidentiality and integrity. When it comes to confidentiality and integrity for the data, it's not much of a rocket since, as the classic crypto (and secure client systems) is all that we need. I have already wrote about it in an earlier post.

But it would also be nice, if we could somehow get the same confidentiality and integrity assurance for our programs that we upload for the execution in the cloud...

For example, a company might want take their database application, that deal with all sorts of corporate critical sensitive data, and then upload and safely run this application on e.g. Amazon's EC2, or maybe even to some China-based EC2-clone. Currently there is really nothing that could stop the provider, who has a full control over the kernel or the hypervisor under which our application (or our VM) executes, from reading the contents of our process' memory and stealing the secrets from there. This is all easy stuff to do from the technical point of view, and this is also not just my own paranoia...

Plus, there are the usual concerns, such as: is the infrastructure of the cloud provider really that safe and secure, as it is advertised? How do we know nobody found an exploitable bug in the hypervisor and was not able to compromise other customer's VMs from within the attacker-hired VM? Perhaps the same question applies if we didn't decided to outsource the apps to a 3^rd party cloud, but in case of a 3^rd party clouds we really don't know about what measures have been applied. E.g. does the physical server on which my VMs are hosted also used to host some foreign customers? From China maybe? You get the point.

Sometimes all we really need is just integrity, e.g. if we wanted to host an open source code revision system, e.g. a git repository or a file server. Remember the kernel.org incident? On a side note, I find the Jonathan Corbet's self-comforting remarks on how there was really nothing to worry about, to be strikingly naive... I could easily think of a few examples of how the attacker(s) could have exploited this incident, so that Linus & co. would never (not soon) find out. But that's another story...

But, how can one protect a running process, or a VM, from a potentially compromised OS, or a hypervisor/VMM?

To some extent, at least theoretically, Intel Trusted Execution Technology (TXT), could be used to implement such protection. Intel TXT can attest to a remote entity, in that case this would be the cloud customer, about the hash of the hypervisor (or kernel) that has been loaded on the platform. This means it should be possible for the user to know that the cloud provider uses the unmodified Xen 4.1.1 binary as the hypervisor and not some modified version, with a built-in FBI backdoor for memory inspection. Ok, it's a poor example, because the Xen architecture (and any other commercially used VMM) allow the administrator who controls Dom0 (or equivalent) to essentially inspect and modify all the memory in the system, also that belonging to other VMs, and no special backdoors in the hypervisor are needed for this.

But let's assume hypothetically that Xen 5.0 would change that architecture, and so the Dom0 would not be able to access any other VM's memory anymore. Additionally, if we also assumed that the Xen hypervisor was secure, so that it was not possible to exploit any flaw in the hypervior, then we should be fine. Of course, assuming also there were also no flaws in the TXT implementation, and that the SMM was properly sandboxed, or that we trusted (some parts of) the BIOS (these are really complex problems to solve in practice, but I know there is some work going on in this area, so there is some hope).

Such a TXT-bases solution, although a step forward, still requires us to trust the cloud provider a bit... First, TXT doesn't protect against bus-level physical attacks – think of an attacker who replaces the DRAM dies with some kind of DRAM emulator – a device that looks like DRAM to the host, but on the other end allows full inspection/modification of its contents (well, ok, this is still a bit tricky, because of the lack of synchronization, but doable).

Additionally for Remote Attestation to make any sense, we must somehow know that we “talk to” a real TPM, and not to some software-emulated TPM. The idea here is that only a “real” TPM would have access to a private key, called Endorsement Key, used for signing during Remote Attestation procedure (or used during the generation of the AIK key, that can be used alternatively for Remote Attestation). But then again who generates (and so: owns) the private endorsement keys? Well, the TPM manufacturer, that can be... some Asian company that we not necessarily want to trust that much...

Now we see it would really be advantageous for customers, if Intel decided to return to the practice of implementing TPM internally inside the chipset, as they did in the past for their Series 4 chipsets (e.g. Q45). This would also protect against the LCP bus-level attacks against TPM (although somebody told me recently that TPM in current systems cannot be so easily attacked from LCP bus, because of some authentication protocol being used there – I really don't know, as physical attacks have not been the area we ever looked at extensively; any comments on that?).

But then again, the problem of DRAM content sniffing always remains, although I would consider this to be a complex and expensive attack. So, it seems to me that most governments would be able to bypass such TXT-ensured guarantees in order to “tap” the user's programs executing in the cloud provides that operate within their jurisdictions. But at least this could stop malicious companies from staring up fake cloud services with an intent to easily harvest some sensitive data from unsuspecting users.

It seems that the only way to solve the above problem of DRAM sniffing attacks is to add some protection at the processor level. We can imagine two solutions that processor vendors could implement:

First, they could opt for adding an in-processor hardware mechanism for encrypting all the data that leave the processor, to ensure that everything the is kept in the DRAM is encrypted (and, of course, also integrity-protected), with some private key that never leave the processor. This could be seen as an  extension to the Intel TXT.

This would mean, however, we still needed to relay on: 1) the hypervisor to not contain bugs, 2) the whole VMM architecture to properly protect VM's memory, specifically against the Dom0, 3) Intel TXT to not be buggy either, 4) SMM being properly sandboxed, or alternatively to trust (some parts of) the BIOS and SMI handler, 5) TPM's EK key to be non-compromised and verifiable as genuine, and 6) TPM bus attacks made impossible (those two could be achieved by moving the TPM back onto the chipset, as mentioned above), and finally, 7) on the encryption key used by the processor for data encryption to be safely kept in the processor.

That's still quite a lot of things to trust, and it requires quite a lot of work to make it practically really secure...

The other option is a bit more crazy, but also more powerful. The idea is that the processor might allow to create untrusted supervisors (or hypervisors). Bringing this down to x86 nomenclature, it would mean that kernel mode (or VT-x root) code cannot sniff or inject code into (crypto-protected) memory of the usermode processes (or VT-x guests). This idea is not as crazy as you might think, and there has even been some academic work done in this area. Of course, there are many catches here, as this would require specifically written and designed applications. And if we ever considered to use this technology also for client systems (how nice it would be if we could just get rid of some 200-300 kLOC of the Xen hypervisor from the TCB in Qubes OS!), the challenges are even bigger, mostly relating to safe and secure trusted output (screen) and, especially, input (keyboard, mouse).

If this worked out, then we would need to trust just one element: the processor. But we need to trust it anyway. Of course, we also need to trust some software stack, e.g. the compilers we use at home to build our application, and the libraries it uses, but that's somehow an unrelated issue. What is important is that we now would be able to choose that (important) software stack ourselves, and don't care about all the other software used by the cloud provider.

As I wrote above, the processor is this final element we always need to rust. In practice this comes down to also trusting the US government :) But we might imagine users consciously choosing e.g. China-based, or Russia-based cloud providers and require (cryptographically) to run their hosted programs on US-made processors. I guess this could provide reasonable politically-based safety. And there is also ARM, with its licensable processor cores, where, I can imagine, the licensee (e.g. an EU state) would be able to put their own private key, not known to any other government (here I assume the licensee also audits the processor RTL for any signs of backdoors). I'm not sure if it would be possible to hide such a private key from a foundry in Hong Kong, or somewhere, but luckily there are also some foundries within the EU.

In any case, it seems like we could make our cloud computing orders of magnitude safer and more secure than what is now. Let's see whether the industry will follow this path...

Exploring new lands on Intel CPUs (SINIT code execution hijacking)

Today we're releasing a new paper where we describe exploiting a bug in Intel SINIT authenticated code module that allows for arbitrary code execution in what we call an “SINIT mode”. So, to the already pretty-well explored “lands” on Intel processors, that include ring 3 (usermode), ring 0 (kernelmode), ring “-1” (VT-x root), and ring “-2” (SMM), we're now adding a new “island”, the SINIT mode, a previously unexplored territory inhabited so far only by the Intel-blessed opcodes.

What is really interesting about the attack are the consequences of SINIT mode hijacking, which include ability to bypass Intel TXT, LCP, and also compromise system SMRAM.

It's also interesting how difficult was this vulnerability for Intel to patch, as they had to release not only updated SINIT modules, but also updated microcode for all the affected processors, and also work with the BIOS vendors so they release updated BIOSes that would be unconditionally loading this updated microcode (plus provide anti-rollback mechanisms for both the BIOS and microcode). Quite an undertaking...

You can get the paper here.

Intel also published an advisory yesterday, which can be downloaded from their website here. The advisory is peculiar in a few ways, however...

First, the advisory (I'm referring to the revision 1.0) never explicitly mentions that the attack allows to bypass TXT launch itself, only that the attack “may compromise certain SINIT ACM functionality, including launch control policy and additionally lead to compromise of System Management Mode (SMM). Intel also recommend to disable TXT altogether in the BIOS, as a preventive measure, in case the user doesn't “actively running Intel® TXT”... This reminds me how various vendors started actively disabling Intel VT-x after certain virtualization rootkits have been demonstrated some 5 years ago, and how many laptops still ship with this technology disabled today (or VT-d at least) to the questionable delight of many users.

Second, the advisory assigns only an “Important” rating to this vulnerability, even though another Intel advisory, published some two years ago for a problem also reported by us, and which which was strictly a subset of the current vulnerability in terms of powers that it gave to the attacker (in other words the current vulnerability provides the attacker with everything that the previous one did, plus much more), was given a “Critical” rating... This is called evolution, I guess, and I wonder what would be considered critical by Intel these days?

UPDATE (Dec 7th, 2011): Intel has just released an updated advisory (release 1.1) that now explicitly states that the vulnerability also bypasses Intel TXT.

This is the last paper co-authored with Rafal Wojtczuk, who recently decided to try some new things and to leave ITL. Rafal has been the most talented exploit writer I have worked with, and I will surely miss his ingenious insights, such as e.g. how to practically win an absolutely hopeless race condition with ICMP-delivered MSI! But then again, how many times can one break Intel technologies, before getting bored? At the same time ITL is really transforming now into a development company, with all our efforts around Qubes and architecting, rather than on breaking. I wish Rafal all the best with his new endeavors, and thank him for all the excellent contributions he made while working for ITL over the past 3+ years.