WEBVTT 00:00.000 --> 00:08.560 Okay, first of all, thank you very much for coming to my talk. 00:08.560 --> 00:11.400 I'm very glad that so many of you are interested in open source 00:11.400 --> 00:13.600 sphere, metaphor, confination of building. 00:13.600 --> 00:17.600 Second, thanks to DevRome managers for accepting my talk. 00:17.600 --> 00:21.240 Yeah, luckily this year we don't have open source 00:21.240 --> 00:24.400 pyramid DevRome, but anyway, I got there quite a lot of feedback from 00:24.400 --> 00:28.200 many people, so I would like to thank all the reviewers of this presentation. 00:29.200 --> 00:36.200 Thremed up, me how was the brain technical coding developers brain behind this? 00:36.200 --> 00:42.200 I'm a coordinator and kind of high level vision for that. 00:42.200 --> 00:48.200 So modern high, modern high assurance requires 00:48.200 --> 00:50.200 confidential computing. 00:50.200 --> 00:53.200 We have 10 years of confidential computing. 00:53.200 --> 00:57.200 Definity, this is like a state-of-the-art part of the security ecosystem. 00:57.200 --> 01:00.200 And I don't think we can build high assurance infrastructure 01:00.200 --> 01:02.200 without confidential computing. 01:02.200 --> 01:06.200 And of course, we need high assurance to build some sovereignty. 01:06.200 --> 01:12.200 So how we will do this, if we don't have enough experts, 01:12.200 --> 01:16.200 and of course we have to grow more experts, we need more seniors. 01:16.200 --> 01:20.200 So how we grow those seniors need some hardware, 01:20.200 --> 01:23.200 some transparent ecosystem, which they can inspect, 01:23.200 --> 01:26.200 research, analyze, reason about. 01:26.200 --> 01:30.200 And this is what this talk is about. 01:30.200 --> 01:34.200 So first of all, I would like to give a 01:34.200 --> 01:40.200 to confidential computing ecosystem some research platform for 01:40.200 --> 01:44.200 the educational purposes for security research purposes, 01:44.200 --> 01:48.200 which they can easily inspect. 01:48.200 --> 01:52.200 And then hopefully that will increase transparency 01:52.200 --> 01:56.200 in the ecosystem, increase openness of the ecosystem. 01:56.200 --> 02:02.200 And then hopefully we can get the underlying key components 02:02.200 --> 02:04.200 of the firmware, which are right now, 02:04.200 --> 02:08.200 close swords, binary robes, going into standardization, 02:08.200 --> 02:10.200 and openness. 02:10.200 --> 02:13.200 And what I will show in this presentation, 02:13.200 --> 02:17.200 the firmware trust problem, and who, all these who, 02:17.200 --> 02:20.200 and where, like, who we rely on, 02:20.200 --> 02:23.200 then I will tell you about open seal and core boot, 02:23.200 --> 02:26.200 and what we did to open the ecosystem. 02:26.200 --> 02:30.200 And then I will show you the demo of the stock, 02:30.200 --> 02:33.200 showing the SCV, S&P, 02:33.200 --> 02:38.200 attestation on the open seal plus core boot on the retail server, 02:38.200 --> 02:42.200 which you can buy, which you can provision, 02:42.200 --> 02:45.200 which you can flash, and play with, of course, 02:45.200 --> 02:50.200 if you can afford the memory design. 02:50.200 --> 02:54.200 Okay, so this, I don't expect you to read this, 02:54.200 --> 02:56.200 go back to the presentation, read the details, 02:56.200 --> 02:59.200 I know the letters are small. 02:59.200 --> 03:03.200 This slide is just to tell you what's my thinking about high assurance, 03:03.200 --> 03:05.200 and this is definitely extremely simplified view, 03:05.200 --> 03:07.200 because it's not enough here. 03:07.200 --> 03:09.200 It, this picture should be much bigger. 03:09.200 --> 03:11.200 But let's start from the right side. 03:11.200 --> 03:14.200 First of all, I'm thinking about the bootstrapable tool chains. 03:14.200 --> 03:19.200 This is inspired by stage X, this trust company, this stage X, 03:19.200 --> 03:23.200 which is very similar to GUIX, to next thinking, 03:23.200 --> 03:26.200 but also a little bit different in some places. 03:26.200 --> 03:29.200 But it doesn't matter the point is to bootstrap from some, 03:29.200 --> 03:32.200 from some seed, from some known, 03:32.200 --> 03:36.200 all the table piece of bytes, in assembly, whole tool chain. 03:36.200 --> 03:39.200 So we can do this in a reproducible way, 03:39.200 --> 03:42.200 and we can make sure that it's really what we, 03:42.200 --> 03:46.200 that what we building is really from the code that we get, 03:46.200 --> 03:48.200 things we have some transparency. 03:48.200 --> 03:51.200 When we have the tool chain, we can start building. 03:51.200 --> 03:53.200 How we building, we have to build on multiple targets, 03:53.200 --> 03:57.200 to have distributed reproducibility code on, 03:57.200 --> 04:00.200 because if we will build on multiple targets, 04:00.200 --> 04:02.200 they will agree on the harshest. 04:02.200 --> 04:05.200 That means the software supply chain is not compromised, 04:05.200 --> 04:08.200 and it's very likely we can build some trust 04:08.200 --> 04:10.200 worthiness based on that evidence. 04:10.200 --> 04:13.200 If we do a very metal on different architectures, 04:13.200 --> 04:15.200 for cross compiling, this is even better. 04:15.200 --> 04:18.200 Then if we have some builds, and we have some trust worthiness 04:18.200 --> 04:21.200 in those build, and some assurance of those builds, 04:21.200 --> 04:24.200 we can go into owner controller through the status 04:24.200 --> 04:26.200 and chain of trust, that's kind of future, 04:26.200 --> 04:29.200 3M depth contributing a lot to that future, 04:29.200 --> 04:32.200 to make the ability of buying the hardware, 04:32.200 --> 04:35.200 and you essentially can't provision all your own keys 04:35.200 --> 04:39.200 into a good guard, or whatever AMD platform, 04:39.200 --> 04:41.200 secure boot, or whatever ARM platform, 04:41.200 --> 04:43.200 so you can really own the platform, 04:43.200 --> 04:46.200 that the keys, your keys are fused in OTP, 04:46.200 --> 04:48.200 or ifuses, and from the beginning of the word, 04:48.200 --> 04:53.200 from the power on everything whole whole software is yours. 04:53.200 --> 04:57.200 After that, after that, I hope this can contribute 04:57.200 --> 05:00.200 to the confidential computing ecosystem, 05:00.200 --> 05:03.200 and hopefully at some point we will have some open source 05:03.200 --> 05:05.200 firmware here, and open source firmware here. 05:05.200 --> 05:10.200 This is trusted execution environment security monitor. 05:10.200 --> 05:12.200 I have a lot of slides, so I have to speed up 05:12.200 --> 05:15.200 because I don't have time to talk about all those details. 05:15.200 --> 05:17.200 I want to build some parallel, because some of you 05:17.200 --> 05:19.200 maybe don't know, okay, what is this open source 05:19.200 --> 05:20.200 firmware ecosystem? 05:20.200 --> 05:22.200 I just want to tell you, like, you know, 05:22.200 --> 05:24.200 cardboard, who knows, cardboard? 05:24.200 --> 05:26.200 Good, but very good. 05:26.200 --> 05:29.200 Tyano core is an IDK, IDK2, 05:29.200 --> 05:31.200 IDK2, IDK2, IDK2, IDK2, 05:31.200 --> 05:33.200 UFI, reference implementation ecosystem, 05:33.200 --> 05:36.200 Linux boot, Snim boot loader, 05:36.200 --> 05:38.200 AMD open seal is kind of new thing. 05:38.200 --> 05:41.200 I will talk a little bit about OpenSFI, 05:41.200 --> 05:43.200 which is OCP activity. 05:43.200 --> 05:46.200 It's even newer thing, it's right now in drafting. 05:46.200 --> 05:48.200 Caliptera, very good root of trust, 05:48.200 --> 05:50.200 despite coming from Microsoft, 05:50.200 --> 05:52.200 but Microsoft AMD and Google, 05:52.200 --> 05:53.200 but it's very good, really. 05:53.200 --> 05:55.200 Read the specification, it's very good. 05:55.200 --> 05:58.200 Open Titan, trusted firmware, 05:58.200 --> 06:01.200 and Linux is because of the presence in OpenBMC. 06:01.200 --> 06:04.200 I want to build some parallel with the BIOS evolution. 06:04.200 --> 06:08.200 So, I divided the evolution of Confederation computing 06:08.200 --> 06:10.200 into IRAS, like the BIOS evolution. 06:10.200 --> 06:13.200 So, in the beginning, we have this proprietary error. 06:13.200 --> 06:16.200 Then we have some tribes of openness and standardization, 06:16.200 --> 06:17.200 like we see here. 06:17.200 --> 06:20.200 And then hopefully we go more into standardization 06:20.200 --> 06:23.200 when we have standards, we can build the open implementations 06:23.200 --> 06:27.200 and try to improve our ecosystem to make it more trustworthy. 06:27.200 --> 06:31.200 And build this architecture that we talk about. 06:31.200 --> 06:34.200 I'm not sure if I should go very deep into that one. 06:34.200 --> 06:37.200 You probably all know this evolution. 06:37.200 --> 06:39.200 So, it depends how we count. 06:39.200 --> 06:42.200 2017, some say 2016, 06:42.200 --> 06:45.200 because the white paper was from 2016, 06:45.200 --> 06:47.200 but the processors were cheaper to lighter. 06:47.200 --> 06:50.200 But we essentially have these generations of AMD processor, 06:50.200 --> 06:53.200 Naples, Rome, Milan, Genoa, Turing, 06:53.200 --> 06:57.200 which every includes more and more security features. 06:57.200 --> 07:00.200 Turing includes SVT, trusted IO, 07:00.200 --> 07:02.200 which is very interesting. 07:02.200 --> 07:04.200 We plan to do some stuff with that. 07:04.200 --> 07:06.200 But point of the slide is showing. 07:06.200 --> 07:10.200 First of all, by the way, security promise was not publicly communicated from AMD. 07:10.200 --> 07:12.200 There was no CVs. 07:12.200 --> 07:16.200 There were internal tracking of the firmware security issues. 07:16.200 --> 07:18.200 About they were not as a CVs. 07:18.200 --> 07:22.200 If you look into release notes of the AMD SCV firmware, 07:22.200 --> 07:24.200 you will find there were problems there. 07:24.200 --> 07:27.200 Then they communicated at the Milan state. 07:27.200 --> 07:30.200 They communicated this security. 07:30.200 --> 07:33.200 And then suddenly CVs were issues. 07:33.200 --> 07:37.200 We see just in the AMD SCV firmware, 07:37.200 --> 07:41.200 we got 22 here, 28 here and so far, 15 for Turing. 07:41.200 --> 07:45.200 Some of those are cross-cross micro-architectures. 07:45.200 --> 07:53.200 So that's the point of the slide to show that this closed source piece is quite vulnerable. 07:53.200 --> 07:58.200 And there are a lot of evidence for problems there. 07:58.200 --> 08:01.200 Okay? 08:01.200 --> 08:04.200 Okay. 08:04.200 --> 08:07.200 And this trust problem. 08:07.200 --> 08:09.200 We got 20 years of trusted computing. 08:09.200 --> 08:13.200 I know you don't like trusted computing because you like confidential computing. 08:13.200 --> 08:16.200 And this is kind of in that being cooperation. 08:16.200 --> 08:19.200 It is like kind of some small war. 08:19.200 --> 08:22.200 But the point is trusted computing working for 20 years, 08:22.200 --> 08:24.200 on improving the ecosystem. 08:24.200 --> 08:28.200 As bombs, you know, TPM, standardization of the protocol dies, 08:28.200 --> 08:30.200 then openness of the BIOS. 08:30.200 --> 08:33.200 All this work made around core boot and so on and so on. 08:33.200 --> 08:36.200 Harder true of the root of trust, also provisioning code. 08:36.200 --> 08:39.200 Harder true of trust we working hard on opening that. 08:39.200 --> 08:42.200 BMC also is we're opening that. 08:42.200 --> 08:45.200 We're going into some standardization versus PDM. 08:45.200 --> 08:48.200 Also dies in BMC appearing. 08:48.200 --> 08:51.200 Then we're saying, okay, let's don't trust this one. 08:51.200 --> 08:54.200 We will trust this one, which is like binary block. 08:54.200 --> 08:55.200 And it's closed source. 08:55.200 --> 08:57.200 We don't really know what is going there. 08:57.200 --> 09:04.200 So we essentially took all this work and transferred that to some closer to the ecosystem. 09:04.200 --> 09:05.200 Okay, that's fine. 09:05.200 --> 09:08.200 That's why, but let's now work on improving this ecosystem. 09:09.200 --> 09:11.200 So why this is wrong? 09:11.200 --> 09:14.200 Intel management engine story showing so many vulnerabilities. 09:14.200 --> 09:18.200 Single co processor is essentially a risk. 09:18.200 --> 09:21.200 And especially cross it source one. 09:21.200 --> 09:27.200 Then BIOS Richard openness with the core boot, then open seal from AMD. 09:27.200 --> 09:31.200 Essentially opens the silicon initialization part. 09:31.200 --> 09:36.200 So part of the initialization of the AMD processor was moved to ASP. 09:36.200 --> 09:39.200 The most secret part, memory initialization. 09:39.200 --> 09:42.200 But rest was left in the open. 09:42.200 --> 09:45.200 And now we can have totally fully BIOS for AMD. 09:45.200 --> 09:49.200 And this is what I will tell you about on later slides. 09:49.200 --> 09:51.200 Because that's essentially a huge achievement. 09:51.200 --> 09:55.200 And thanks to thanks to the AMD. 09:55.200 --> 09:57.200 Yeah, this is what I said. 09:57.200 --> 10:00.200 Yeah, this is like skis of RAM, yeah. 10:00.200 --> 10:02.200 Okay, AMD co founded the Kaliptera. 10:02.200 --> 10:04.200 There's really great spec. 10:04.200 --> 10:07.200 It's the everything is well thought. 10:07.200 --> 10:08.200 Really really respect. 10:08.200 --> 10:12.200 I just hope that at some point we will have this chip in regular devices. 10:12.200 --> 10:15.200 And really the promise of the spec will deliver. 10:15.200 --> 10:18.200 But on the one side we have Kaliptera. 10:18.200 --> 10:20.200 And on the other side they deliver this. 10:20.200 --> 10:22.200 So I'm not sure I don't understand this. 10:22.200 --> 10:27.200 Unless at some point Kaliptera will replace AMD security processor. 10:27.200 --> 10:32.200 And this is quote from Brian Kelly from Microsoft who's Kaliptera architect. 10:32.200 --> 10:35.200 Great security compromised by other great ideas. 10:35.200 --> 10:37.200 Start to weaken its security posture. 10:37.200 --> 10:41.200 So the point is that if security project is successful. 10:41.200 --> 10:43.200 Then there's money in that project. 10:43.200 --> 10:46.200 And there are managers who wants to create new features for the project. 10:46.200 --> 10:50.200 More features, more features, bigger PCB, more vulnerabilities. 10:50.200 --> 10:53.200 And essentially good project is no longer good project. 10:53.200 --> 10:54.200 Yeah. 10:54.200 --> 10:58.200 So we have to be conscious about that part. 10:58.200 --> 11:01.200 So let's start what we build. 11:01.200 --> 11:03.200 So this is state from last year. 11:03.200 --> 11:05.200 This has state of high assurance. 11:05.200 --> 11:08.200 Confidential infrastructure from last year. 11:08.200 --> 11:12.200 So you see that we already got operating system open. 11:12.200 --> 11:16.200 Yeah, we we even have firmware in this VMs open. 11:16.200 --> 11:18.200 We got open hypervisors. 11:18.200 --> 11:20.200 Firmare not really bios. 11:20.200 --> 11:21.200 No no. 11:21.200 --> 11:24.200 Sometimes BMC for some platforms. 11:24.200 --> 11:28.200 But then we didn't know like what kind of proprietary pieces are there. 11:28.200 --> 11:32.200 Sometimes BMC could be OTP fuse it to boot just the open. 11:32.200 --> 11:33.200 Excuse me. 11:33.200 --> 11:37.200 Just operating system vendor wants GPU definitely not. 11:37.200 --> 11:42.200 The that the test execution environment security manager definitely definitely. 11:42.200 --> 11:46.200 So ASP or whatever Intel has like management engine. 11:46.200 --> 11:47.200 Definitely not. 11:47.200 --> 11:51.200 Of course we have IBM and and arm, which is like a little bit more open. 11:51.200 --> 11:53.200 But that difference that's different story. 11:53.200 --> 11:55.200 And it's in CPU also. 11:55.200 --> 11:56.200 Some platforms got. 11:56.200 --> 11:58.200 Intel boot got provision at some note. 11:58.200 --> 11:59.200 So it depends. 11:59.200 --> 12:01.200 So this was of course a level. 12:01.200 --> 12:02.200 We just were thinking. 12:02.200 --> 12:03.200 Okay, what's going on here? 12:03.200 --> 12:04.200 Where is the platform? 12:04.200 --> 12:05.200 Which platform we should choose? 12:05.200 --> 12:07.200 Which will give us ability to implement that. 12:07.200 --> 12:09.200 And then this we know already. 12:09.200 --> 12:11.200 Thanks to open seal and core boot dot. 12:11.200 --> 12:12.200 Yeah, we can do this. 12:12.200 --> 12:14.200 That's why it was already planted. 12:14.200 --> 12:16.200 And. 12:16.200 --> 12:19.200 Okay, little bit about the open open seal. 12:19.200 --> 12:21.200 I already told you about little bit about it. 12:21.200 --> 12:24.200 So who knows Agissa and the Agissa. 12:25.200 --> 12:26.200 Okay, some. 12:26.200 --> 12:32.200 So I'm the Agissa is a is a silicon initialization component that is added to BIOS by AMD. 12:32.200 --> 12:36.200 So yeah, this is secret source for for an initialization of the silicon. 12:36.200 --> 12:38.200 Yeah, it's like Intel FSP also. 12:38.200 --> 12:44.200 The the point here is that Intel FSP took into consideration integration with the core boot. 12:44.200 --> 12:48.200 So they have special mode of Intel FSP to integrate with open source BIOS. 12:49.200 --> 12:55.200 And AMD did not of course there were really days of of AMD where they completely open source Agissa. 12:55.200 --> 12:57.200 And it was included in the core boot. 12:57.200 --> 12:58.200 But that's not what I'm talking. 12:58.200 --> 13:00.200 I'm talking about the modern platform. 13:00.200 --> 13:02.200 It's not the very legacy one. 13:02.200 --> 13:03.200 So this was not all the table. 13:03.200 --> 13:06.200 This was not all the table because this has been iron broke. 13:06.200 --> 13:09.200 And then we have open seal, which is fully open source is on. 13:09.200 --> 13:12.200 I guess MIT license on GitHub. 13:12.200 --> 13:14.200 Everyone can contribute to it. 13:14.200 --> 13:16.200 And we already did quite a lot of that. 13:16.200 --> 13:19.200 It consists of three libraries. 13:19.200 --> 13:26.200 Silicon initialization for memory and CPU part of the initialization platform reference 13:26.200 --> 13:30.200 Firmare for platform right at configuration. 13:30.200 --> 13:35.200 And utilities is at service if someone wants to add something more to this to this part. 13:35.200 --> 13:38.200 But you know typically we want to leave it as small as possible. 13:38.200 --> 13:45.200 And this was contributed to OCP as a standard in September 2025, which is very, very good. 13:45.200 --> 13:53.200 And of course what we still have this one, I will not torture AMD more. 13:53.200 --> 13:54.200 Okay. 13:54.200 --> 13:56.200 So let's look at the boot chain. 13:56.200 --> 13:58.200 How it looks like? 13:58.200 --> 14:00.200 This is how it looks like before. 14:00.200 --> 14:03.200 So we got some root of trust in our AMD security processor. 14:03.200 --> 14:08.200 Then we have independent bios vendor framework, which we have no idea what's going on inside. 14:08.200 --> 14:12.200 Something, something binary blocks and essentially closed source. 14:12.200 --> 14:17.200 We knew that they integrated Agesar because that they needed for initialization of the AMD silicon. 14:17.200 --> 14:19.200 And maybe they added some other features. 14:19.200 --> 14:23.200 And then at some point we started hypervisor and from that combination VMs. 14:23.200 --> 14:24.200 So we moved. 14:24.200 --> 14:29.200 This is what 3M depth contributes with our code to cardboard. 14:29.200 --> 14:34.200 So this one is just the standard boot process of cardboard. 14:34.200 --> 14:39.200 And you can see that open seal is kind of blue at the RAM state level. 14:39.200 --> 14:43.200 So this is one of the stages of booting of cardboard. 14:43.200 --> 14:48.200 We cannot, we couldn't do this with Agesar because it's UFI only. 14:48.200 --> 14:51.200 And RAM state cardboard does not implement this interface. 14:51.200 --> 14:53.200 So this was not an option. 14:53.200 --> 14:56.200 But this was possible to implement everything. 14:56.200 --> 14:58.200 Every each step is is open. 14:58.200 --> 15:01.200 It's contributed upstream mostly merged. 15:01.200 --> 15:04.200 Okay. 15:05.200 --> 15:08.200 Okay. 15:08.200 --> 15:10.200 This is the hardware. 15:10.200 --> 15:13.200 This is Gigabyte MZ33-IR1. 15:13.200 --> 15:15.200 Turing by Splatform. 15:15.200 --> 15:21.200 We know that it's not provisioned with PSB unless they will change something in shipping. 15:21.200 --> 15:23.200 But right now it is not. 15:23.200 --> 15:26.200 We already confirmed there is no security in VMC. 15:26.200 --> 15:28.200 So VMC is also possible. 15:28.200 --> 15:33.200 So this is first retail server hardware, which will be shipped with open source firmware. 15:33.200 --> 15:37.200 For the introspection in the confidential computing environment. 15:37.200 --> 15:39.200 This is story on our blog post. 15:39.200 --> 15:42.200 So this was the size of the contribution without SVSNP. 15:42.200 --> 15:47.200 It was 13, 30,000 lights of code 80 for patches to cardboard. 15:47.200 --> 15:53.200 7 to open seal around, you know, 3.7 of open seal code base was delivered with that work. 15:53.200 --> 15:58.200 You can read about that using those links, rights are on the website. 15:59.200 --> 16:00.200 Okay. 16:00.200 --> 16:08.200 A little bit about the SVSNP implementation around 900 lines of code in cardboard and open seal. 16:08.200 --> 16:10.200 This is what was delivered. 16:10.200 --> 16:13.200 So yeah, I guess I will not dive into this. 16:13.200 --> 16:20.200 It's like some PSP initialization, some memory integrity protection initialization mailbox for PSP. 16:20.200 --> 16:34.200 So like some basic stuff to establish relation with with a SP with PSP to be able to run this feature on the open source feed my files. 16:34.200 --> 16:35.200 Okay. 16:35.200 --> 16:36.200 This is attestation. 16:36.200 --> 16:39.200 I also think most of you know what's going on here. 16:39.200 --> 16:41.200 So we have our confidential VM. 16:41.200 --> 16:44.200 We have this project SNP guest. 16:44.200 --> 16:49.200 We just creating a report which talks with AMD secure processor. 16:49.200 --> 16:55.200 It using this vendor chip and those met key to sign it returns reports. 16:55.200 --> 16:58.200 Then we fetch from the AMD server certificates. 16:58.200 --> 17:00.200 We check that everything is okay. 17:00.200 --> 17:03.200 Yeah, which checking that this sign is okay. 17:03.200 --> 17:09.200 And then we can attest that whatever we get here from AMD SP is correct. 17:09.200 --> 17:12.200 And then we will go to the yeah. 17:12.200 --> 17:15.200 Attestation is completed. 17:15.200 --> 17:18.200 Okay, demo time. 17:18.200 --> 17:21.200 Let me go here. 17:21.200 --> 17:46.200 Yeah, so first of all, we showing this is really core boot. 17:46.200 --> 17:50.200 And that this is this gigabyte platform. 17:50.200 --> 17:52.200 Then we showing that the kernel. 17:52.200 --> 17:55.200 This is Ubuntu that the kernel really detected the features. 17:55.200 --> 17:58.200 And what kind of features are enabled. 17:58.200 --> 18:10.200 Then we start in QAMO with AMD SCV BIOS and all the required parameters. 18:10.200 --> 18:20.200 And inside, we will essentially run this SNP guest report and confirm that the auto stations exceed. 18:20.200 --> 18:35.200 Maybe I can make it a little bit faster. 18:35.200 --> 18:38.200 The SNP guest. 18:38.200 --> 18:41.200 We use root. 18:41.200 --> 18:46.200 We're checking the features that the features are really recognized by the. 18:46.200 --> 18:56.200 That we are in VMPL zero that the features are really recognized by the QAMO KVM. 18:56.200 --> 18:59.200 Yeah, we have to load the module. 18:59.200 --> 19:03.200 And then we're going to generate report. 19:03.200 --> 19:05.200 Yeah, the report is generated. 19:05.200 --> 19:12.200 Then we have to fetch all the keys from the server. 19:12.200 --> 19:17.200 Yeah, which vendor, we fetch vendor chip and also in key, 19:17.200 --> 19:21.200 with which that the keys are correctly signed. 19:21.200 --> 19:26.200 And then we do the auto station and confirm that everything. 19:26.200 --> 19:29.200 There's certainly a much is the attestation report and so on. 19:29.200 --> 19:31.200 So that's what was delivered. 19:31.200 --> 19:36.200 And let me get back to slides. 19:36.200 --> 19:38.200 And this is the state after. 19:38.200 --> 19:40.200 So the next slide is maybe better. 19:40.200 --> 19:41.200 This is better. 19:41.200 --> 19:42.200 So this is what changed. 19:42.200 --> 19:45.200 So we have no keys here. 19:45.200 --> 19:47.200 We have no keys here. 19:47.200 --> 19:49.200 We deliver this part. 19:49.200 --> 19:52.200 Of course, this part and this part stay close. 19:52.200 --> 19:54.200 We provide that there is no key here. 19:54.200 --> 19:57.200 And then because of that, we planning this one. 19:57.200 --> 20:01.200 We planning OpenBNC with fusing. 20:01.200 --> 20:03.200 Also fusing for the CPU. 20:03.200 --> 20:05.200 And we already delivered this part. 20:05.200 --> 20:09.200 So we have BIOS, which is open for your in-spoke 20:09.200 --> 20:11.200 Interspection of the. 20:11.200 --> 20:12.200 Yeah, I have to finish. 20:12.200 --> 20:14.200 So I will just tell you. 20:14.200 --> 20:16.200 There are kind of some backup slide. 20:16.200 --> 20:18.200 But I will just tell you what's the future of that. 20:18.200 --> 20:21.200 The future is that we have to complete the upstreaming. 20:21.200 --> 20:23.200 We would like to offer. 20:23.200 --> 20:24.200 The shot already. 20:24.200 --> 20:27.200 So the shot is like a downstream distribution of the core boot, 20:27.200 --> 20:29.200 which trimmed up many things. 20:29.200 --> 20:32.200 So we will sell the gigabyte hardware with this. 20:32.200 --> 20:34.200 But you don't have to buy from us. 20:34.200 --> 20:36.200 You can buy the hardware yourself and flash yourself. 20:36.200 --> 20:38.200 Compile and flash yourself. 20:38.200 --> 20:41.200 And it would be great if you could deliver some feedback. 20:41.200 --> 20:44.200 And some essentially testing because, you know, 20:44.200 --> 20:46.200 there are memory testing. 20:46.200 --> 20:48.200 Perifer testing is very important. 20:48.200 --> 20:52.200 The next thing is SCV trusted IO for GPU accelerators. 20:52.200 --> 20:54.200 I hope my being next year I can show that. 20:54.200 --> 20:56.200 And participation in OpenSFI. 20:56.200 --> 21:01.200 And in future, I hope we can contribute the same stuff for the other 21:01.200 --> 21:03.200 confidential computing pieces. 21:03.200 --> 21:05.200 And that's it from my side. 21:05.200 --> 21:09.200 And we can, I don't know if we have any time for question. 21:09.200 --> 21:11.200 Thank you very much. 21:11.200 --> 21:15.200 Yes. 21:15.200 --> 21:19.200 So when it's like something you were talking about. 21:19.200 --> 21:22.200 But you were talking so. 21:22.200 --> 21:24.200 Which one is it? 21:24.200 --> 21:26.200 Is it green and draw a post? 21:26.200 --> 21:28.200 What kind of protocol is it using? 21:28.200 --> 21:30.200 You're just going like. 21:30.200 --> 21:32.200 So let's be honest. 21:32.200 --> 21:33.200 I'm not expert with attestation. 21:33.200 --> 21:35.200 We're using an SNP guest. 21:35.200 --> 21:38.200 You can, that's open source project from AMD. 21:38.200 --> 21:41.200 You can check the source code and see how they doing it. 21:41.200 --> 21:44.200 I don't know because I didn't expect that source. 21:44.200 --> 21:46.200 That's not my point of this presentation. 21:46.200 --> 21:49.200 The point of presentation is showing that I'm giving open source 21:49.200 --> 21:52.200 Firmary-based platform for researchers' introspection. 21:52.200 --> 21:53.200 That might go. 21:53.200 --> 21:56.200 And attestation ecosystem and binaries for 21:56.200 --> 21:57.200 Acestation is your topic. 21:57.200 --> 21:59.200 It's confidential computing developers. 21:59.200 --> 22:01.200 Researchers architect topic. 22:01.200 --> 22:02.200 That's not my topic. 22:02.200 --> 22:04.200 Yes? 22:04.200 --> 22:05.200 Good question. 22:05.200 --> 22:07.200 The memory that I've insinitation. 22:07.200 --> 22:09.200 Is there any purpose in this? 22:09.200 --> 22:11.200 Is it new to scope open? 22:11.200 --> 22:13.200 Yes. 22:13.200 --> 22:17.200 Is it a memory-genization scope of the open-seal? 22:17.200 --> 22:18.200 No. 22:18.200 --> 22:22.200 The most secret code was moved into PSP into PSP. 22:22.200 --> 22:25.200 And that's why they can reveal all the other stuff. 22:25.200 --> 22:28.200 That's why they give open-seal to the public. 22:28.200 --> 22:30.200 That's, I think that's good choice. 22:30.200 --> 22:33.200 Now we have to fight the next stage. 22:34.200 --> 22:35.200 Yeah. 22:35.200 --> 22:40.200 For your conduct, so you have only your roadmap into TDS. 22:40.200 --> 22:43.200 I'm sent a lot of what you did for your personal platform. 22:43.200 --> 22:45.200 By the way, is it possible to go to open-seal? 22:45.200 --> 22:47.200 Is there something similar for Intel? 22:47.200 --> 22:48.200 Yes. 22:48.200 --> 22:50.200 It's Intel at the SP, it's closed source. 22:50.200 --> 22:55.200 Is it possible open source firmware for Intel and Intel TDX? 22:55.200 --> 23:00.200 To some extent, Intel keeps more proprietary closed source 23:00.200 --> 23:01.200 groups. 23:01.200 --> 23:05.200 So, AMD got open-seal, Intel got Intel FSP. 23:05.200 --> 23:08.200 Intel FSP is closed so far and I don't think they will open it. 23:08.200 --> 23:09.200 So, that's the limitation. 23:09.200 --> 23:14.200 We have other platform, ASROR, CRAC, which you can find on our website. 23:14.200 --> 23:17.200 Suffer app is, I guess, supports TDX. 23:17.200 --> 23:18.200 A lot of question. 23:18.200 --> 23:21.200 I'd know, like, what kind of level of TDX features its supports. 23:21.200 --> 23:23.200 We already have DashROR for it. 23:23.200 --> 23:24.200 So, there is open source for it. 23:24.200 --> 23:25.200 Yeah. 23:25.200 --> 23:29.200 So, there is possibility for researcher to enter something and check how much open it is. 23:29.200 --> 23:34.200 So, what's the roadmap to what's having the system before it? 23:34.200 --> 23:37.200 We are going to do things like the GPU, the network. 23:37.200 --> 23:39.200 We have to keep our control up. 23:39.200 --> 23:43.200 I mean, we have that business power in the home, because it's power to go out. 23:43.200 --> 23:45.200 But that's been a while ago. 23:45.200 --> 23:50.200 And I haven't seen anything similar to that's called on our AMD 64. 23:50.200 --> 23:51.200 Yes. 23:51.200 --> 23:56.200 So, the question is, what about other components like GPU firmware? 23:56.200 --> 24:01.200 And, and the second was, this is a component. 24:01.200 --> 24:02.200 We have to keep our control. 24:02.200 --> 24:03.200 We have all these other things. 24:03.200 --> 24:04.200 Network, keyboard control. 24:04.200 --> 24:06.200 So, and essentially periphery controls. 24:06.200 --> 24:07.200 Yes. 24:07.200 --> 24:09.200 Platforms are full of firmware, full of proprietary firmware. 24:09.200 --> 24:11.200 I'm not sure we can do everything. 24:11.200 --> 24:13.200 We are just small company. 24:13.200 --> 24:14.200 Like, help us. 24:14.200 --> 24:16.200 Like, let's do it together. 24:16.200 --> 24:21.200 Yes, there is work in almost every piece of ecosystem. 24:21.200 --> 24:25.200 And we just have to push forward to propose something, 24:25.200 --> 24:29.200 to show that the closer it's site, that a lot of CVs, that's our work. 24:29.200 --> 24:31.200 Regarding the power, we did the power. 24:31.200 --> 24:37.200 We did the transition of the C++ 800,000 lines of code of C++ to see the gore boot. 24:37.200 --> 24:42.200 There is some small false promise there, which I can talk about you after, 24:42.200 --> 24:46.200 because that's, with thinking that everything is completely open source on power, 24:46.200 --> 24:48.200 but there are some missing specs. 24:48.200 --> 24:49.200 Yeah? 24:49.200 --> 24:53.200 You know, the thing that you can actually reverse the layer search, 24:53.200 --> 24:56.200 and well-impeared, we see the chasing that vendors will be producing, 24:56.200 --> 24:58.200 as a specular specification. 24:58.200 --> 25:01.200 We are pulling them to three years. 25:01.200 --> 25:07.200 We see them to create this location based on the observations from the open source projects. 25:07.200 --> 25:09.200 One example is the feedbacks. 25:09.200 --> 25:10.200 There's a new version. 25:10.200 --> 25:12.200 Valet IO, which is on PCI. 25:12.200 --> 25:14.200 There is no hardware on that. 25:14.200 --> 25:17.200 And that's where you can get it's 336. 25:17.200 --> 25:24.200 So at least 1, 2, 3 years after we're going to get something on the PX 2.0. 25:24.200 --> 25:28.200 Yeah, so emulation is one thing we should push. 25:28.200 --> 25:34.200 So the question is, if we can somehow reverse with the proprietary vendors to have something 25:34.200 --> 25:38.200 earlier, or we'll cooperate with open ecosystem to have the features earlier, 25:38.200 --> 25:40.200 then they release hardware. 25:40.200 --> 25:45.200 And yes, I think they, so Intel do in Cmix, I think they should release more in Cmix, 25:45.200 --> 25:49.200 and essentially provide working models for those advanced features. 25:49.200 --> 25:52.200 QM could also get the contribution. 25:52.200 --> 25:59.200 What would be the rough cost for a lunch system based on this? 25:59.200 --> 26:01.200 That's a very good question. 26:01.200 --> 26:06.200 It really, yeah, what would be the rough cost for this system? 26:06.200 --> 26:08.200 What we did here was very expensive. 26:08.200 --> 26:09.200 I will tell you. 26:09.200 --> 26:11.200 It's not easy project. 26:11.200 --> 26:15.200 It's not sponsored by NLNet, but NLNet also kind of finishing sponsoring, 26:15.200 --> 26:17.200 and also we have to leave somehow. 26:17.200 --> 26:23.200 Yeah, so it would definitely be margin on top of the, on top of the regulars. 26:23.200 --> 26:25.200 It would be very hefty margin. 26:25.200 --> 26:29.200 But on the other side, I don't expect you to pay that margin, because you are the hackers. 26:29.200 --> 26:31.200 I don't want to earn money on hackers. 26:31.200 --> 26:32.200 I don't care. 26:32.200 --> 26:35.200 I care about those who want to benefit from open ecosystem, 26:35.200 --> 26:38.200 without contributing to this ecosystem. 26:38.200 --> 26:39.200 They will pay. 26:39.200 --> 26:43.200 You can take the platform, get the code, compile yourself, and necessarily flash. 26:43.200 --> 26:44.200 And that's for free. 26:44.200 --> 26:53.200 The board cost, like, you know, the board cost is nothing comparison to memory cost. 26:53.200 --> 27:00.200 So for, so it really depends which CPU you will use. 27:00.200 --> 27:02.200 Yeah, it really depends on that. 27:02.200 --> 27:07.200 I don't know what's the right now, how much 600 euro or something for this motherboard or something. 27:07.200 --> 27:08.200 You can, isn't it? 27:08.200 --> 27:13.200 Check, NZ33, A01, eBay, and check what's the price. 27:13.200 --> 27:17.200 Hi, I'm wondering if you looked into it, like, the code driver, 27:17.200 --> 27:22.200 or the NLNet, which driver? 27:22.200 --> 27:23.200 Which driver? 27:23.200 --> 27:25.200 The code driver of the CPU. 27:25.200 --> 27:26.200 Cove driver? 27:26.200 --> 27:27.200 Go. 27:27.200 --> 27:28.200 Ah, go. 27:28.200 --> 27:29.200 Graphical driver. 27:29.200 --> 27:31.200 No, no, no, no, no, no, no, no. 27:31.200 --> 27:35.200 This is not yet, maybe when we will get into a CV trusted IOR, 27:35.200 --> 27:38.200 this would be something which will be more interesting, 27:38.200 --> 27:41.200 because we will have some security story there. 27:41.200 --> 27:44.200 Yeah, because that's, you know, I'm working on the thing report. 27:44.200 --> 27:48.200 So I'm trying, but you need that information. 27:48.200 --> 27:49.200 Cool, cool. 27:49.200 --> 27:51.200 So we can, like, we definitely, if you will publish it, 27:51.200 --> 27:56.200 we definitely can pick up and, and think. 27:56.200 --> 27:57.200 All right. 27:57.200 --> 27:58.200 Thank you again. 27:58.200 --> 27:59.200 Thank you very much. 27:59.200 --> 28:01.200 Thank you.