Recruiting is hard

It’s going to be easier to outsource this work to somebody who is more of an expert than I’ll ever be, would ever want to be, or could ever be.

We (Profian) are currently looking to recruit some software engineers. Now, I’ve been involved in hiring people before – on the interviewing side, at least – but actually doing the recruiting is a completely new experience for me. And it’s difficult. As the CEO of a start-up, however, it turns out that it’s pretty much down to me to manage the process, from identifying the right sort of person, to writing a job advert (see above), to finding places to place it, to short-listing candidates, interviewing them and then introducing them to the rest of the team. Not to mention agreeing a start date, “compensation package” (how much they get paid) and all that. Then there’s the process of on-boarding them (getting contracts sorted, getting them email addresses, etc.), and least some of which I’m pleased to say I have some help with.

The actual recruiting stuff is difficult, though. Recruitment consultants get a bad rap, and there are some dodgy ones, but I’m sure most of them are doing the best they can and are honest people. You might even be happy to introduce some of them to your family. Just a few. But, like so many other things about being start-up founder, it turns out that there comes a time when you have to say to yourself: “well, I could probably learn to do this – maybe not well, but with some degree of competence – but it’s just not worth my time. It’s going to be easier, and actually cheaper in the long run, to outsource this work to somebody who is, frankly, more of an expert than I’ll ever be, would ever want to be, or could ever be. And so I’ve found someone to work with.

What’s really interesting when you find somebody to help you with a new task is the time it takes to mesh your two worlds. I’m a software guy, a we’re looking for software people. I need to explain to the recruitment consultant not only what skills we’re looking for, but what phrases, when they appear on a LinkedIn page or CV[1], are actually red flags. In terms of phrases we’re looking for (or are nice to haves), I’d already mentioned “open source” to the recruitment consultant, but it was only on looking over some possible candidates that I realised that “FOSS” should be in there, too. A person whose current role is “Tech lead” is much more likely to be a fit than “Technical manager”. What’s the difference between a “cloud architect” and a “systems architect”? Is “Assembly” different to “WebAssembly” (yes! – oh, and the latter is sometimes shortened to “Wasm”).

There are, of course, recruitment consultants who specialise in particular technical fields, but what we’re doing (see the Enarx project) is so specialised and so new that I really don’t think that there are likely to be any specialist recruiters anywhere in the world (yet).

So, I feel lucky that I’ve managed to find someone who seems to get not only where we’re coming from as a company, but also the sorts of people we’re looking for. He wisely suggested that we spend some time going over some possible candidates so he could watch me identifying people who were a definite “no” – as useful for him as a definite “must interview”. Hopefully we’ll start to find some really strong candidates soon. If you think you might be one of them, please get in touch!

(Oh – and yes, I’ve invited him to meet my family.)


1 – that’s “resume” for our US friends.

Enarx first release

Write an application, compile it to WebAssembly, and then run it in one of three Keeps types.

I was on holiday last week, and I took the opportunity not to write a blog post, but while I was sunning myself[1] at the seaside, the team did a brilliant thing: we have our first release of Enarx, and a new look for the website, to boot.

To see the new website, head over to https://enarx.dev. There, you’ll find new updated information about the project, details of how to get involved, and – here’s the big news – instructions for how to download and use Enarx. If you’re a keen Rustacean, you can also go straight to crates.io (https://crates.io/crates/enarx) and start off there. Up until now, in order to run Enarx, you’ve had to do quite a lot of low level work to get things running, run your own github branches, understand how everything fits together and manage your own development environment. This has now all changed.

This first release, version 0.1.1, is codenamed Alamo, and provides an easy way in to using Enarx. As always, it’s completely open source: you can look at every single line of our code. It doesn’t provide a full feature set, but what it does do is allow you, for the first time, to write an application, compile it to WebAssembly, and then run it in one of three Keep[2] types:

  1. KVM – this is basically a debugging Keep, in that it doesn’t provide any confidentiality or integrity protection, but it does allow you to get running and to try things even if you don’t have access to specialist hardware. A standard Linux machine should do you fine.
  2. SEV – this is a Keep using AMD’s SEV technology, specifically the newer version, SEV-SNP. This requires access to a machine which supports it[3].
  3. SGX – this is a Keep using Intel’s SGX technology. Again, this requires access to a machine which supports it[3].

The really important point here is that you’re running the same binary on each of these architectures. No recompilation for different architectures: just plain old WebAssembly[4].

Current support

There’s a lot more work to do, but what do we support at the moment?

  • running WebAssembly
  • KVM, SEV and SGX Keeps (see above)
  • stdin and stdout from/to the host – this is temporary, as the host is untrusted in the Enarx model, but until we have networking support (see below), we wanted to provide a simple way to manage input and output from a Keep.

There’s lots more to come – networking and attestation are both high on the list – but now anyone can start playing with Enarx. And, we hope, submitting enhancement and feature requests, not to mention filing bugs (we know there will be some!): to do so, hop over to https://github.com/enarx/enarx/issues.

To find out more, please head over to the website – there’s loads to see – or join us on chat channel over at https://chat.enarx.dev to find out more and get involved.


1 – it’s the British seaside, in October, so “sunning” might be a little inaccurate.

2 – a Keep is what we call a TEE instance set up for you to run an application in.

3 – we have AMD and SGX machines available for people who contribute to the project – get in touch!

4 – WebAssembly is actually rather new, but “plain old” sounds better than “vanilla”. Not my favourite ice cream flavour[5].

5 – my favourite basic ice cream flavour is strawberry. Same for milkshakes.

Announcing Profian

Profian, a security start-up in the Confidential Computing space

I’m very excited to announce Profian, a security start-up in the Confidential Computing space that I co-founded with Nathaniel McCallum, came out of stealth mode today to announce that we’ve completed our Seed Round – you can find the press release here. This is the culmination of months of hard work and about two years of a vision that we’ve shared and developed since coming up with the idea of Enarx. Profian will be creating products and services around Enarx, and we’re committed to keeping everything we do open source: not just because we believe in open source as an ethical choice, but also because we believe that it’s best for security.

Enarx grew out of a vision that we had to simplify use of Trusted Execution Environments like AMD’s SEV and Intel’s SGX[1], while not compromising on the security that we believe the industry wants and needs. Enarx aims to allow you to deploy applications to any of the supported platforms without needing to recompile for each one, and to simplify both the development and deployment process. It supports WebAssembly as its runtime, allowing a seamless execution environment across multiple hardware types. Engineering for Enarx was initially funded by Red Hat, and towards the end of 2020, we started looking for a way to ensure long-term resourcing: out of this Profian was born. We managed to secure funding from two VC funds – Project A (lead investor) and Illuminate Financial – and four amazing angel investors. Coming out of stealth means that we can now tell more people about what we’re doing.

Profian is a member of two great industry bodies: the Confidential Computing Consortium (a Linux Foundation project to promote open source around Trusted Execution Environments) and the Bytecode Alliance (an industry group to promote and nurture WebAssembly, the runtime which Enarx supports).

The other important thing to announce is that with funding of Profian comes our chance to develop Enarx and its community into something really special.

If it’s your thing, you can find the press release on Business Wire, and more information on the company press page.

A few questions and answers

What’s confidential computing?

I tend to follow the Confidential Computing Consortium’s definition: “Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment”.

What does Profian mean?

It’s Anglo-Saxon, the language also sometimes called “Old English”, which was spoken in (modern day) England and parts of Scotland from around the mid-5th century BCE to 1066, when Norman French had such an impact on the language that it changed (to Middle English).

One online Anglo-Saxon dictionary defines profian thus:

profian - 1. to esteem; regard as 2. to test ; try ; prove 3. to show evidence of ; evince

It’s the root of the English word “to prove”, from which we also get “proof” and “proven”. We felt that this summed up much of what we want to be doing, and is nicely complementary to Enarx.

How is Profian pronounced?

Not the way most pre-Conquest Anglo-Saxons would probably have pronounced it, to be honest. We (well, I) thought about trying to go with a more “authentic” pronunciation, and decided (or was convinced…) that it was too much trouble. We’re going with “PROH-vee-uhn”[2].

What does Enarx mean?

You’ll find more information about this (and how to pronounce Enarx), over at the Enarx FAQ. TL;DR – we made it up.

Who’s part of the company?

Well, there’s me (I’m the CEO), Nathaniel McCallum (the CTO) and a small team of developers. We also have Nick Vidal, who we recruited as Community Manager for Enarx. By the beginning of October, we expect to have six employees in five different countries spread across three separate continents[3].

What’s next?

Well, lots of stuff. There’s so much to do when running a company of which I knew next to nothing when we started. You would not believe the amount of work involved with registering a company, setting up bank accounts, recruiting people, paying people, paying invoices, etc. – and that’s not even about creating products. We absolutely plan to do this (or the investors are not going to be happy).

No – what’s next for this blog?

Ah, right. Well, I plan to keep it going. There will be more articles about my book on trust, security, open source and probably VCs, funding and the rest. There have been quite a few topics I’ve just not felt safe blogging about until Profian came out of stealth mode. Keep an eye out.


1 – there are more coming, such as Arm CCA (also known as “Realms”), and Intel’s TDX – we plan to support these are they become available.

2 – Anglo-Saxons would probably have gone with something more like “PRO-fee-an”, where the “o” has sound like “pop”.

3 – yes, I know we’ve not made it easy on ourselves.

Trust book preview

What it means to trust in the context of computer and network security

Just over two years ago, I agreed a contract with Wiley to write a book about trust in computing. It was a long road to get there, starting over twenty years ago, but what pushed me to commit to writing something was a conference I’d been to earlier in 2019 where there was quite a lot of discussion around “trust”, but no obvious underlying agreement about what was actually meant by the term. “Zero trust”, “trusted systems”, “trusted boot”, “trusted compute base” – all terms referencing trust, but with varying levels of definition, and differing understanding if what was being expected, by what components, and to what end.

I’ve spent a lot of time thinking about trust over my career and also have a major professional interest in security and cloud computing, specifically around Confidential Computing (see Confidential computing – the new HTTPS? and Enarx for everyone (a quest) for some starting points), and although the idea of a book wasn’t a simple one, I decided to go for it. This week, we should have the copy-editing stage complete (technical editing already done), with the final stage being proof-reading. This means that the book is close to down. I can’t share a definitive publication date yet, but things are getting there, and I’ve just discovered that the publisher’s blurb has made it onto Amazon. Here, then, is what you can expect.


Learn to analyze and measure risk by exploring the nature of trust and its application to cybersecurity 

Trust in Computer Systems and the Cloud delivers an insightful and practical new take on what it means to trust in the context of computer and network security and the impact on the emerging field of Confidential Computing. Author Mike Bursell’s experience, ranging from Chief Security Architect at Red Hat to CEO at a Confidential Computing start-up grounds the reader in fundamental concepts of trust and related ideas before discussing the more sophisticated applications of these concepts to various areas in computing. 

The book demonstrates in the importance of understanding and quantifying risk and draws on the social and computer sciences to explain hardware and software security, complex systems, and open source communities. It takes a detailed look at the impact of Confidential Computing on security, trust and risk and also describes the emerging concept of trust domains, which provide an alternative to standard layered security. 

  • Foundational definitions of trust from sociology and other social sciences, how they evolved, and what modern concepts of trust mean to computer professionals 
  • A comprehensive examination of the importance of systems, from open-source communities to HSMs, TPMs, and Confidential Computing with TEEs. 
  • A thorough exploration of trust domains, including explorations of communities of practice, the centralization of control and policies, and monitoring 

Perfect for security architects at the CISSP level or higher, Trust in Computer Systems and the Cloud is also an indispensable addition to the libraries of system architects, security system engineers, and master’s students in software architecture and security. 

Buying my own t-shirts, OR “what I miss about conferences”

I can buy my own t-shirts, but friendships need nurturing.

A typical work year would involve my attending maybe six to eight conferences in person and speaking at quite a few of them. A few years ago, I stopped raiding random booths at the exhibitions usually associated with these for t-shirts for the simple reason that I had too many of them. That’s not to say that I wouldn’t accept one here or there if it was particularly nice, or an open source project which I esteemed particularly, for instance. Or ones which I thought my kids would like – they’re not “cool”, but are at least useful for sleepwear, apparently. I also picked up a lot of pens, and enough notebooks to keep me going for a while.

And then, at the beginning of 2020, Covid hit, I left San Francisco, where I’d been attending meetings co-located with RSA North America (my employer at the time, Red Hat, made the somewhat prescient decision not to allow us to go to the main conference), and I’ve not attended any in-person conferences since.

There are some good things about this, the most obvious being less travel, though, of late, my family has been dropping an increasing number of not-so-subtle hints about how it would be good if I let them alone for a few days so they can eat food I don’t like (pizza and macaroni cheese, mainly) and watch films that I don’t enjoy (largely, but not exclusively, romcoms on Disney+). The downsides are manifold. Having to buy my own t-shirts and notebooks, obviously, though it turns out that I’d squirrelled away enough pens for the duration. It also turned out that the move to USB-C connectors hadn’t sufficiently hit the conference swag industry by the end of 2019 for me to have enough of those to keep me going, so I’ve had to purchase some of those. That’s the silly,minor stuff though – what about areas where there’s real impact?

Virtual conferences aren’t honestly too bad and the technology has definitely improved over the past few months. I’ve attended some very good sessions online (and given my share of sessions and panels, whose quality I won’t presume to judge), but I’ve realised that I’m much more likely to attend borderline-interesting talks not on my main list of “must-sees” (some of which turn out to be very valuable) if I’ve actually travelled to get to a venue. The same goes for attention. I’m much less likely to be checking email, writing emails and responding to chat messages in an in-person conference than a virtual one. It’s partly about the venue, moving between rooms, and not bothering to get my laptop out all the time – not to mention the politeness factor of giving your attention to the speaker(s) or panellists. When I’m sitting at my desk at home, none of these is relevant, and the pull of the laptop (which is open anyway, to watch the session) is generally irresistible.

Two areas which have really suffered, though, are the booth experience the “hall-way track”. I’ve had some very fruitful conversations both from dropping by booths (sometimes mainly for a t-shirt – see above) or from staffing a booth and meeting those who visit. I’ve yet to any virtual conferences where the booth experience has worked, particularly for small projects and organisations (many of the conferences I attend are open source-related). Online chat isn’t the same, and the serendipitous aspect of wandering past a booth and seeing something you’d like to talk about is pretty much entirely missing if you have to navigate a set of webpages of menu options with actual intent.

The hall-way track is meeting people outside the main sessions of a conference, either people you know already, or as conversations spill out of sessions that you’ve been attending. Knots of people asking questions of presenters or panellists can reveal shared interests, opposing but thought-provoking points of view or just similar approaches to a topic which can lead to valuable professional relationships and even long-term friendships. I’m not a particularly gregarious person – particularly if I’m tired and jetlagged – but I really enjoy catching up with colleagues and friends over a drink or a meal from time to time. While that’s often difficult given the distributed nature of the companies and industries I’ve been involved with, conferences have presented great opportunities to meet up, have a chinwag and discuss the latest tech trends, mergers and acquisitions and fashion failures of our fellow attendees. This is what I miss most: I can buy my own t-shirts, but friendships need nurturing. and I hope that we can safely start attending conferences again so that I can meet up with friends and share a drink. I just hope I’m not the one making the fashion mistakes (this time).

In praise of … the Community Manager

I am not – and could never be – a community manager

This is my first post in a while. Since Hanging up my Red Hat I’ve been busy doing … stuff. Stuff which I hope to be able to speak about soon. But in the meantime, I wanted to start blogging regularly again. Here’s my first post back, a celebration of an important role associated with open source projects: the community manager.

Open source communities don’t just happen. They require work. Sometimes the technical interest in an open source project is enough to attract a group of people to get involved, but after some time, things are going to get too big for those with a particular bent (documentation, coding, testing) to manage the interactions between the various participants, moderate awkward (or downright aggressive) communications, help encourage new members to contribute, raise the visibility of the project into new areas or market sectors and all the other pieces that go into keeping a project healthy.

Enter the Community Manager. The typical community manager is in that awkward position of having lots of responsibility, but no direct authority. Open source projects being what they are, few of them have empowered “officers”, and even when there are governance structures, they tend to operate by consent of those involved – by negotiated, rather than direct, authority. That said, by the point a community manager is appointed for a community manager, it’s likely that at least one commercial entity is sufficiently deep into the project to fund or part-fund the community manager position. This means that the community manager will hopefully have some support from at least one set of contributors, but will still need to build consensus across the rest of the community. There may also be tricky times, also, when the community manager will need to decide whether their loyalties lie with their employer or with the community. A wise employer should set expectations about how to deal with such situations before they arise!

What does the community manager need to do, then? The answer to this will depend on a number of issues, and there is likely to be a balance between these tasks, but here’s a list of some that come to mind[1].

  • marketing/outreach – this is about raising visibility of the project, either in areas where it is already known, or new markets/sectors, but there are lots of sub-tasks such as a branding, swag ordering (and distribution!), analyst and press relations.
  • event management – setting up meetups, hackathons, booths at larger events or, for really big projects, organising conferences.
  • community growth – spotting areas where the project could use more help (docs, testing, outreach, coding, diverse and inclusive representation, etc.) and finding ways to recruit contributors to help improve the project.
  • community lubrication – this is about finding ways to keep community members talking to each other, celebrate successes, mourn losses and generally keep conversations civil at least and enthusiastically friendly at best.
  • project strategy – there are times in a project when new pastures may beckon (a new piece of functionality might make the project exciting to the healthcare or the academic astronomy community for instance), and the community manager needs to recognise such opportunities, present them to the community, and help the community steer a path.
  • product management – in conjunction with project strategy, situations are likely to occur when a set of features or functionality are presented to the community which require decisions about their priority or the ability of the community to resource them. These may even create tensions between various parts of the community, including involved commercial interests. The community manager needs to help the community reason about how to make choices, and may even be called upon to lead the decision-making process.
  • partner management – as a project grows, partners (open source projects, academic institutions, charities, industry consortia, government departments or commercial organisations) may wish to be associated with the project. Managing expectations, understanding the benefits (or dangers) and relative value can be a complex and time-consuming task, and the community manager is likely to be the first person involved.
  • documentation management – while documentation is only one part of a project, it can often be overlooked by the core code contributors. It is, however, a vital resource when considering many of the tasks associated with the points above. Managing strategy, working with partners, creating press releases: all of these need good documentation, and while it’s unlikely that the community manager will need to write it (well, hopefully not all of it!), making sure that it’s there is likely to be their responsibility.
  • developer enablement – this is providing resources (including, but not restricted to, documentation) to help developers (particularly those new to the project) to get involved in the project. It is often considered a good idea to separate this set of tasks out, rather than expecting a separate role to that of a community manager, partly because it may require a deeper technical focus than is required for many of the other responsibilities associated with the role. This is probably sensible, but the community manager is likely to want to ensure that developer enablement is well-managed, as without new developers, almost any project will eventually calcify and die.
  • cat herding – programmers (who make up the core of any project) are notoriously difficult to manage. Working with them – particularly encouraging them to work to a specific set of goals – has been likened to herding cats. If you can’t herd cats, you’re likely to struggle as a community manager!

Nobody (well almost nobody) is going to be an expert in all of these sets of tasks, and many projects won’t need all of them at the same time. Two of the attributes of a well-established community manager are an awareness of the gaps in their expertise and a network of contacts who they can call on for advice or services to fill out those gaps.

I am not – and could never be – a community manager. I don’t have the skills (or the patience), and one of the joys of gaining experience and expertise in the world is realising when others do have skills that you lack, and being able to recognise and celebrate what they can bring to your world that you can’t. So thank you, community managers!


1 – as always, I welcome comments and suggestions for how to improve or extend this list.

Hanging up my Red Hat

It’s time to move on.

Friday (2021-06-11) was my last day at Red Hat. I’ve changed my LinkedIn, Facebook and Twitter profiles and updated the information on this blog, too. I’d been at Red Hat for just under 5 years, which is one of the longest stays I’ve had at any company in my career. When I started there, I realised that there was a huge amount about the company which really suited who I was, and my attitude to life, and, in particular, open source. That hasn’t changed, and although the company is very different to the one I joined in 2016 – it’s been acquired by IBM, got a new CEO and more than doubled in size – there’s still lots about it which feels very familiar and positive. Bright people, doing stuff they care about, and sharing what they’re doing with the rest of the company and the world: great values.

I’ve also made lots of friends, and got involved in lots of cool things and institutions. I’d particularly call out Opensource.com and the Confidential Computing Consortium. And, of course, the Enarx project.

But … it’s time to move on. I’ve developed an interest in something I care a whole lot about, and which, after lots of discussion and soul-searching, I’ve decided to move into that. I hope to be able to talk more about it in a few weeks, and until then, this blog may be a little quiet. In the meantime, have fun, keep safe and do all that good security stuff.

Dependencies and supply chains

A dependency on a component is one which that an application or component needs to work

Supply chain security is really, really hot right now. It’s something which folks in the “real world” of manufactured things have worried about for years – you might be surprised (and worried) how much effort aircraft operators need to pay to “counterfeit parts”, and I wish I hadn’t just searched online the words “counterfeit pharmaceutical” – but the world of software had a rude wake-up call recently with the Solarwinds hack (or crack, if you prefer). This isn’t the place to go over that: you’ll be able to find many, many articles if you search on that. In fact, many companies have been worrying about this for a while, but the change is that it’s an issue which is now out in the open, giving more leverage to those who want more transparency around what software they consume in their products or services.

When we in computing (particularly software) think about supply chains, we generally talk about “dependencies”, and I thought it might be useful to write a short article explaining the main dependency types.

What is a dependency?

A dependency on a component is one which that an application or component needs to work, and they are generally considered to come in two types:

  • build-time dependencies
  • run-time dependencies.

Let’s talk about those two types in turn.

Build-time dependencies

these are components which are required in order to build (typically compile and package) your application or library. For example, if I’m writing a program in Rust, I have a dependency on the compiler if I want to create an application. I’m actually likely to have many more run-time dependencies, however. How those dependencies are made visible to me will depend on the programming language and the environment that I’m building in.

Some languages, for instance, may have filesystem support built in, but others will require you to “import” one or more libraries in order to read and write files. Importing a library basically tells your build-time environment to look somewhere (local disk, online repository, etc.) for a library, and then bring it into the application, allowing its capabilities to be used. In some cases, you will be taking pre-built libraries, and in others, your build environment may insist on building them itself. Languages like Rust have clever environments which can look for new versions of a library, download it and compile it without your having to worry about it yourself (though you can if you want!).

To get back to your file system example, even if the language does come with built-in filesystem support, you may decide to import a different library – maybe you need some fancy distributed, sharded file system, for instance – from a different supplier. Other capabilities may not be provided by the language, or may be higher-level capabilities: JSON serialisation or HTTPS support, for instance. Whether that library is available in open source may have a large impact on your decision as to whether or not to use it.

Build-time dependencies, then, require you to have the pieces you need – either pre-built or in source code form – at the time that you’re building your application or library.

Run-time dependencies

Run-time dependencies, as the name implies, only come into play when you actually want to run your application. We can think of there being two types of run-time dependency:

  1. service dependency – this may not be the official term, but think of an application which needs to write some data to a window on a monitor screen: in most cases, there’s already a display manager and a window manager running on the machine, so all the application needs to do is contact it, and communicate the right data over an API. Sometimes, the underlying operating system may need to start these managers first, but it’s not the application itself which is having to do that. These are local services, but remote services – accessing a database, for instance – operate in the same sort of way. As long as the application can contact and communicate with the database, it doesn’t need to do much itself. There’s still a dependency, and things can definitely go wrong, but it’s a weak coupling to an external application or service.
  2. dynamic linking – this is where an application needs access to a library at run-time, but rather than having added it at build-time (“static linking”), it relies on the underlying operating system to provide a link to the library when it starts executing. This means that the application doesn’t need to be as large (it’s not “carrying” the functionality with it when it’s installed), but it does require that the version that the operating system provides is compatible with what’s expected, and does the right thing.

Conclusion

I’ve resisted the temptation to go into the impacts of these different types of dependency in terms of their impact on security. That’s a much longer article – or set of articles – but it’s worth considering where in the supply chain we consider these dependencies to live, and who controls them. Do I expect application developers to check every single language dependency, or just imported libraries? To what extent should application developers design in protections from malicious (or just poorly-written) dynamically-linked libraries? Where does the responsibility lie for service dependencies – particularly remote ones?

These are all complex questions: the supply chain is not a simple topic (partly because there is not just one supply chain, but many of them), and organisations need to think hard about how they work.

Arm joins the Confidential Computing party

Arm’s announcement of Realms isn’t just about the Edge

The Confidential Computing Consortium is a Linux Project designed to encourage open source projects around confidential computing. Arm has been part of the consortium for a while – in fact, the company is Premier Member – but things got interesting on the 30th March, 2021. That’s when Arm announced their latest architecture: Arm 9. Arm 9 includes a new set of features, called Realms. There’s not a huge amount of information in the announcement about Realms, but Arm is clear that this is their big play into Confidential Computing:

To address the greatest technology challenge today – securing the world’s data – the Armv9 roadmap introduces the Arm Confidential Compute Architecture (CCA).

I happen to live about 30 minutes’ drive from the main Arm campus in Cambridge (UK, of course), and know a number of Arm folks professionally and socially – I think I may even have interviewed for a job with them many moons ago – but I don’t want to write a puff piece about the company or the technology[1]. What I’m interested in, instead, is the impact this announcement is likely to have on the Confidential Computing landscape.

Arm has had an element in their architecture for a while called TrustZone which provides a number of capabilities around security, but TrustZone isn’t a TEE (Trusted Execution Environment) on its own. A TEE is the generally accepted unit of confidential computing – the minimum building block on which you can build. It is arguably possible to construct TEEs using TrustZone, but that’s not what it’s designed for, and Arm’s decision to introduce Realms strongly suggests that they want to address this. This is borne out by the press release.

Why is all this important? I suspect that few of you have laptops or desktops that run on Arm (Raspberry Pi machines apart – see below). Few of the servers in the public cloud run Arm, and Realms are probably not aimed particularly at your mobile phone (for which TrustZone is a better fit). Why, then, is Arm bothering to make a fuss about this and to put such an enormous design effort into this new technology? There are two answers, it seems to me, one of which is probably pretty much a sure thing, and the other of which is more of a competitive gamble.

Answer 1 – the Edge

Despite recent intrusions by both AMD and Intel into the Edge space, the market is dominated by Arm-based[3] devices. And Edge security is huge, partly because we’re just seeing a large increase in the number of Edge devices, and partly because security is really hard at the Edge, where devices are more difficult to defend, both logically (they’re on remote networks, more vulnerable to malicious attack) and physically (many are out of the control of their owners, living on customer premises, up utility poles, on gas pipelines or in sports stadia, just to give a few examples). One of the problems that confidential computing aims to solve is the issue that, traditionally, once an attacker has physical access to a system, it should be considered compromised. TEEs allow some strong mitigations against that problem (at least against most attackers and timeframes), so making it easy to create and use TEEs on the Edge makes a lot of sense. With the addition of Realms to the Arm 9 architecture, Arm is signally its intent to address security on the Edge, and to defend and consolidate its position as leader in the market.

Answer 2 – the Cloud

I mentioned above that few public cloud hosts run Arm – this is true, but it’s likely to change. Arm would certainly like to see it change, and to see its chipsets move into the cloud mainstream. There has been a lot of work to improve support for server-scale Arm within Linux (in fact, open source support for Arm is generally excellent, not least because of the success of Arm-based chips in Raspberry Pi machines). Amazon Cloud Services (AWS) started offering Arm-based servers to customers as long ago as 2018. This is a market in which Arm would clearly love to be more active and carve out a larger share, and the growing importance of confidential computing in the cloud (and public and private) means that having a strong story in this space was important: Realms are Arm’s answer to this.

What next?

An announcement of an architecture is not the same as availability of hardware or software to run on it. We can expect it to be quite a few months before we see production chips running Arm 9, though evaluation hardware should be available to trusted partners well before that, and software emulation for various components of the architecture will probably come even sooner. This means that those interested in working with Realms should be able to get things moving and have something ready pretty much by the time of availability of production hardware. We’ll need to see how easy they are to use, what performance impact they have, etc., but Arm do have an advantage here: as they are not the first into the confidential computing space, they’ve had the opportunity to watch Intel and AMD and see what has worked, and what hasn’t, both technically and in terms of what the market seems to like. I have high hopes for Arm Realms, and Enarx, the open source confidential computing project with which I’m closely involved, has plans to support them when we can: our architecture was designed with multi-platform support from the beginning.


1 – I should also note that I participated in a panel session on Confidential Computing which was put together by Arm for their “Arm Vision Day”, but I was in no way compensated for this[2].

2 -in fact, the still for the video is such a terrible picture of me that I think maybe I have grounds to sue for it to be taken down.

3 – Arm doesn’t manufacture chips itself: it licenses its designs to other companies, who create, manufacture and ship devices themselves.

GET/SET methods for open source projects

Or – how to connect with open source

I’m aware that many of the folks who read my blog already know lots about open source, but I’m also aware that there are many who know little if anything about it. I’m a big, big proponent or open source software (and beyond, such as open hardware), and there are lots of great resources you can find to learn more about it: a very good starting point is Opensource.com. It’s run by a bunch of brilliant people for the broader community by my current employer, Red Hat (I should add a disclaimer that I’m not only employed by Red Hat, but also a “Correspondent” at Opensource.com – a kind of frequent contributor/Elder Thing), and has articles on pretty much every aspect of open source that you can imagine.

I was thinking about APIs today (they’re in the news this week after a US Supreme Court Judgment on an argument between Google and Oracle), and it occurred to me that if I were interested in understanding how to interacting with open source at the project level, but didn’t know much about it, then a quick guide might be useful. The same goes if I were involved in an open source project (such as Enarx) which was interested in attracting contributors (particularly techie contributors) who aren’t already knowledgeable about open source. Given that most programmers will understand what GET and SET methods do (one reads data, the other writes data), I thought this might be useful way to consider engagement[1]. I’ll start with GET, as that’s how you’re likely to be starting off, as well – finding out more about the project – and then move to SET. This is far from an exhaustive list, but I hope that I’ve hit most of the key ways you’re most likely to start getting involved/encourage others to get involved. The order I’ve chosen reflects what I suspect is a fairly typical approach to finding out more about a project, particularly for those who aren’t open source savvy already, but, as they say, YMMV[2].

I’ve managed to stop myself using Enarx as the sole source of examples, but have tried to find a variety of projects to give you a taster. Disclaimer: their inclusion here does not mean that I am a user or contributor to the project, nor is it any guarantee of their open source credentials, code quality, up-to-date-ness, project maturity or community health[4].

GET methods

  • Landing page – the first encounter that you may have with a project will probably be its landing page. Some projects go for something basic, others apply more design, but you should be able to use this as the starting point for your adventures around the project. You’d generally hope to find a link various of the other resources listed below from this page. Sigstore
  • Wiki – in many cases, the project will have a wiki. This could be simple, it could be complex. It may allow editing by anyone, or only by a select band of contributors to the project, and its relevance as source-of-truth may be impacted by how up to date it is, but the wiki is usually an excellent place to start. Fedora Project
  • Videos – some projects maintain a set of videos about their project. These may include introductions to the concepts, talking head interviews with team members, conference sessions, demos, HOW-TOs and more. It’s also worth looking for videos put up my contributors to the project, but which aren’t necessarily officially owned by the project. Rust Language
  • Code of Conduct – many projects insist that their project members follow a code of conduct, to reduce harassment, reduce friction and generally make the project a friendly, more inclusive and more diverse place to be. Linux kernel
  • Binary downloads – as projects get more mature, they may choose to provide pre-compiled binary downloads for users. More technically-inclined users may choose to compile their own from the code base (see below) even before this, but binary downloads can be a quick way to try out a project and see whether it does what you want. Chocolate Doom (a Doom port)
  • Design documentation – without design documentation, it can be very difficult to get really into a project (I’ve written about the importance of architecture diagrams on this blog before). This documentation is likely to include everything from an API definition up to complex use cases and threat models. Kubernetes
  • Code base – you’ve found out all you need to get going: it’s time to look at the code! This may vary from a few lines to many thousands, may include documentation in comments, may include test cases: but if it’s not there, then the project can’t legitimately call itself open source. Rocket Rust web framework[5]
  • Email/chat – most projects like to have a way for contributors to discuss matters asynchronously. The preferred medium varies between projects, but most will choose an email list, a chat server or both. Here’s where to go to get to know other users and contributors, ask questions, celebrate successful compiles, and just hang out. Enarx chat
  • Meet-ups, video conferences, calls, etc. – though physically meetings are tricky for many at the moment (I’m writing as Covid-19 still reduces travel opportunities for many), having ways for community members and contributors to get together synchronously can be really helpful for everybody. Sometimes these are scheduled on a daily, weekly or monthly basis, sometimes they coincide with other, larger meet-ups, sometimes a project gets big enough to have its own meet-ups, and sometimes so big that there are meet-ups of sub-projects or internal interest groups. Linux Security Summit Europe

SET methods

  • Bug reports – for many of us, the first time we contribute anything substantive back to an open source project is when we file a bug report. These types of bug reports – from new users – can be really helpful for projects, as they not only expose bugs which may not already be known to the project, but they also give clues as to how actual users of the project are trying to use the code. If the project already publishes binary downloads (see above), then you don’t even need to have compiled the code to try it and submit a bug report, but bug reports related to compilation and build can also be extremely useful to the project. Sometimes, the mechanism for bug reporting also provides a way to ask more general questions about the project, or to ask for new features. exa (replacement for the ls command)
  • Tests – once you’ve starting using the project, another way to get involved (particularly once you start contributing code) can be to design and submit tests for how the project ought to work. This can be a great way to unearth both your assumptions (and lack of knowledge!) about the project, but also the project’s design assumptions (some of which may well be flawed). Tests are often part of the code repository, but not always. Gnome Shell
  • Wiki – the wiki can be a great way to contribute to the project whether you’re coding or not. Many projects don’t have as much information available as they should do, and that information may often not be aimed at people coming to the project “fresh”. If this is what you’ve done, then you’re in a great position to write material which will help other “newbs” to get into the project faster, as you’ll know what would have helped you if it had been there. Wine (Windows Emulator for Linux)
  • Code – last, but not least, you can write code. You may take hours, months or years to get to this stage – or may never reach it – but open source software is nothing without its code. If you’ve paid enough attention to the other steps, got involved in the community, understood what the project aims to do, and have the technical expertise (which you may well develop as you go!), then writing code may be way to you want to do. Enarx (again)

1 – I did consider standard RESTful verbs – GET, PUT, POST and DELETE, but that felt rather contrived[2].

2 – And I don’t like the idea of DELETE in this context!

3 – “Your Mileage May Vary”, meaning, basically, that your experience may be different, and that’s to be expected.

4 – that said, I do use lots of them!

5 – I included this one because I’ve spent far too much of my time look at this over the past few months…