Vojtech Pavlik, SUSE | OSS North America 2023

This is Techstrong tv. Hello everybody and welcome to the Open Source Summit here in Vancouver, British Columbia. I'm here with Voytek Pavlin from suse.

We're talking about confidential computing and open source, and there's a lot going on. Voytek, welcome to show. Hello.

Happy to be here with you. I'm not sure everybody knows exactly what confidential computing is. I talk to a lot of folks and they like look at me and they kind of stare blankly.

So you wanna take a couple of seconds here and just walk us through what is it about confidential computing that's different and how are people gonna use this? Right. So confidential computing, actually there is like two kinds of people, right?

The ones that didn't hear about it and the ones that have heard too much about it and nobody in the end, um, is very keen about it as a result. So our confidential computing actually is a technology trying to, uh, not just protect the data at rest. Like when you have this encryption or data in transit, when you have https, everybody's using encrypted, uh, data transit over the network today, right?

But also data in processing, so when it actually is being used, when it's in the operating memory of the computer. So that alone does not sound very interesting until you actually realize that if you can build a confidential VM virtual machine, then that VM is not only protected from physical attacks, right? Because all the data that goes off the chip into the ram, into the dims and on the board is encrypted, but also from any, uh, excess from the hypervisor.

And that's when things start getting really interesting. Mm-hmm. Are the bad guys attacking systems and when the data's being processed because it's clear text, right?

It's clear data right when it's running. So is that an easy target for them or is this kind of a nuance of cybersecurity? So when you look at, um, the various scenarios, right?

So you can have, for example, a machine that is living somewhere in the wild in on the edge, as is today's friend of calling it. So it may be at a curb of a street, uh, in a box of a, um, cable TV provider or internet provider, right? It may be in a, in a BTS of a telco somewhere potentially high up on a telephone tower or transmit tower, it may be in, um, in a restaurant.

And those are all potentially hostile environments where somebody could want to get in and, I don't know, get the TV streaming for free or something, right? So that is actually where that physical protection matters. Um, but then there is one major use case where the hypervisor protection matters, right?

When you, when you are a bad guy, you can be, um, like someone anonymous on the internet taking over one virtual machine at a cloud provider and exploiting a security hole security vulnerability. You could get control of the hypervisor and then the, the whole world is yours because then you can actually peer into all the other VMs, do any modification that you want, get the data from there, then you would be a very happy hacker. Um, but that is not even the main use case.

The main use case is actually preventing the cloud service provider from being able to access your data. It is not that the cloud service providers would be evil, right? I certainly do trust them that they, um, are doing everything they can to prevent a rogue administrator from accessing the data.

It is more about the liability about the really technical barrier that prevents them. So then the cloud provider actually is not even able to access the data and so they are protected against their potential rogue administrator. And on the other hand, uh, the owner of the VM is then able to process data that they would not necessarily be able to entrust to a third party.

It may be personal data, it may be financial data, it may be just trade secrets that they are, um, needing to protect or that they're obligated to protect by, uh, regulation. So even, um, and you said I'm from Souse, right? Souse is an operating system company, Linux open source, but even we are limited on where we can process our code.

Uh, we are certified to the, one of the highest security standards in supply chain security common. We are EL four plus. Uh, and that prevents us from actually being able to use the cloud for compiling our code because well, we are potentially against even government level players.

And so somebody could want to use, uh, the cloud to actually modify our code, potentially inject some backdoor, not necessarily the cloud provider, but an agency let's say. Um, and so we are not allowed to do that, right? We need to keep everything in house with confidential computing that revenue opens because even the cloud provider, even somebody physically accessing the machine, will have a very hard time actually getting, uh, inside of the vm.

We today are filling out massive amounts of paperwork to attest to who had access to what. Can all that just go away if we have confidential computing? Because I'll know by definition that nobody had access to this and I'll just check the box and be done.

It makes a lot of that simpler. It will not go away, obviously mm-hmm. Because people who have never does go completely away, but it can make things a lot, lot simpler.

Indeed. The perception is is that this is a cloud issue. But you mentioned some on-premise type use cases at the network edge.

So is confidential computing gonna be pervasive from end to end? Is that something we need to think about across the board? Well, uh, from, from previous experience, right?

So, uh, the first thing that came was the network encryption. Like when you are communicating over network, you want your data encrypted. I don't think they, initially when the internet started, everybody was communicating plain text.

Emails were sent plain text, um, webpages were served over attp without encryption. Today everybody is encrypted. Even data that does not need to be encrypted because it's just safer.

Mm-hmm. Same thing with disc encryption, right? Uh, people wear loath to use disc encryption because it costs you some performance, but today even your cell phone will have all the storage automatically encrypted.

So it is only natural that in the end, uh, confidential computing will probably be similarly pervasive, right? Because it has advantages in almost every use case. Um, it has some disadvantages of course as well because it does impact performance.

The main impact that you see is, well, there should have, there are two. The main impact that you see is the memory access latency, right? So cashes are not encrypted, they are still on the die, so they are as fast as ever.

But when you are trying to access main memory in the dims, there is the additional step of encrypting and decrypting, which costs a couple nanoseconds. So that's one performance. The other one, and this one probably can't be really solved, right?

This will always be there, but things will get faster over time so people will not notice. The other one is, uh, that a lot of, of load and acceleration technologies are currently not possible to do with confidential computing. So if oral memory is encrypted, then your network card cannot just get at the memory and do the encryption for the network.

For you, it needs to be done by the cpu. So the CPU first encrypts the data, places it into non-encrypted memory, and then after the card, whereas in the past or in the current state, uh, it'll just put the data in memory and tell the card, go encrypt the data and send it over. But since you don't want that unencrypted data to leave the cpu, uh, the CPU needs to do the encryption.

So, uh, today, if you enable confidential computing on a server that is, let's say a heavy HTTP web server, right? That is churning a lot of data out, uh, you will lose performance because the card will not be able to do, um, much of that encryption for the cpu. But that will be solved again by adding instructions for on CPU encryption, uh, adding encrypted pcx press and the car that actually can, uh, access that and, and so on over the time this problem will go completely away.

What is the role of the open source community in all of this? Cuz it kind of sounds fairly technical. I mean, where, I mean so far most I've been talking about, um, the hardware part, like the technology part, the, the, the one that really excites me, uh, because I've started, although I'm today I'm in the manager role, right?

Um, and actually managing most of suse lennox's business. Um, I've started as a kernel programmer, I've started tinkering with devices. So this is still something that, that really, um, yeah, that I really love.

You're you're recovering main maintainer, is that what you're saying? Oh, that's correct, yes. I was, I was actually a maintainer of the Linux input subsystem.

Mm-hmm. Um, so anything that, or the code that processes all the human input, the keyboards and the mice and all that still bears my name in the Linux kernel. Uh, but yeah, I've been able to hand that over soon enough.

Um, anyway, back to the role of open source, uh, of open source, uh, Linux companies like SUSE in the whole thing. So the one thing that's, that I've started with, right? The, the cloud, uh, example, the idea is that the confidential computing reduces the number of parties that you have to trust.

Mm-hmm. Um, it takes a couple parties out of the equation. The cloud provider for one, uh, the board manufacturer as well, because anything that goes off the chip is encrypted.

Uh, so even a road board could potentially not get at the data and only two, um, two parties remain in the equation. And that is the CPU vendor. Obviously the CPU needs to be able to, or not able needs to, needs to process the code correctly.

It needs to execute the instructions correctly because as soon as it would do fishy stuff with one plus one, well then your code will not be working and your security will be gone. So you need to transfer CPU vendor and everybody kind of automatically assumes that today. Uh, the other one is the operating system vendor or operating system, uh, not necessarily vendor, but the source of the operating system.

So you need to trust the operating system and that's where open source comes in because you can have a lot more trust into the operating system than you can actually well verify for yourself. Um, and that's also where Suza comes in because, uh, out of the open source, uh, Linux companies, we are the one that actually has the most certified security supply chain or secure supply chain actually documenting where we get the code fully validating that the individual communities that we are taking the code from, uh, are have good operating guidelines that ensure that the probability of a backdoor getting in is very low, validating the code, testing the code, having all the internal processes very well documented. That is what actually builds a very trustable operating system.

There is one more aspect to those just two parties, and that is that when you are using confidential computing, you are eliminating, let's say again the cloud provider or MSP or any third party that is actually running your system, including a data center operator, uh, which are all parties that have direct online access to our system. So they actually either can physically or logically, uh, manipulate it neither the CPU vendor or the operating system vendor can. So yes, we are providing the code, but once the code is deployed, we do not have access to it.

So that further increases your security posture, right? Because those that have online access actually do not have access and could have online access, do not have access anymore. And those who are only providing components are, well, those are the ones remaining to be trusted.

And while that's as good as it can get, We hear a lot about, uh, post quantum crypto, uh, post quantum cryptography these days. Are the encryption schemes that we're using today gonna stand up to that tomorrow? Or do we need to think about that a little bit as well?

Oh, that's an interesting question. So number one, I've actually studied physics, right? So I have a somewhat dimmer view on quantum computing then, uh, well it is prevalent in the news so to say.

So, um, I actually do not have a huge belief that quantum computing will get us very far, very soon. The problem with it is that it is exponentially more, exponentially harder, uh, to build machines that are using quantum computing as they grow. So if, if you start with a couple cub bits, it's still easy.

If you double that, well that's get exponentially more, uh, tough to actually keep that quantum state in an unco collapsed state, right? So the, the bigger you build it, the the shorter time it actually can live in an unco collapsed state. And so I actually do not think that uh, quantum cryptography will proce pro progress that fast.

On the other hand, it is still like the right thing to do to create, uh, quantum resilient algorithms. So post quantum crypto cryptography also can't say that my fault, uh, is, is actually uh, an absolutely right consequence of of seeing the quantum computers. It is the one area of research that actually does make sense.

Um, so yeah, I do not think that the current algorithms would necessarily, um, not succumb to large enough quantum computers. But um, also given that there is not a particular rush, um, CPUs with, well more advanced algorithms can easily be built as the quantum crypto aircraft gets closer to, uh, to cracking, let's say, um, asymmetrical, um, factorization based ciphers, like I saying. Yeah, unless Something crashes as you think it through and we wanna encrypt everything, can we do this in a way that's transparent to the developer or does the developer have to do something or know something about these underlying encryption schemes?

Okay, sounds good. Thanks so much about, so our current approach, uh, and SUSE is like developing our of computing quite a bit. Actually I would say that we are spearheading it in the Linux kernel, uh, is to really make it basically zero effort, right?

So, um, the developer does not have, unless you are developing the confidential computing itself, then you don't need to know much about it, right? Uh, the IT administrator does need to know about it. Um, mainly because there is one significant component of confidential computing and that is, it is not enough if your VM is encrypted.

The other part that you need to know it is exact whether the VM is the one that you want it to be running. So if I click, um, in a web interface, please spin up my vm, then the cloud or some computer somewhere does spin up that vm, but it also may be a different vm, it's like modifications. Um, it may have bit errors during transfer or well somebody tempered with it, right?

And you want to be sure that it is exactly what you sent there. The other thing that you want to know is that, uh, that click actually caused it to run encrypted rather than in plain text. Uh, we are just telling you it's encrypted.

So you want to have kind of proof that it is running encrypted and it's running exactly what you want. Otherwise the whole thing would be pointless. This is called remote at.

Mm-hmm. And this is built into the architecture of confidential computing. So, uh, that is something that the IT administrator needs to be aware and needs to be running a remote attestation server somewhere.

It can be provided by a trusted party or it can run on premise, which is the most secure solution of course, that actually con connects the VM and validates it. And yeah, so that's the only thing that actually needs to be done. You need to configure out some third party that will tell, yeah, this is it.

Or you need to be running a service that can tell you this is what you wanted to run. Is this all moving faster than government policies are keeping up with? Cuz it seems like there's a lot of noise in the system about encryption on smartphones, but now we take it all the way up to the cloud and back and in between is, you know, are law enforcement people gonna go, well that's great, but you gotta find some way to make sure that we can access it whenever we need to.

Well, that's going to be of course interesting as usual, like end-to-end encryption in phones on messages is currently a, a big, uh, point of discussion between governments because it can be used for criminal purposes quite easily. Um, but at the same time it is giving people the privacy that everybody wants. So that is a policy decision and yes, always policies and regulations are behind the reality that is how they work.

So I suppose that eventually we may have some policies around this as well, although it is not that different to what we are doing today, right? It is just making, um, just closing some of the holes that we have in today's technology. Uh, and certainly it is not where the policy is as behind as, for example, when it comes to artificial intelligence.

True. That, um, last question. What's your best advice to folks about how to get started with all of this?

Where should they begin? I guess, you know, the variation of that question is you've been doing it for a while, what do you wish you knew? Well, I would say visit my talk.

I'll be talking about exactly this, this afternoon at three o'clock here at opensource Summit North America. Uh, but also I can point people to two projects that are kind of interesting because this is not yet all available yet coming, right? The CPUs are not all enabled.

Um, like Intel CPUs will start get enabled by the end of the year and there are even some open source components missing that actually make it all work very uh, smoothly, right? So this is still under development, but it's a really cool technology. So I want people to be fully aware of it and, and excited and looking for it when it comes.

The other pro. So the, the new project that I would like to mention are Coconut s vsm, which is a SUSE project providing, uh, one of the major building stones in the whole chain. Um, a virtual TPM running in confidential competing mode.

Uh, the other one is suse alp, a next generational living distribution that has all these technologies integrated as they develop. We are releasing every three months and it's of course open source, of course free. Uh, so people can play with that.

All right, cool. Hey folks, you heard in here first from the man himself, trust no one VO tech. Thanks for being on the show.

Thank you. All right. And we'll be back in a minute.