So let's start.
So thank you for that.
So you already know a bit about the TrendWolf project.
So now we will take a look about another practical application of TrendWolf project as an anti-eveal
solution in QPSOS.
My name is Maciej.
I am currently over seven years in FremDep, currently at the position of engineering manager.
I open source enthusiast interested in bedlet systems contributing to various open source projects.
As FremDep we are involved in various open source communities, mainly Corbuth, Yocto, but also others such as FWPD.
We are also pop-and-power foundation members.
We did some work on Raptor Talos 2 Power 9 platforms.
So what we will talk about today, we had already some introduction about the TrendWolf in general.
Now we will have some introduction about QPSOS anti-eveal made solution based on TrendWolf.
What is its current state and what are the further plans.
So pretty simple.
Let's see.
So we will not cover the whole progress.
We have regularly updated on various conferences.
We've given some status updates on last two QPSOS summits.
So we will cover the progress since the last one, which was October last year.
You have links if you want to watch the previous ones.
Feel free to.
So just a few words about what eveal made attack is and why we want to prevent that with TrendWolf.
So eveal made attack is a one when you leave your device unattended.
Someone has physical access to that and can tamper with that.
And you, for instance, come back to your hotel room and you don't know whether your device was tampered with or not.
Anti-eveal made solution aims to provide you with some tools to maybe not prevent
because that would be quite difficult to prevent such attacks,
but at least give you some information whether your device was tampered with by some external person or not.
In terms of QPSOS, we have QPSOS anti-eveal made solution which was already there.
It's a set of scripts.
Right now we are improving extending attack based on TrendWolf to support
broader variety of hardware, for instance, TPM 2.0.
And it requires TPM, so it requires some piece of hardware and also it requires DRTM,
which was mentioned before, so some silicon vendor feature
either from Intel by AMD currently.
So what's the current state?
In short, we have released two milestones in the last month
and we are just starting another one.
If you want more details, there are links to GitHub milestones.
These three were funded by the NLNet Foundation.
So links are there and we will now briefly cover each of them.
So the MySum number two, it was about QPSOS anti-eveal made solution on Intel boards with TPM 2.0
because previously we had only some support for 1.2.
As you saw before, there are many parts in TrendWolf project.
In the previous presentation we saw a bit maybe different use case
because we saw the one with Linux kernel, with QPSOS, we used Grub and then Zen hypervisor,
and not Linux directly.
So for each MySum, for each phase we have a set of GitHub actions
releasing the packages so we can download them and install in the QPSOS installation.
We also have blog post which describes how given MySum was verified
so we can also reproduce that if you are brave enough.
So as the project is ongoing progress, it takes already a few years in total, we can say.
There are some changes in the upstream trend boot protocol,
so the phase three was aiming to align with that with the TrendWolf anti-eveal made solution.
So again we have a set of packages you may use and install,
and we also have a nice blog post you can read to have some more insights on that one.
So we are just starting phase four as said before.
That one is about AMD platforms.
We want to cover both TPM 1.2 and 2.0 solutions.
We are still selecting hardware.
Right now we think about ASUS KGP-D16, it's quite old already,
but it allows us to verify both TPMs.
It can also have open source firmware based on core boot.
So that is one we might use here.
Another one is some super micro board.
There are some cubes for point two installation issues, we have some discussions open,
so we are still considering that one.
At least with the latest version there were some problems.
What are the further plans?
So after we finalized, or maybe not after, we are already scoping the phase five.
Its goal is to bring UFI support as well,
because so far all of the previous one were focused on the legacy boot only.
For the phase five we want to support both Intel and AMD platforms with both TPM 1.2 and 2.0.
So we are finalizing the scope to gather what needs to be done basically.
We plan to publish that as another Github milestone,
so if you are interested you can also follow that topic.
Definitely the UFI one is interesting, because nowadays it's the most common one for many boards.
So it opens up a wider, higher variety in terms of what we can actually test,
on which boards we can use that solution.
Another thing about our roadmap is further improvements of testing and documentation.
As you saw the project consists of multiple moving parts.
We have Zen, we have Grab, we have anti-vmage scripts.
Installation, even though we have some CI, we have some packages, CubeStyle packages being built,
it's still a tedious task to do it manually to test recent changes.
So we are aiming to automate that as much as possible.
In the last status we shown some progress in that area, but it was only on QMU to have some automated installation
of the anti-vmage solution. Right now we are pursuing to move that forward,
so we can also use that on real hardware units, not only on emulation targets.
And also it would be nice to automatically pick up packages from GitHub actions with rightest changes
to see what's the result is.
Another one we are interested in is upstreaming AMD Linux patches.
Maybe it's not directly related to the CubeStyle's anti-vmage solution, but to trend-root it is.
So Jack said about the Intel upstreaming effort, which is a very demanding task.
As we see it's version number 7 and counting.
We've secured an internet grant for AMD equivalent of that port, so we could be able to help here.
So we need to sync up on the latest changes with Oracle.
Ideally the Intel patches are merged so we can have easier time posting another set of patches for trend-root to the Linux kernel mailing list.
Another area we are interested in is as we are developing the Shara open source firmware for some of the platforms.
So we have control over the firmware part and we can make sure that all of the properties required to actually use the trend-root
can be properly configured.
And if there are bugs we can at least try to fix them.
So that would be very nice to have trend-root running with Cubes and perhaps also without Cubes
on different hardware targets supported by the Shara.
We already do use some of that.
For instance on the Dell OptiPlex one of the other series we use that's one for testing for the current phases.
So we use Corbett firmware with CBIOS as a reg AC solution to test what we currently have.
But we aim to also once the Phase 5 is completed with the UFI support,
support perhaps the Navacast and Laptos which are already certified in Cubes OS as well.
Another idea since that the testing is mostly done by us at that point.
We could use maybe some help if there are some folks interested in that.
We know actually we know there are because we have already some reports but it's not that easy to jump into that.
So we're considering also to make it a bit simpler.
Maybe set up currently you can already download packages from GitHub Actions from GitHub releases
but maybe we can set up a package repository with trend-root packages with trend-root patches.
So you can more easily install them and try them out if you are interested.
If that sounds interesting you can feel free to join Matrix Channel let us know so we can try.
We can gather some attention and see what can be done here.
So that was it. Any questions?
Sure.
I have a question.
As I saw you are strongly insisting on still implementing support for TPM 1.2.
I wanted to understand why do you want to support such hardware
and do you have any hardware which supports DRTM and TPM 1.2?
Very insisting.
So the question is why do we still support TPM 1.2 and do we have hardware supporting that?
Yes, we started with TPM 1.2.
So for instance the stations showed here they have TPM 1.2.
TPM 1.2 these are like...
Yes.
But they can run coreboot, they are really open source because they can have even more initialization
natively in coreboot without FSB, correct?
So they are quite similar for TPM PADS EX230.
So TPM 1.2.
When they were produced?
Quite a while ago but this is the last one that you can have fully open.
Ah, okay, right coreboot and FSB.
Yes, you can have a mini open source and ME discarded as much as possible.
So they are popular among those people which are here on the first day.
So some old plant-based signal support, they fire some of the back-up to the mic.
Of course.
I understand.
Yes, okay.
How's the U?
We were anyway.
I have to test the U5 1.4 TPM 1.2.
Yeah, I know.
And...
Two questions.
One, you mentioned you fetch in your CI packages from GitHub actions.
How you do that?
Because GitHub does a lot of fetching artifacts with authentication.
Yes, not... I mean we don't use that currently.
Oh sorry, the question was how do we fetch packages from GitHub actions?
We do not yet, so...
Yeah, I'm aware of that problem.
You can fetch from releases but not from the jobs directly.
Yes, that's a problem with GitHub actions.
We like GitHub CI for this reason also.
And the other question for UFI support, what to do about runtime services?
Oh, sorry.
Sorry.
I guess the question was about what to do about runtime services and I guess it's still a little bit discussed.
Or is that?
Yeah, there are some ideas to virtualize that.
Can you do that?
Yeah, is there a proof of concept from non-enables?
Yeah, another hypervisor do the same thing actually where they do runtime services in virtual environments.
So it's a common concept.
Yeah, yeah.
So you essentially isolate that through...
Yeah, that would be nice.
If that works?
As far as all is started, when the fumes start and then the hypervisor...
Something like that.
There is write up.
Okay.
Can you show me?
Sure.
Anything else?
This is the most recent publication on a non-enable blog.
Oh, so a colleague wrote a KVM hypervisor where he puts like EDK2 in that environment.
Yes, yes, yes.
What was that?
So he puts in the go KVM runs the EDK2 UFI in this environment.
What was the blog?
But this is about...
9 elements, 9 ESAC blog and the last post I guess is about that.
This sounds like running virtual firmware and not calling...
But that's part of this concept because this concept is like very long time, I guess like this, like we're going in that direction.
I mean, just the single things.
Yeah, I know.
Setting UFI variables.
You have to convince someone to contribute that.
There is another thing, capsules.
Thank you.
And you mentioned capsules.
Yes, capsules.
What are your calorie goals for that?
That's okay.
Always use some vulnerable pieces.
Yeah, for the better ways.
You know, I can set boot next to something and then reboot to capsule.
That's okay.
You still need to reboot to...
Yeah, like you may have it.
So one reboot more.
So you have at least two because if you want to reboot to the UFI, this is...
No, that's broken.
On most implementations.
Yeah, yeah.
Did you try it on the shadow?
I think yes.
And there is no bug about that.
I don't know.
Are you sure?
It's a bug about that.
Two minutes.
If this is so new that I don't know, I can...
I have last status...
Last status was Friday.
So you have access to the variables.
I need to start, I think.
It is not because you have to set variables to boot next to something.
Yeah, that's okay.
Potentially you can do a capsule.
And you can reboot via ACPI or something.
Yeah, exactly.
That works.
I think Windows do reboot via...
You have Wi-Fi?
Exactly.
ACPI.
I'm not sure.
It's a sort of graphic level bug.
It's my sort of...
My experience is that there are several firmwares that have broken the UFI reboot.
So we default to ACPI.
Yeah, okay.
Another question?
We have time for one more.
Okay, thank you.
APPLAUSE
Oh, yeah.