Joanna Rutkowska leaves Qubes OS, joins Golem | Hacker News Reader

Joanna Rutkowska leaves Qubes OS, joins Golem

qubes-os.org

202 pointspentestercrab68 comments

FWIW: just over half of Latacora uses Qubes on a daily basis. We do that because "Xen VM" is a pretty great boundary; it allows me to have totally separate client environments with the convenience of a single laptop. (We've had a client have us use their endpoint before; while I generally like that client, we won't be doing that again :-))

It's not flawless. Sometimes switching to a big screen or moving USB devices between VMs is wonky... but the bottom line is I haven't booted my MacBook Pro for work in 2018. We stopped using MBPs because the then-current now one-minor-rev old generation is trash; all of them broke, and that was unacceptable, so I have a Lenovo (again).

Happy to answer questions about Qubes.

FWIW: not worried about Qubes' future. As Joanna herself points out in the blog post: Marek has been doing most of the technical day to day stuff for a while now, and Qubes has been doing just fine. I'm really thankful for the work Joanna has done in making Qubes happen and hope her new endeavors are everything she wants them to be :)

What's hardware compatibility like? Did/do you struggle to find good portable machines to run Qubes on with solid wireless/bluetooth support?

As somebody whose (trash) recently-current MBP just spent the weekend with Apple due to a display failure, I'm evaluating my options.

I have a T470 -- at the time the most recent T-series 14" Thinkpad. Everything pretty much worked fine? But that's just one data point. Perhaps if they're super new, you'll run into more issues. dom0 is hyperconservative with updates, so maybe you'll need to run testing-grade stuff to get all your hardware to work properly.

I think I had an issue with WiFi + suspend/resume but that was easy to fix, and fixed by default now. (It involves reloading the driver after resume -- that's automatic now but the setting lives in a config file.)

For what its worth the T4x0(s) series has been very good for Linux in general. We've been hopping the odd numbers every other year.

Bluetooth needs futzing around with in Qubes, for sure. It took me a while to figure out how to get my Bluetooth devices to pair/connect correctly and to persist that through reboots.

How is performance? My experience with normal VMs has always been that CPU performance is fine but doing anything with a GUI is very annoyingly slow/laggy.

I'd generally agree (CPU perf fine, GPU perf noticeably worse), but it's honestly fine for normal browser/editor use, even on my 4k@60Hz display. I do stuff like (digitally) sign documents and mild Inkscape/GIMP work. I wouldn't use it as a CAD machine.

have you used it with a docking station and multiple screens? if so what was your experience?

do you think Qubes will complete their effort with a live USB with persistence? what would be your opinion on using that?

Yes, docking station + 4k@60Hz + builtin laptop screen. Works fine, though there's an annoying bug where occasionally the updated screen sizes won't be reflected properly on the secondary screen. Reboot works as a workaround, I hear there's a less annoying one but I haven't tried it myself. So: not perfect, but not bad enough for me to throw it out :-)

Re: LiveUSB; I see the point for Tails. I don't see the point for Qubes. Is it "easy to try out"? Because the whole TemplateVM thing seems pretty core to how Qubes works and

How do you mean? There's a bug where the screen size inside the VM is not updated properly due to small allocation of VMEM for the graphics. It's a one line fix :)

What about performance of VMs that spans many cores? At work I need to compile a huge C++ codebase and it is important to utilize all the cores and almost all RAM.

From my use of Qubes:

* RAM hit is pretty big. 16gb was pretty much necessary for any type of work.

* CPU hit is decent. In Qubes, one of the applications I'm working on would build in 40s, on a "regular" OS it would take 20s.

The CPU hit is probably more variable and depends on many factors.

FWIW even though I really liked Qubes, I eventually moved away from it because maintaining the system took up a bit too much of my time. For the most part it "just works" (and huge props to the Qubes team for that!), but for example I had trouble upgrading my images at some point, which messed things up. I had backups (Qubes has a decent backup tool for which I had a bash script), but that was kind of the breaking point - I felt I had spent too much time futzing around with things. I think I used it for ~6 months. It's definitely worth trying out if you have the nerve to deal with those kinds of problems.

Agreed on the RAM bit. I have 32GB and it's sufficient. But keep in mind we have N customers, all with Slack, so our use cases are probably a little out of the ordinary.

> We've had a client have us use their endpoint before

What does that mean?

Endpoint means managed laptop in this context :)

Joanna's brilliant, and this Golem project is fascinating. The idea of a secure remote compute arrangement is sort of a natural extension from Qubes, and this is a pretty unique approach. May she (and Qubes, and Golem) find great success.

Reading the Golem website, I'm no longer sure that I 'get it'. Is this just a decentralized AWS or supercomputing service which is payable using $ThisWeeksHotCryptocurrency? Her description made it sound less like a marketplace for spare cycles and more like a thin-client sort of thing.

It's a Graphene SGX fork running docker containers so far.

In the end it is supposed to be a decentralised AWS/cloud computing service with the benefits that computation is more or less private (limited to no snooping) and (the actually important bit) with market driven pricing that seems to be driving the cost below that of AWS.

Sia and a number of other projects are trying to address hot and cold storage while Golem and company are addressing the compute. With some clever architecture design, these decentralised systems could be combined to make a decentralised remote server.

> a secure remote compute arrangement is sort of a natural extension from Qubes

I see what you mean, but on the other hand it's a threat to the endpoint security she's worked so hard on. If Intel offered a solution that allowed remote users to run code on your machine, no matter how secure they claimed it to be the response here would rightfully be 'what could go wrong?' Can it be made secure enough?

(I'm aware that Intel already offers such things, including via SGX which others in this discussion say is utilized by Golem.)

Sure, but at the same time, a big part of Qubes involved creating very secure jails for processes, which they could not escape. So, 'keeping untrusted stuff in its box' is sort of her expertise, and if anybody's going to do that right, it's probably her.

Chances are, the NSA won't be renting out Top Secret machines for Golem, but some rando with a multi-thousand dollar gaming rig she's just using to browse HN on may well view the tradeoff differently.

> some rando with a multi-thousand dollar gaming rig she's just using to browse HN on may well view the tradeoff differently.

I don't think so since you will immediately hear the difference in terms of fan noise. :-)

Seems like an acceptable tradeoff, like if it's cold in her room and she wants to get paid to heat it

You have a very naive view of the quality of isolation Qubes OS can provide. It is currently basically sanely configured Xen domains with some python helper scripts. There is nothing in the way Qubes OS does isolation that would suggest some exceptional expertise in process isolation. That kind of expertise is more appropriately sought in projects like sel4, Genode, etc.

Another "natural" direction would have been to work on the security of smartphones.

Considering the amount of pain going into fighting the million drivers and black-box chips in a commodity X86 box where you can run user code as root, I can't imagine a smartphone would provide anything but suffering for a Qubes-style security project. Unless, of course, $OEM was directly on board with the research or work, and willing to modify the software and hardware as needed.

Librem 5 from Purism, PinePhone from Pine64, Necuno Mobile from Necuno... even the DragonBox Pyra if you really stretch it. In 2018, it starts to seem doable again :P

That would probably turn into a silicon fabbing endeavor since almost everything that can talk to a cell network is proprietary

So someone should make a project to open this up?

That's not entirely true these days.

I have a ADALM-PLUTO sdr that can do duplex from 70MHz-6GHz. Only 5mW (7dBm) Tx.

But there is a Gnu Radio gr-gsm and gr-lte plugins to make your own client (cell phone) and server (tower). There was also a nice talk at DerbyCon that went further in what you need to do to handle tower ops.

These ICO-funded research projects are turning into the next Xerox Parc, IBM Research etc. I doubt they will ever ship something practical directly, or that the investing public will ever get their money back, but they are spending the money by hiring great engineers and researchers and giving them free rein to have fun with no budget restrictions. I suspect that will result in fundamental advances that will benefit us in the long term, like Darpanet eventually gave us the Internet.

I want to believe that something good will come of this, beyond incinerating cash building products nobody actually wants to use. (Yes, I’m saying that Golem as described is impractical and naive, and giving it so much funding so early makes it even harder for them to learn hard lessons and succeed as a product).

In a way, they found a way to trick us into paying more taxes to subsidize public research and development! You’ve got to respect that.

The difference is that unlike taxes, these research projects are 100% opt in and you get to pick which project to support.

I think most ICO participants expect something in return other than “lots of cool research that won’t be immediately practical, but might indirectly advance society in 20 years”. They expect either financial gain through speculation, or a successful launch of the product specified by the ICO whitepaper. They will most likely not get either of those things.

I wonder if this is really true. My understanding is that the majority of ICO funding actually comes from Bitcoin & Ethereum "whales" who got in early, own thousands of coins worth tens of millions of dollars, `and are looking for something cool to do with it that won't trigger a huge tax bill. (Well, technically investing in an ICO is a taxable event, but when you can just use your private key to send Ethereum from your pseudonymous address to a smart contract that exists everywhere and nowhere at once, enforcement is difficult.)

Most of the newbie Bitcoin investors I've met at meetups have been very wary of ICOs. Too risky; they won't go near them. Occasionally they'll be someone who spreads maybe 5% of their crypto portfolio across a dozen ICOs, but they're the die-hard exceptions.

If this is the case, the analogy really is more like Google X or YCombinator: an already-wealthy firm who spends money on passion projects because they can, with the potential added benefit of a small chance of an even bigger payoff down the road, and a nice PR boost in the meantime that increases the value of their primary holdings.

Generally probably true, but Graphene-ng looks pretty interesting and seems close to something that can be shipped.

Golem has the potential to solve the Cloud Trustworthiness problem, and it's an interesting problem one with huge upside if it we ever get there. How do we verify that the the code we're running (e.g. the VPN we have set up on a VPS in the cloud, or the web server we're connecting to) is actually running the code it says it's running?

Ethereum can do that (because it's just one giant computer running the same code and verifying it's state after every functional call), it's just really, really slow and insanely expensive. Perhaps they'll figure this out, if they do, it will be awesome.

Can solve it with TEEs (e.g. SGX). I think that's what they're working on.

>Ethereum can do that (because it's just one giant computer running the same code and verifying it's state after every functional call), it's just really, really slow and insanely expensive.

Also, everything on Ethereum is public.

Very interesting to see her joining Golem. I have been following them for many years and I'm excited to see what they produce, but they seem to have been in a holding pattern for a while unable to produce progress in some ways. I think she'll probably help solve that.

I'm not fond of the economics of Golem. I suspect they will not be able to compete with centralized solutions, as they have to support all sorts of redundancy to make things trustless. They could make it more federated, but then how is that better than AWS? And why do you need a token at all?

Most of those complaints could be said about cryptocurrency in general, such as Bitcoin, which by technical standards isn't very "efficient" compared to a centralized ledger.

Just as there are a lot of people out there that are interested in banking but not interested in playing at the scale of being a bank I think there are a lot of people interested in contributing to a decentralized computing infrastructure without having to create a large dedicated data center.

When you use AWS you're subjected to AWS pricing and AWS servers. A more open network where everyone can offer computing power has the potential to reduce the lock-in effect that all the big cloud vendors force upon their customers.

The initial goal of Golem was to be so efficient that the best way for big cloud vendors to offer their services would be through the Golem platform. That's obviously a moonshot, but it helps us to see what the Golem team is aiming for.

From her new project: https://golem.network/

>> Ethereum-based transaction system

Is this going to be fast enough for their use cases?

Sounds like FileCoin for CPU rental. Could be legit, especially as they're not creating their own token for this purpose. Nonetheless, by using Ethereum they're still committing to burning a lot of electricity - would be interesting to know if it's more or less power than used in the actual computation they're selling.

Ether is planning on moving to proof-of-stake rather than proof-of-work some time in 2019, which should help with the power consumption.

https://www.mangoresearch.co/ethereum-roadmap-update/

GNT is the ERC-20 token they use. Golem had an ICO last year. It would be really challenging to figure out how much power is used by a particular ERC-20 token given that mining is performed on the whole chain, not a token bybtoken basis.

It's worth mentioning Ethereum has been planning to switch to proof-of-stake (PoS) mining instead fo proof-of-work (Pow) for a long while now. They even have a "time bomb" built into their PoW algorithm they have to "reset" every once in a while because these original plans were more aggressive.

I'm not necessarily in favor of PoS, but it does "solve" the electricity concerns you are raising.

Also insert here long winded explanation of how much power is used by existing banking infrastructure.

>Could be legit, especially as they're not creating their own token for this purpose.

Maybe I am confusing them for another project, but I am pretty sure they do have a token model.

They mention it's based on ethereum, not currently their own token.

They have an ERC-20 token called GNT, it's a smart contract that runs on the eth network.

Edit, wrong parent reply, but I hope their market isn't entirely memecoin based, should let resources decide on the payments they want to take

Golem uses Intel SGX (specifically a modified Graphene-SGX libraryOS) for trusted execution if anybody is interested [1] https://software.intel.com/sgx

However, it's worth noting that SGX was affected by Foreshadow.

Looks like Joanna left the project in good hands. She says Golem raised money but the challenge to me seems being able to verify whatever computation is being done as trustworthy/correct. Unlike in crypto transactions, it becomes hard to build a trustworthy network where computation can be verified, especially because there are so many different kinds of computations available out there

Can't zkSnarks help with this? https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/

Oh no. From a serious OS project to a buttcoin startup. I guess these people are the ones that pay the big money these days…

Best of luck to her. It's sad to see her go; I still don't think Qubes OS is quite ready for prime-time yet.

why?

Another challenge is the trustworthiness of the x86 platform.

I can only imagine that's incredibly frustrating. Knowing no matter how hard you work on Qubes, x86 isn't really deserving of trust right now.

In case someone else is just learning about these folks: ITL is Invisible Things Labs.

You should use the proper title: * The Next Chapter: From the Endpoint to the Cloud

Counterpoint: Joanna is a highly regarded security researcher and this is big news for the Qubes project. I wouldn't have clicked on this link if it was presented with the generic title

Your counterpoint doesn't matter, this site's rules are very clear.
If you wouldn't have clicked the link, that's a pity, but that's something the article's author brought on himself.

rules are only useful when they serve their intended purpose.

herself

Herself.

I agree. A name sometimes conveys more information than a generic title.

Who is Joanna Rutkowska and what is Qubes OS :S

The first link of the top header is 'INTRO' leading to a page which literally has 'What is Qubes OS?' as the first h2.
The third link of the top header is 'TEAM' leading to a page where Joanna Rutkowska is the most obvious topmost item, appearing above the fold on many devices (even my phone!), complete with her title(s).
Sometimes comments make my day. This is not one of them. I am achingly speechless.

Reply on news.ycombinator.com