WEBVTT

00:00.000 --> 00:02.000
You

00:30.000 --> 00:57.000
Okay, okay, so and then finally we'll talk about how we can actually implement a supervisor

00:57.000 --> 01:01.000
that runs on Intel TDX.

01:01.000 --> 01:05.000
Okay, just very briefly about me, my name is Tondonan.

01:05.000 --> 01:11.000
My name is Dejop, is I do from the development, but I also developed a lot of other stuff in my spare time,

01:11.000 --> 01:15.000
and I also do a lot of security research, as Joel alluded to.

01:15.000 --> 01:20.000
I really like writing rust cards, and I also really enjoy writing low-level,

01:20.000 --> 01:26.000
kernel development stuff, and so like writing kernels, spoodlers, all that sort of low-level hardware stuff.

01:26.000 --> 01:34.000
I just want to quick note all the opinions presented in this talk, and I want to put both of my employer or any of my previous employers, you know, to go.

01:34.000 --> 01:39.000
Okay, so on a very high level, what is machine?

01:39.000 --> 01:47.000
The basic idea behind machine is to have workloads that transform inputs into outputs,

01:47.000 --> 01:51.000
and then have the integrity of all of that protected.

01:51.000 --> 01:57.000
So we don't want a potential in malicious hypervisor or in the other entity to mess with the input,

01:57.000 --> 02:01.000
the workload itself, or the output, or the output then.

02:01.000 --> 02:07.000
And the way we do this is that we use virtual machine-based confidential computing technologies,

02:07.000 --> 02:13.000
for example initially AMD SVSMP, but in this talk I'll actually present how we actually

02:13.000 --> 02:17.000
are protected to IntelTDX as well.

02:17.000 --> 02:21.000
Yeah.

02:21.000 --> 02:26.000
Okay, and so for example, one of the networking use cases for this, and also the primary use case,

02:26.000 --> 02:31.000
I had to mind with this, was to implement a trusted compiler cache.

02:31.000 --> 02:35.000
So usually, like as you all know,

02:35.000 --> 02:42.000
the company code is fairly complicated and processing in terms of process.

02:42.000 --> 02:46.000
And if you want to catch that, that could potentially save a lot of energy.

02:46.000 --> 02:53.000
The problem there, then, is that if there's a malicious party that injects malicious data into that cache,

02:53.000 --> 02:57.000
you suddenly can't trust the data in there anymore, and you might potentially get infected.

02:57.000 --> 03:02.000
And so in those cases, we want to protect the integrity of the actual input file,

03:02.000 --> 03:07.000
and we want to protect the integrity of the actual workload, which, in this case, might be, for example, GCC.

03:07.000 --> 03:14.000
And we also want to protect the integrity of the actual builds and compile binary that we get out in the end.

03:14.000 --> 03:18.000
And so those are exactly the entities that you could, for example, use a machine,

03:18.000 --> 03:22.000
the output will end with the output file and also an industrial port.

03:22.000 --> 03:26.000
And there's another whole separate process where you can actually use the industrial port,

03:26.000 --> 03:30.000
to verify that all the inputs are output, output, belong together,

03:30.000 --> 03:35.000
and that nothing was tampered with doing all of those processes.

03:35.000 --> 03:43.000
One thing that's really cool about machine is that usually with conventional conventional,

03:43.000 --> 03:50.000
conventional confidential VMs, you have workload directly exposed to the supervisor.

03:50.000 --> 03:54.000
The problem is that the workload is in a lot of cases,

03:54.000 --> 03:56.000
despite very nature, very complicated.

03:56.000 --> 04:00.000
Usually it's like on how operating system might be a Linux kernel or something,

04:00.000 --> 04:06.000
but the point is that it's very large, and that also naturally opens up a letter of place for potential attacks.

04:06.000 --> 04:10.000
What's special about machine is that it places a third entity in the middle of tools,

04:10.000 --> 04:12.000
which is called the supervisor.

04:12.000 --> 04:17.000
And the basic idea is that all data flows through the supervisor.

04:17.000 --> 04:20.000
So the hypervisor never has any chances to talk to the workload,

04:20.000 --> 04:24.000
and that reduces the attack surface for potential experts a lot,

04:24.000 --> 04:29.000
because all data that ever passes to the workload is sanitized.

04:29.000 --> 04:34.000
Another nice thing about the supervisor is that it completely abstracts away

04:34.000 --> 04:39.000
all of the confidential computing technology related stuff that's needed.

04:39.000 --> 04:44.000
So the workload doesn't have to care if it's running on AMD,

04:44.000 --> 04:49.000
or IntelGX, the supervisor just provides hardware independent abstractions

04:49.000 --> 04:52.000
that the workload can then use.

04:52.000 --> 04:54.000
Yeah.

05:00.000 --> 05:04.000
So to summarize, the supervisor acts as a sort of firewall,

05:04.000 --> 05:07.000
and the projects to workload from the hypervisor.

05:07.000 --> 05:10.000
At this point, you might be asking why can we trust the supervisor,

05:10.000 --> 05:12.000
but not the workload itself.

05:12.000 --> 05:16.000
And the answer to that is that the supervisor is much much much smaller.

05:16.000 --> 05:23.000
So, yeah, on IntelTDX, it's a little bit less than 2,000 lines of code,

05:23.000 --> 05:27.000
or in the S&P it's a little bit more than 2,000 lines of code.

05:27.000 --> 05:31.000
But either way, it's way, way smaller than the actual kernel that's used to run the workload,

05:31.000 --> 05:39.000
which is completely custom, but currently happens to be around roughly 31,000 lines of code.

05:39.000 --> 05:43.000
The supervisor's just much smaller, and so if someone wants to audit a system,

05:43.000 --> 05:46.000
the idea is that they just have the supervisor,

05:46.000 --> 05:49.000
they don't even have to look at the workload puzzle,

05:49.000 --> 05:52.000
and so also if the workload evolves over time,

05:52.000 --> 05:54.000
that doesn't have to be re-ordered,

05:54.000 --> 05:58.000
it's only the supervisor that has to be audited,

05:58.000 --> 06:02.000
and considering that the supervisor is pretty much feature complete,

06:02.000 --> 06:06.000
there are no major changes expected in the future.

06:06.000 --> 06:09.000
Another nice thing is that because the supervisor is so small,

06:09.000 --> 06:13.000
we can also apply a lot of hardware mitigations and other mitigations

06:13.000 --> 06:17.000
that would be more complicated to apply on the whole workload itself.

06:17.000 --> 06:20.000
And so, for example, we use some hardware mitigations,

06:20.000 --> 06:22.000
like shadow spec and forward branch breaking,

06:22.000 --> 06:25.000
but we also use some more esoteric stuff.

06:25.000 --> 06:29.000
For example, there is no heap, which just glutes all the whole class of memory corruption

06:29.000 --> 06:31.000
with little bullities, like heap rate at once.

06:31.000 --> 06:34.000
But there's also some even more esoteric stuff,

06:34.000 --> 06:38.000
we actually could put our boot, the page tables at compile time,

06:38.000 --> 06:40.000
and then the runtime we never even have to change them,

06:40.000 --> 06:43.000
and just once again, it's going to simplify stuff,

06:43.000 --> 06:48.000
and makes it a lot more secure, hopefully.

06:48.000 --> 06:51.000
Of course, then the question becomes,

06:51.000 --> 06:53.000
how can we actually enforce at a hardware level,

06:53.000 --> 06:56.000
that the hypervisor never talks to the workload itself,

06:56.000 --> 06:58.000
and the only talks to the supervisor.

06:58.000 --> 07:02.000
On IntelTDX, this is implemented using a special feature,

07:02.000 --> 07:04.000
called TGAttitioning.

07:04.000 --> 07:07.000
And the basic idea is that you have your confidential VM,

07:07.000 --> 07:09.000
and within that you have the main partition,

07:09.000 --> 07:12.000
but then you can also spawn secondary petitions.

07:12.000 --> 07:16.000
And you can sort of think of this as like nested VMs.

07:16.000 --> 07:18.000
It's not quite the same, but yeah.

07:18.000 --> 07:22.000
Also important to point out that even though they are like separate entities

07:22.000 --> 07:25.000
within the same VM, they are used to having cryptic keys,

07:25.000 --> 07:28.000
and so the main partition can access the memory of all other petitions,

07:28.000 --> 07:31.000
but not necessarily the other way around.

07:31.000 --> 07:35.000
And so in the end, as I said, this works a lot like VMs,

07:35.000 --> 07:38.000
and nested VMs, and in the sense that the main partition

07:38.000 --> 07:40.000
pretty much just drives the other petitions,

07:40.000 --> 07:42.000
like a hypervisor usually would.

07:42.000 --> 07:44.000
And this is of course really nice,

07:44.000 --> 07:47.000
because hypervisors have a lot of world access,

07:47.000 --> 07:49.000
and can do a lot of restrictions,

07:49.000 --> 07:53.000
that just, if you just want to workload on their metal,

07:53.000 --> 07:56.000
or like in a bare VM, that just wouldn't work.

07:56.000 --> 07:58.000
And so, like for example, one of the things that we can do,

07:58.000 --> 08:01.000
is that the first partition, the supervisor,

08:01.000 --> 08:04.000
can restrict the secondary partition,

08:04.000 --> 08:07.000
so that the secondary partition doesn't have

08:07.000 --> 08:10.000
the ability to access hypervisors shared memory.

08:10.000 --> 08:16.000
Another thing that we can do is like this goes more on the realm of like hypervisor mitigations,

08:16.000 --> 08:21.000
where we can actually make the kernel code that's used by workload completely mutable.

08:21.000 --> 08:23.000
In an ideal work we probably wouldn't need this,

08:23.000 --> 08:26.000
but if there is some vulnerability somewhere in there,

08:26.000 --> 08:29.000
maybe this eventually helps it because, well,

08:29.000 --> 08:32.000
if the kernel code is mutable, that prevents a lot of attacks.

08:32.000 --> 08:35.000
Another thing that's interesting is that,

08:35.000 --> 08:38.000
usually even with confidential VMs that we have today,

08:38.000 --> 08:43.000
the hypervisor is still in charge of injecting interrupts.

08:43.000 --> 08:45.000
And that has actually led to issues in the past.

08:45.000 --> 08:48.000
There have been some vulnerabilities in black Linux and so on.

08:48.000 --> 08:52.000
And once again, this is something that the supervisor abstracts away.

08:52.000 --> 08:55.000
The supervisor is in charge of injecting all interrupts

08:55.000 --> 08:56.000
and to the workload.

08:56.000 --> 08:59.000
And of course, the supervisor also has to protect against other attacks,

08:59.000 --> 09:01.000
but again, the supervisor is much smaller,

09:01.000 --> 09:05.000
and so hopefully it's much easier to get a correct solution there,

09:05.000 --> 09:08.000
and that because it doesn't have the kernel of the content,

09:08.000 --> 09:09.000
it can be a case.

09:09.000 --> 09:13.000
The case is only has the kernel simply cases.

09:13.000 --> 09:18.000
Yeah, and so this then brings us to what this supervisor actually do.

09:18.000 --> 09:20.000
I told you that it doesn't do a lot,

09:20.000 --> 09:22.000
but I mean, it still has to do some things.

09:22.000 --> 09:24.000
There are basically three stages.

09:24.000 --> 09:28.000
There's a setup stage where the supervisor loads up

09:28.000 --> 09:30.000
and a few inputs, as well as the kernel,

09:30.000 --> 09:33.000
and makes them accessible to the secondary partition,

09:33.000 --> 09:35.000
which is like the workload partition.

09:35.000 --> 09:40.000
Then we enter the stage where we actually execute the workload,

09:40.000 --> 09:44.000
that basically works kind of like a normal hypervisor,

09:44.000 --> 09:48.000
and that you first check if there are any interrupts that need to be injected.

09:48.000 --> 09:51.000
Then you run the workload, eventually the workload exits,

09:51.000 --> 09:54.000
and either through some like natural event,

09:54.000 --> 09:59.000
or in some cases the workload can actually also request some services from the supervisor,

09:59.000 --> 10:01.000
and then those events get handled,

10:01.000 --> 10:03.000
and then we start a loop all over.

10:03.000 --> 10:06.000
Eventually the workload finishes,

10:06.000 --> 10:08.000
it has produced its output file,

10:08.000 --> 10:11.000
and then the last step is that we create the station report

10:11.000 --> 10:14.000
that hopefully makes it,

10:14.000 --> 10:17.000
yeah, hopefully it can convince a very faring party,

10:17.000 --> 10:20.000
that the input file and the workload were able

10:20.000 --> 10:24.000
to create that output.

10:24.000 --> 10:30.000
Yeah, and now we go through some of those steps in a bit more detail.

10:30.000 --> 10:34.000
So the first problem is how can we actually,

10:34.000 --> 10:38.000
how can the supervisor verify that the input file is correct?

10:38.000 --> 10:40.000
There are a couple of requirements here.

10:40.000 --> 10:44.000
The first one is that obviously the input file needs to be part of the

10:44.000 --> 10:48.000
attestation report, otherwise anyone that wants verified

10:48.000 --> 10:51.000
the attestation report can't make sure that it input file hasn't been

10:51.000 --> 10:52.000
tempered with.

10:52.000 --> 10:54.000
But there's also secondary requirement to that,

10:54.000 --> 10:59.000
which is that ideally we don't want the supervisor to be able

10:59.000 --> 11:02.000
to lie about the input file that was provided.

11:02.000 --> 11:05.000
And the reason for that is that somehow if there is a malicious input file,

11:05.000 --> 11:07.000
that exploits the supervisor,

11:07.000 --> 11:11.000
we don't want the supervisor to lie that maybe it was the malicious file,

11:11.000 --> 11:14.000
which is an attestation report for like in benign file,

11:14.000 --> 11:19.000
that user actually wanted to run with.

11:19.000 --> 11:22.000
The other requirement is that we don't want the input file

11:22.000 --> 11:24.000
to be part of the launch management itself.

11:24.000 --> 11:27.000
So if you know those confidential computing technologies,

11:27.000 --> 11:29.000
they have like the launch management itself,

11:29.000 --> 11:32.000
which has like all the initial code and some other segments.

11:32.000 --> 11:35.000
And we don't want the input file to be part of the launch management.

11:35.000 --> 11:39.000
The reason for that is that of course launch management is highly

11:39.000 --> 11:40.000
specific.

11:40.000 --> 11:43.000
And ideally we want to have the deployment,

11:43.000 --> 11:46.000
where we can pre-compete all those values ahead of time,

11:46.000 --> 11:48.000
and then have the input file be separate from that,

11:48.000 --> 11:51.000
so it doesn't have to be involved in all the computations.

11:51.000 --> 11:54.000
And on GDX, we can actually solve this quite neatly,

11:54.000 --> 11:57.000
using this all-configured measurement config,

11:57.000 --> 12:00.000
and the basic idea is that the measurement config,

12:00.000 --> 12:05.000
at GD field, is one field that's supplied at one of the

12:05.000 --> 12:08.000
launch, and it can be changed,

12:08.000 --> 12:11.000
and basically that field just contains a hash of the file.

12:11.000 --> 12:13.000
And when the server has a load up,

12:13.000 --> 12:15.000
it doesn't really look at the input file,

12:15.000 --> 12:17.000
but before it does anything on the grid,

12:17.000 --> 12:20.000
it just competes a hash over that file,

12:20.000 --> 12:24.000
and then makes sure that the measurement config ad fields,

12:24.000 --> 12:25.000
matches the input file,

12:25.000 --> 12:29.000
and hopefully because it doesn't actually look at the input file that much,

12:29.000 --> 12:32.000
and it's unlikely for a malicious input file

12:32.000 --> 12:37.000
to exploit the supervisor or our shown at this stage.

12:37.000 --> 12:42.000
Next up, we'll talk about how the primary petitions

12:42.000 --> 12:45.000
or the supervisor can actually restrict memory accesses

12:45.000 --> 12:48.000
made by the secondary petitions.

12:48.000 --> 12:50.000
There are two ways to sustain.

12:50.000 --> 12:53.000
The first one is fairly simple, which is the TDX,

12:53.000 --> 12:57.000
just exposes a bit, that can be used to prevent

12:57.000 --> 13:01.000
all hypervisor access, hypervisor, let me share accesses

13:01.000 --> 13:03.000
by the secondary petitions.

13:03.000 --> 13:06.000
And by just disabling that,

13:06.000 --> 13:09.000
we can just do that out.

13:09.000 --> 13:13.000
It doesn't matter how badly the workload possibly messes up.

13:13.000 --> 13:17.000
It can be possible for the workload to accidentally access

13:17.000 --> 13:19.000
memory that's shared with the hypervisor,

13:19.000 --> 13:23.000
which once again just eliminates a whole class of bugs.

13:23.000 --> 13:28.000
The other way, the primary petitions can influence the memory

13:28.000 --> 13:31.000
that's accessible by the secondary petitions

13:31.000 --> 13:35.000
is through a so-called TDX call, which is just the TDX thing,

13:35.000 --> 13:37.000
where we can request stuff from the hardware.

13:37.000 --> 13:42.000
And with this particular one, which is like memory page attribute right,

13:42.000 --> 13:47.000
we can set permission bits for secondary petitions.

13:47.000 --> 13:52.000
And so basically at the beginning when the guest launchers,

13:52.000 --> 13:55.000
all memory is only ever accessible to the primary petitions,

13:55.000 --> 13:56.000
so the supervisor.

13:56.000 --> 13:59.000
But if you want to make memory accessible to the secondary petitions,

13:59.000 --> 14:00.000
we can set the value bit.

14:00.000 --> 14:03.000
And as soon as the value bit is actually set,

14:03.000 --> 14:06.000
the workload can then access that memory.

14:06.000 --> 14:08.000
But there's not just a value bit.

14:08.000 --> 14:09.000
There are also few other bits.

14:09.000 --> 14:12.000
So for example, there are like the null rewrite bits,

14:12.000 --> 14:14.000
that you use to.

14:14.000 --> 14:15.000
But there are also expu bits.

14:15.000 --> 14:17.000
There are actually two expu bits.

14:17.000 --> 14:19.000
One is for kernel mode and one is for user mode.

14:20.000 --> 14:23.000
And there are also some other more complicated ones that.

14:23.000 --> 14:24.000
Yeah.

14:24.000 --> 14:28.000
But so the way this is done actually use is that, for example,

14:28.000 --> 14:31.000
for the workload kernel, we just marked that as valid readable

14:31.000 --> 14:34.000
and kernel mode executable.

14:34.000 --> 14:37.000
For the inner binary and also the inner file,

14:37.000 --> 14:39.000
we just marked that as valid and readable.

14:39.000 --> 14:41.000
And we don't ever need to write to it.

14:41.000 --> 14:44.000
And as we don't execute it, because before we execute it,

14:44.000 --> 14:47.000
we actually copy it into some other memory that is hope black in.

14:47.000 --> 14:51.000
That's basically like the generic memory that mushroom uses for most things.

14:51.000 --> 14:55.000
And that memory is then actually used smart as readable,

14:55.000 --> 14:57.000
whiteable and user mode executable.

14:57.000 --> 15:01.000
But once again, like if there are some exploit in there,

15:01.000 --> 15:03.000
the workload kernel can't ever execute that code.

15:03.000 --> 15:05.000
That's in that memory region.

15:05.000 --> 15:09.000
And because it's not marked as a kernel mode executable,

15:09.000 --> 15:11.000
it's only marked as user mode executable.

15:11.000 --> 15:15.000
So I mean, that's just your generic hypervisor,

15:15.000 --> 15:19.000
hypervisor mitigation stuff.

15:19.000 --> 15:24.000
Which brings me to one of my last topics is then how do we execute the workload,

15:24.000 --> 15:26.000
which is of course really bad.

15:26.000 --> 15:28.000
We don't just want to set up all the memory.

15:28.000 --> 15:31.000
And there is another TV guest call VPN.

15:31.000 --> 15:34.000
So I think virtual processor enter is what it's short for.

15:34.000 --> 15:38.000
And there's very pretty much like the instruction that

15:38.000 --> 15:40.000
hypervisor would usually use.

15:40.000 --> 15:44.000
So they're like on the hypervisor, you use the launch of the

15:44.000 --> 15:46.000
and the resume.

15:46.000 --> 15:50.000
Inside, like for with the get partitioning, you just use this one.

15:50.000 --> 15:53.000
And basically when you use this instruction,

15:53.000 --> 15:55.000
the first partition stops running.

15:55.000 --> 15:57.000
And then set the secondary partition stops running.

15:57.000 --> 16:01.000
At some point the secondary partitioning stops running for some reason or another.

16:01.000 --> 16:06.000
And then the primary partition gets some information about why it's stop running.

16:06.000 --> 16:09.000
And then can handle that event and go in.

16:09.000 --> 16:13.000
And so it turns out even though we're like kind of fighting in smaller

16:13.000 --> 16:16.000
live-a-visors, there are actually very few things that can actually happen.

16:16.000 --> 16:19.000
And so there are only three things that can happen in practice.

16:19.000 --> 16:22.000
The first one is the TDX requires the primary partition to handle

16:22.000 --> 16:26.000
CPU ID instructions for secondary petitions.

16:26.000 --> 16:32.000
The other one is that of course we want the workload to request some services for this

16:32.000 --> 16:33.000
one.

16:33.000 --> 16:35.000
That's mostly used for scheduling.

16:35.000 --> 16:38.000
Like for example, if the workload wants to wake up another

16:38.000 --> 16:42.000
CPU, it uses the Supervisor for that, because that's platform specific.

16:42.000 --> 16:44.000
The other thing is memory hub plug.

16:44.000 --> 16:48.000
If the workload wants to request some memory,

16:48.000 --> 16:52.000
it clearly has to talk the hypervisor, but we don't want the workload to try

16:52.000 --> 16:53.000
the hypervisor.

16:53.000 --> 16:56.000
And so that's one of the things that the Supervisor actually takes care of.

16:56.000 --> 16:59.000
And then the last thing of course is that the whole thing,

16:59.000 --> 17:01.000
the goal of this was to produce an output file.

17:01.000 --> 17:05.000
And once again, this is a potential interaction point between the workload and

17:05.000 --> 17:06.000
the hypervisor.

17:06.000 --> 17:08.000
And so all of that also gets taken care of.

17:08.000 --> 17:13.000
By the Supervisor, the Supervisor also transferred transfer server output out.

17:13.000 --> 17:16.000
Lastly, the last thing we do is as I said,

17:16.000 --> 17:22.000
we don't want the hypervisor to inject interrupts into the workload.

17:22.000 --> 17:27.000
And so that's also another thing that we the Supervisor might potentially get

17:27.000 --> 17:31.000
VM exits for, and that it can then emulate.

17:31.000 --> 17:34.000
Yeah, just very briefly for attestation them.

17:34.000 --> 17:39.000
Once again, this is another to the guest call that can be made.

17:39.000 --> 17:44.000
And then basically, we just popular three fields.

17:44.000 --> 17:47.000
Or they get the popular automatically.

17:47.000 --> 17:49.000
The first two ones are the code and input.

17:49.000 --> 17:55.000
So as I talked about, the input gets, let's put into the measurement configuration

17:55.000 --> 17:56.000
at E fields.

17:56.000 --> 18:02.000
As we get launched, the TDX module automatically puts, like launch measurement in

18:02.000 --> 18:03.000
the MLTD field.

18:03.000 --> 18:08.000
And the Supervisor then puts an hash of the output file into the reportile

18:08.000 --> 18:09.000
that field.

18:09.000 --> 18:13.000
And so what's really nice then is that the first two actually completely immutable

18:13.000 --> 18:14.000
after launch.

18:14.000 --> 18:18.000
So it doesn't matter how badly the Supervisor potentially gets compromised.

18:18.000 --> 18:23.000
The only thing that it can ever influence the output file.

18:23.000 --> 18:28.000
And the assumption is that the main threat model is that the input, the code and the

18:28.000 --> 18:29.000
input are malicious.

18:29.000 --> 18:32.000
But of course, if there are malicious, that will show the native facial report.

18:32.000 --> 18:34.000
And so that just can't happen.

18:34.000 --> 18:39.000
Last, the TD reports are actually only verifiable on a local system.

18:39.000 --> 18:43.000
If you want to do remote attestation, you need to turn that into a TD code.

18:43.000 --> 18:47.000
And that's another thing that's actually doesn't have to be done in the VM at all.

18:47.000 --> 18:50.000
That can actually be done by the host.

18:50.000 --> 18:55.000
And so yeah, there's a service that grants on the host that can transform one into

18:55.000 --> 18:56.000
the other.

18:56.000 --> 18:58.000
And that's basically it.

18:58.000 --> 19:01.000
If you're interested in this, there's also another topic that has last year where

19:01.000 --> 19:05.000
I'll talk about a little bit more of the details for AMD as CVS and P.

19:05.000 --> 19:09.000
And if you want, you can check out the course or feel free to ask any questions

19:09.000 --> 19:10.000
if you have any.

19:10.000 --> 19:11.000
Thank you.

19:11.000 --> 19:16.000
I'm not sure about the last one.

19:16.000 --> 19:18.000
Thank you very much.

19:18.000 --> 19:19.000
Thank you.

19:19.000 --> 19:20.000
Thank you.

19:20.000 --> 19:21.000
Thank you.

19:21.000 --> 19:23.000
Okay.

19:23.000 --> 19:24.000
So.

19:24.000 --> 19:25.000
Okay.

19:25.000 --> 19:26.000
So.

19:26.000 --> 19:27.000
So.

19:27.000 --> 19:28.000
So.

19:28.000 --> 19:29.000
Okay.

19:29.000 --> 19:38.000
So the question was, if the host is actually turning the TD report into a TD code,

19:38.000 --> 19:39.000
then it's actually messing with that.

19:39.000 --> 19:43.000
And that like kind of eliminates like if the host can mess with that, that eliminates

19:43.000 --> 19:44.000
integrity guarantees.

19:44.000 --> 19:49.000
And so the answer to that is that it's not actually the host that does the conversion.

19:49.000 --> 19:50.000
It's.

19:50.000 --> 19:52.000
It's like a quoting and you know, it's called.

19:52.000 --> 19:55.000
And that actually converts one issue to the other.

19:55.000 --> 20:00.000
So it's just the host that talks to the quoting and claim and actually does the conversion.

20:00.000 --> 20:03.000
And it's not too much that the host is really doing the conversion.

20:03.000 --> 20:07.000
It's just handling that communication because there's really no reason for like the supervisor or the

20:07.000 --> 20:08.000
counsel to do that.

20:08.000 --> 20:10.000
If you can just ask the host to do that.

20:10.000 --> 20:11.000
So that's not a problem.

20:11.000 --> 20:12.000
Okay.

20:12.000 --> 20:13.000
Please do.

20:13.000 --> 20:14.000
Okay.

20:14.000 --> 20:15.000
Okay.

20:15.000 --> 20:16.000
Come talk to him in the hallway.

20:16.000 --> 20:17.000
If you have more questions.

20:17.000 --> 20:18.000
But now we.

20:18.000 --> 20:21.000
Use the last 10 minutes for writing that for people around.

20:21.000 --> 20:22.000
Thank you.

20:22.000 --> 20:23.000
Thank you.

20:23.000 --> 20:24.000
Thank you.

20:24.000 --> 20:25.000
Thank you.

20:25.000 --> 20:26.000
Thank you.

20:26.000 --> 20:27.000
Thank you.