So, we can start. So, as you may know, currently, we are mostly focusing on Intel TXT platforms
because this is first implementation on which we are working on and it provides not
only the TXT implementation, but also generic code and structures which will be used for further
development for AMD, ARM, etc. So, this is the key thing which should be introduced into
the kernel itself. As you can see, I think that we are nearing to the point where this
part of this will be taken into the kernel itself. In the meantime, there was introduced
a quick start guide on the transport project because at this point it is quite difficult
to first of all find platforms which work with the transport and the other problem is that
it is quite difficult to configure the software to run this project. So, we have a quick
start guide which guides to you through the process setting up the environment and the software.
Also, we are working on various versions of raw speed working, various versions of implementation
from TXT. There are three releases in last few months, version 10, 11 and 12. In general,
there were mostly discussions recently happening around Shawan and why we are using Shawan
and maybe we will use a different kind of functions to calculate houses from the TPM. So, it
was quite tough discussion, but I think that during reviewing V11, all questions were solved
and rostered V12 and at this point, I think everything will be shortly accepted. But we
can see because there is no error play from the kernel community. We are going to poke some people
into your peoples. Also, the AMD is still under development. In general, we are, of course,
we are basic our development on IntelTXT implementation for year OEMs. So, there are some
things which should be hidden in early stages. From the kernel, it looks that it is possible.
So, the kernel will be quite generic and it will be able to work on various hardware.
So, I hope that it is going quite good direction, but as I said, this is in early stages.
We are focusing mostly on X86 at this point. The group, the group part is also very important
think of the stuff because the crop prepares all the platform for the secure launch. So, it contains
all components which are needed to initialize the platform. And all developments were tied to
mostly at this point to IntelTXT implementation. But, unfortunately, as you may know, we have
values, grap implementation for various distros, distros and also we have upstream. So, initially,
some parts of development were based on downstream staff, some part were based on upstream.
Ross was able to move all this code to the upstream and also free-ended folks,
based some of all this stuff for AMD on the IntelTXT implementation made by Ross.
Also, we were able to make some preparatory parts into the grap upstream. They are just providing
some just cleanups in the code. So, it is just preparation, nothing else. There is no functionality.
When the IntelTXT land in the kernel, then we almost immediately finish reviewing the patches
in the grap and take them into the, into the grap. And also, as I said,
if we am deprovised, AMD's can eat and post it RSC patches on December 18. So, it is
available on the grap developer. You can play with it, test it and send us our reports.
So, it's that's it for my site. Let's move on to my stuff.
Thank you for your time. Any questions?
When we are switching, no. So, we will have more questions after.
Okay, so as I said, I will cover the part that VMDEP has been worked on in the last year.
So, I match it and the engineering manager at VMDEP. Although most of the technical work has been done by
colleagues, mostly Christian, Sergi and others. They also were kind enough to help me with this presentation.
Again, I've pretty simple for today. We present what we've been working on since the
during the last year and what are the future plans. So, we have two main work streams in VMDEP.
On the one side, the first area is implementation of the original DRT and task for AMD
in contrast to the new one. Let's say for which in which Oracle was most invested in.
In this case, we are working on the Linux kernel boot path mostly.
And the second one is practical application of transport as keeps us anti-vmite application.
In this case, we are obviously more focused on the design. Boot path as keeps us using this one.
So, let's start with the first one. So, transport for AMD, let's say, so we have
basically updated the existing code we had to then use version of specification to use
a secure entry resource table. We have also integrated our challenges with the ones from
Oracle. So, we can have a single code base, which would work on the older and newer AMD CPUs.
On top of that, we've been adding some tests to our test suite, which is open-surfing validation.
And we've updated over fresh some of the trend boot documentation with our current development.
There were a huge keynote there, might do during the last year. So, should be more user friendly.
What's also what's now think here is that really wise method transport,
y'all are, it can be used for testing and demonstration. So right now, we can use it to build a single
generic image. It can support at the same time like a case UFI boot. It can support Linux
and the example you can select, you want to test Linux, you want to test Zen, you want to normal, you want to
between 3D boot. It's a part of the Intel AMD. So, you can have a single image that you can use for
evaluation of a hardware, for instance, if you can work with 3D boot.
In terms of plans and what's in progress, it's mostly upstream, we have finalized the main development
in this part. The Linux Intel series has been described by Daniel. We are kind of depending on
that in the Linux kernel as it contains also a common code that AMD Chinese require.
We have successfully submitted a small portion of the graph patches, but there has also
depends on the Linux kernel upstream because we want to have stable Linux first, at least that's the
that the policy in graph right now. Then we have the second one, which is runs boot as
cube stress and Tbilmite solution. So, there are also a couple improvements there. We have finalized
the GAC boot part. We have extended the graph so it can look for all of the disease. So, the
secure kernel folder for AMD and different kinds of ICNs for different Intel micro architecture.
So, user doesn't need to select the proper one, it's selected automatically, which
leads us to more generic image and better user experience. We have some RPM repository that can
be used to ship a kip size packages with trend boot changes. What's in progress? It's advanced,
but it's still not released let's say that we are fine, part with kip size. So, there's a lot of
configuration to play skill as well. So, Intel AMD, with AMD we have to kind of
the RK.
A parent is boring. Or something is not clear.
Oh, we have a cache go ahead.
So, we're asking about booting Kleg AC in the GAC mode. So, as we shown in the GAC part we are
more advanced. So, we could definitely, maybe it's not plug and play because there are
different components, but definitely we could like try this meta-trans boot build and image and
boot it on your specific hardware and see if that works. That's why you can
maybe perhaps the easiest one to try it yourself. You can reach out in as in the nitrix and we can
guide if there is any problem with that, but the GAC mode is definitely more advanced, I would say.
I want to add to this because if I understand correctly we are saying about BIOS implementation.
So, for using mostly on BIOS in implementation of DRTM and Oracle mostly focus on EFI,
but in general the idea is that this DRTM implementation on X86 has to work on both platforms, EFI
and legacy BIOS. This is the approach. So, all these things will be glued together and will work
in delinux and the graph. I hope that this applies your question. Okay, thanks a lot.
Any additional questions? Go ahead. So, how can I test for AMD on legacy? What's that like
easiest to upload on what platform it's easier to upload? I'm not platform. We used to
I have listed here the KGPE and maybe the other one, HP. HP1 is the one we use right now for
there isn't development. It's like stock firmer not anything from us so to speak, but it can be
used for cubes specifically because we had also the other ones like the APU PC engines, but it's not
cubes target, but you can still use the method range boot on PC engines with the color boot
firmer, legacy firmer, but for something maybe you can use KGPE, KGPE, maybe that one is what we
testing running some test against right now. And similar question for UFI is there and isn't in
a state that I could drop some hotness and try with UFI to try to get there on the internet or
I think so maybe not so the question was if if the UFI is in the same state as the Gasey
so we can just grab some photos and test that. The answer is I think so but maybe not all of that is
up to date in this method trend boot stuff which points to the specific
revisions of each component. So my definitely that would be like a part of this in progress
my stone which will be have like a block percent snapshot of what's definitely working but
I'm pretty sure that at this point we could already discuss and help you with testing something
out in UFI as well. I think both definitely definitely Zana is the one we've been working on
lately. In booting there TM stuff on Intel platforms and on IMD both so as magic I suppose magic
when we were talking about AMD implementation for UFI to send us directly but UFI for UFI sorry
DRTM for UFI platforms and Intel should work because we are using it internally if if you have any problems
drop us a line and we'll help you solve them. Yes yes yes yes yes we don't use as an O we use Linux
we don't work with we've done. I know and you will have more problems with then only DRTM
and the other questions. Okay the question was what the state for OptiPlex? I think we've tested
one of the phases on OptiPlex we've seen by us so yeah it should be possible to replicate that yes.
Another question is at all KX like are you planning to import grab like that code to KX?
The question is if we are planning to import grab like that code to KX, I'm not aware of the
plans. I'm not sure I understand the question. Are you asking about supporting KX from the
grab? I think it's really exciting. So let's say okay yes we were discussing this internal in
the Oracle and we have idea we're doing this with grab as intermediary state. So it was discussed
because but there is no code there are some ideas but as I said currently we are focusing mostly on
putting directly from the hardware not switching once again through KX to to to to to to.
So you're meant to pay X from the window to the grab yes because we will be this is quite crazy idea