Open-source firmware

Hi Andrew! Thank you. I definitely took notice when PIA followed our lead and decided to donate to WireGuard as well. I suspect that was your initiative?

As far as innovation goes we published our vision for the VPN industry a few months ago. It's transparent and independently auditable VPN servers, through the use of System Transparency: https://mullvad.net/en/blog/2019/6/3/system-transparency-fut...

If you are interested in it you are more than welcome to join the implementation effort when we have put some basic things in place, or do your own thing right away. Above all it's important that we start moving in that direction as an industry. We don't really care who gets there first. It is also a more interesting game than the currently dominating one of affiliate marketing using hyperbolical and unverifiable security claims.

In a few weeks I will do a talk at the Open Source Firmware Conference together with our technology partner 9eSec ( https://9esec.io/ ), which will coincide with publishing a website as well as more planning of the implementation effort. As far as collaboration goes I have discussed System Transparency at length with IVPN many times, whose values and vision I find very well aligned with Mullvad's. We have an ongoing conversation with them about this and other things.

Thanks for the invite to chat, I agree it doesn't hurt to have a one-on-one talk. Even if Mullvad and PIA doesn't turn out to be a good fit for collaboration we should definitely share ideas on our vision for the VPN services market. Our perspective is pretty much all in the blog post about System Transparency. Looking forward to reading more about your idea "zero access". I'll reach out soon!

Thank you for the recognition! If you haven't read our blog post about System Transparency as a vision for more transparent and trustworthy computing I think you would enjoy it: https://mullvad.net/en/blog/2019/6/3/system-transparency-fut...

This port took roughly two-three weeks of full time work by an experienced firmware developer.

I'm not a firmware expert so take the following with a grain of salt. In general the more your target platform has in common with currently supported mainboards the easier it will be. First of all there obviously needs to be support for the instruction set architecture, then the CPU microarchitecture, and finally for the components on the specific mainboard you are targeting.

Given what has now been done by 9elements and others for SuperMicro boards based on Kabylake I expect more boards to be ported in the coming year.

As kfreds correctly states, there are important questions other than who the OEM for a mainboard is. With the exception of notebooks (where OEM specific components like the embedded controller require a fair bit of work that can be transferred from one device to the next), I'd even say that the OEM is among the least interesting bits about a mainboard on the technology side.

However, if the OEM supports the coreboot port (e.g. by providing schematics and generally answering questions that come up) that's very helpful.

So, question to kfreds: how was the cooperation with Supermicro? Are they aware of your effort, were they helpful?

(disclosure: doing coreboot development for 12 years now, some of that professionally, now for Google's Chrome OS devices)

Hi! Thanks for the question. It's an important one. Both the security of WireGuard as a protocol as well as its Linux kernel implementation are most likely superior to all alternatives. Code audits and age of the project function as signals for decision makers, but there are stronger signals, if you look deeper. The simplicity of the protocol state machine, the fact that it can be implemented without dynamic memory allocation, the cryptographic primitives used, and the lines of code required, are arguably equally or more useful. WireGuard is 4000 LOC, IPSec is 400,000 LOC and OpenVPN is of similar complexity. I don't expect Jason Donenfeld who has a background in kernel exploit development to write code that contains 100x more vulnerabilities than IPSec and OpenVPN. We have noted the prevalence of those arguments. Let's wait a while and see who was right.

As for the privacy issues with a "standard" WireGuard deployment we are well aware of them and are working with others to develop a standard which will hopefully be adopted by privacy-focused operators. Unfortunately we only highlighted them to others in January this year. Note that no criticism of WireGuard's privacy seems to be older than this email: https://lists.zx2c4.com/pipermail/wireguard/2019-January/003...

We have deployed solutions for some of WireGuard's privacy issues while others are in the pipeline. It should however be noted that some of the attack vectors are somewhat esoteric and quite unlikely, so we don't consider them critical. The devil is in the details, as you can read in my email above. On the whole we think WireGuard is where the industry should be heading, fast, for many reasons, and that's why we are spearheading it: https://mullvad.net/en/blog/2017/9/27/wireguard-future/

At the moment IVPN is slightly ahead of us in terms of privacy features in WireGuard, but they are the provider we probably have most in common with, and we frequently discuss projects like this one, so they are definitely the one we most expect competition and collaboration from: https://www.ivpn.net/knowledgebase/253/Using-WireGuard-for-P...

Sure! coreboot + LinuxBoot (with u-root) in the integrity-protected SPI flash memory, which then netboots (download and kexec) a Linux system. All artifacts need to be reproducible. For the CT Log probably trillian.

As for choosing this board, I alluded to it in a post down below. Note that I'm not a firmware expert though. Support for x86 was obviously already there, as well as for the microarch if I recall correctly, so "all" our technology partner 9eSec ( https://9esec.io ) had to do was support the specific board. Had we chosen another microarch or something with multiple CPUs we could have spent months on it. Just another example of how important it is to work with experts.

Well worth considering. Thanks! The best I can offer at the moment are our yearly review posts, but those are obviously written after the fact: https://mullvad.net/en/blog/2018/12/19/final-glance-year-app...

If you need it - you can't buy a fully auditable, fully open source, owner controlled x86 system at any price.

Also, you can buy a Talos II Lite or a Blackbird off the shelf for much less. There are options.

Yes, it absolutely can. However, the first part of good opsec is not lying to yourself about its shortfalls. Fantasy is thinking you can have a "fully open source firmware" for x86 systems, it just isn't - unless it's leaving out major parts of system initialisation and monitoring. Of course you can remove bits and pieces from the ME, but you can't guarantee that'll always be the case - Intel may not let you do so in the future when the next major microcode update comes out. That said, if you're going for cost cutting and as such you're willing to compromise on opsec, you won't beat major established VPN services on cost. That said, cost is a balance, but costs change - as a VPN provider, for your users - opsec is forever.

Why do you think it is fantasy to use an existing platform that has the desired properties today, but also think it is viable to go build a new platform yourself? (I like this effort, but given their goals it's not obvious to me that it was the simplest solution)

I did miss that, and I'm sorry. You weren't positing the system as "fully" open source at all, so I certainly apologise for not making that clear in my writing. Quite the opposite, I misunderstood and/or did not read your writing closely enough nor pay enough attention to it - and so I mischaracterised your post. My bad.

Thank you for your transparency and forthrightness - and hard work in your involvement in porting coreboot to the new platform. The world needs more people like you.

In the future, I'll read more carefully - take some time to digest what I've read - and write in a tone which conveys a bit more charity than I have done.