WEBVTT

00:00.000 --> 00:09.000
Thanks, so can you hear me?

00:09.000 --> 00:10.000
Yes, cool.

00:10.000 --> 00:12.000
So hi, I'm Victor.

00:12.000 --> 00:14.000
I work for the Red Hat.

00:14.000 --> 00:17.000
And yeah, as Kanton said,

00:17.000 --> 00:19.000
I'd like to talk about handling strengths,

00:19.000 --> 00:20.000
and give you programs.

00:20.000 --> 00:26.000
Something that has been kind of clumsy over the years.

00:26.000 --> 00:30.000
So I'll talk about these three kayfunks.

00:30.000 --> 00:32.000
We've introduced it in the past year.

00:32.000 --> 00:35.000
There are a couple of reasons I want to talk about this.

00:35.000 --> 00:37.000
First of all, obviously, so that you know about them,

00:37.000 --> 00:38.000
and you know how to use the, you know,

00:38.000 --> 00:40.000
what benefits they can bring.

00:40.000 --> 00:43.000
But the second is that while implementing these,

00:43.000 --> 00:46.000
it turned out that doing somethings in the EBP of world

00:46.000 --> 00:49.000
may be a bit harder than you would know from traditional

00:49.000 --> 00:51.000
other programming domains.

00:51.000 --> 00:55.000
So that's what I'm going to touch a bit as well.

00:55.000 --> 00:57.000
So let's start with like motivation.

00:57.000 --> 01:00.000
Why would you want handling strengths?

01:00.000 --> 01:04.000
Well, the short answer is because strengths are everywhere.

01:04.000 --> 01:08.000
When it comes to BPF, especially if you be a tracing,

01:08.000 --> 01:11.000
but not not only tracing many hoops that you can attach

01:11.000 --> 01:15.000
your BPF programs to allow you to access strengths,

01:15.000 --> 01:19.000
such as functions, may have arguments, which are strings.

01:19.000 --> 01:22.000
LSM hooks may have arguments, which are strings.

01:22.000 --> 01:25.000
When you're processing packets, or other networking data,

01:25.000 --> 01:28.000
there are like, network protocols, which are strings.

01:28.000 --> 01:31.000
So you want to be able to effectively,

01:31.000 --> 01:35.000
or efficiently pass them and reasoned body strings.

01:35.000 --> 01:37.000
Yeah, so I've got a couple of samples here, like,

01:37.000 --> 01:39.000
for instance, like matching filesystem paths,

01:39.000 --> 01:43.000
like you want to know if a file you're tracing is

01:43.000 --> 01:47.000
inside your home directory, or matching process names,

01:47.000 --> 01:49.000
which is similar thing, right?

01:50.000 --> 01:53.000
For instance, you want to know about all the system D processes,

01:53.000 --> 01:55.000
and the system D is not just a thing of process.

01:55.000 --> 01:57.000
You just create a bunch of processes,

01:57.000 --> 02:01.000
which do have the system D substring somewhere inside,

02:01.000 --> 02:04.000
and you want to capture all of those.

02:04.000 --> 02:06.000
But it doesn't have to be just like the simplest ones.

02:06.000 --> 02:09.000
It can be like environment variants, which can be huge.

02:09.000 --> 02:14.000
And there are several like attack vectors, which target environment variables.

02:14.000 --> 02:17.000
So you want to be efficiently searching those environment variables

02:17.000 --> 02:20.000
for like malicious substrings, et cetera.

02:20.000 --> 02:22.000
Or as I said, like parsing protocols,

02:22.000 --> 02:25.000
can be kind of tricky.

02:25.000 --> 02:31.000
Now, why do we need these, like, new way of handling strings?

02:31.000 --> 02:33.000
Why can't we use what was already there?

02:33.000 --> 02:36.000
There's two things you have to do,

02:36.000 --> 02:40.000
or you had to do in, like, when handling strings like manually inside BPAT.

02:40.000 --> 02:45.000
So first of all, you would need to take the string and copy it

02:45.000 --> 02:48.000
from the curl memory to your BPAT memory,

02:48.000 --> 02:52.000
beat onto the stack or to your BPAT map.

02:52.000 --> 02:57.000
And then you would usually implement a string operation,

02:57.000 --> 02:59.000
like searching a string or something,

02:59.000 --> 03:03.000
a substring, getting string length, whatever you want manually.

03:03.000 --> 03:06.000
So let me show you a quick example here.

03:06.000 --> 03:10.000
Let's have this, let's have this BPAT program,

03:10.000 --> 03:12.000
which attaches to an LSM hook.

03:12.000 --> 03:17.000
This is basically an LSM hook or a function,

03:17.000 --> 03:21.000
if you will, which executes every time a program is executed

03:21.000 --> 03:23.000
on the system.

03:23.000 --> 03:29.000
And let's say you want to check the base name of the program,

03:29.000 --> 03:31.000
this will be executed, right?

03:31.000 --> 03:33.000
So you have an program executed,

03:33.000 --> 03:35.000
it's a, you have a path, the executable,

03:35.000 --> 03:38.000
and you want to do some searching on the base name,

03:38.000 --> 03:40.000
so on the last part of the path.

03:40.000 --> 03:42.000
Traditionally what you need to do,

03:42.000 --> 03:46.000
you basically have to go through the path and find the last slash,

03:46.000 --> 03:50.000
which divides the directory from the base name.

03:50.000 --> 03:54.000
So what you would do here is something like this,

03:54.000 --> 03:58.000
and I want to point out these two things.

03:58.000 --> 04:00.000
So first of all, as I said,

04:00.000 --> 04:03.000
you would need to copy the string into the BPAT memory.

04:03.000 --> 04:05.000
In this case, we're copying it onto the stack,

04:05.000 --> 04:07.000
so you can see this path variable,

04:07.000 --> 04:10.000
so it's a local variable, so it's allocate on the BPF stack.

04:10.000 --> 04:12.000
That's for one,

04:12.000 --> 04:16.000
and then you would need to implement a loop

04:16.000 --> 04:19.000
to go over the string and search for the last slash.

04:19.000 --> 04:22.000
And as probably most of you know,

04:22.000 --> 04:27.000
BPF and loops don't call together that well.

04:27.000 --> 04:29.000
For instance, like for this case,

04:29.000 --> 04:33.000
I was only able to, I had to limit the size of the buffer

04:33.000 --> 04:36.000
for 32 bytes, otherwise verify it with the jank disk program.

04:36.000 --> 04:40.000
Obviously, I could use modern ways of looping in BPF like BPF loop

04:40.000 --> 04:43.000
that would allow me to go to, you know,

04:43.000 --> 04:46.000
for longer paths, but still I'm limited by,

04:46.000 --> 04:49.000
for instance, like for by stack size,

04:49.000 --> 04:51.000
BPF stack is only 500 to a byte,

04:51.000 --> 04:54.000
so it's kind of limited to the size of the path.

04:54.000 --> 04:58.000
Or you would have to store it path into a map,

04:58.000 --> 05:00.000
but that again brings some overhead,

05:00.000 --> 05:01.000
which you have to deal with,

05:01.000 --> 05:03.000
so again, not something you really want

05:03.000 --> 05:06.000
when you want to do some like fast string processing.

05:06.000 --> 05:10.000
So, what is the answer to this problem?

05:10.000 --> 05:13.000
It's a so-called string k-funks,

05:13.000 --> 05:16.000
for those who don't know k-funks,

05:16.000 --> 05:18.000
or called the BPF kernel functions,

05:18.000 --> 05:22.000
are sort of a modern way of exposing kernel functionality

05:22.000 --> 05:24.000
to BPF programs.

05:24.000 --> 05:27.000
They are very much similar to helpers,

05:27.000 --> 05:29.000
although they have some like small differences,

05:29.000 --> 05:31.000
they're not going to dive into.

05:32.000 --> 05:34.000
And the string k-funks provide implementations

05:34.000 --> 05:37.000
of the most common operations over strings,

05:37.000 --> 05:40.000
which your BPF programs can use.

05:40.000 --> 05:42.000
So, what are the advantages?

05:42.000 --> 05:44.000
Well, obviously eliminating the problems

05:44.000 --> 05:47.000
that I was just talking about,

05:47.000 --> 05:50.000
so you don't need to reinvent the functions manually,

05:50.000 --> 05:51.000
which is great.

05:51.000 --> 05:53.000
Like ergonomics is really good.

05:53.000 --> 05:56.000
And you don't need to copy the strings onto the stack,

05:56.000 --> 05:58.000
or to the maps,

05:58.000 --> 06:03.000
eventually lead into even like small performance benefits.

06:03.000 --> 06:08.000
So, let's see how these are implemented,

06:08.000 --> 06:11.000
because this is kind of interesting.

06:11.000 --> 06:15.000
So, the first idea I had when I started working on these is,

06:15.000 --> 06:18.000
well, the kernel already contains implementations

06:18.000 --> 06:20.000
of the string k-funks,

06:20.000 --> 06:23.000
well, kernel doesn't use toned library functions,

06:23.000 --> 06:24.000
it's only implementations,

06:24.000 --> 06:26.000
but they are simple and they are there.

06:26.000 --> 06:29.000
Like you have the, let's take string length.

06:29.000 --> 06:32.000
There is, this is taken directly from the kernel,

06:32.000 --> 06:35.000
so it's a quite short, simple routine.

06:35.000 --> 06:38.000
So, why don't we just call it, right,

06:38.000 --> 06:40.000
from, this is like, let's enter the k-funks,

06:40.000 --> 06:42.000
we just call the string,

06:42.000 --> 06:44.000
or sorry, the function.

06:44.000 --> 06:46.000
What could go wrong?

06:46.000 --> 06:49.000
Turns out, a lot of things can go wrong,

06:49.000 --> 06:52.000
because we are in a BPF world.

06:53.000 --> 06:56.000
And there are a couple of properties that BPF programs

06:56.000 --> 06:57.000
need to have.

06:57.000 --> 06:59.000
They need to ensure, for one,

06:59.000 --> 07:01.000
they need to ensure safety,

07:01.000 --> 07:06.000
which means that the very file is not able to check.

07:06.000 --> 07:08.000
So, they're very far has some limited support

07:08.000 --> 07:10.000
for like k-funks arguments,

07:10.000 --> 07:13.000
but it can only, since it sees this as a standard pointer,

07:13.000 --> 07:15.000
it can only check the first byte,

07:15.000 --> 07:18.000
it's pointing to is actually a valid memory.

07:18.000 --> 07:20.000
But you have a loop inside,

07:21.000 --> 07:23.000
you want to loop over the entire string,

07:23.000 --> 07:25.000
until you find the null terminator,

07:25.000 --> 07:27.000
and you want to reference,

07:27.000 --> 07:29.000
you want to, you know, see the memory,

07:29.000 --> 07:31.000
but what if the memory is not there,

07:31.000 --> 07:32.000
it doesn't have to be patched in,

07:32.000 --> 07:34.000
which means you would panic at the kernel,

07:34.000 --> 07:36.000
something you don't want, obviously.

07:36.000 --> 07:38.000
So, we need to ensure safety

07:38.000 --> 07:42.000
and playing the reference is not the way to go.

07:42.000 --> 07:45.000
Second, BPF programs must terminate,

07:45.000 --> 07:47.000
you can't hang the kernel.

07:47.000 --> 07:51.000
However, the incremental, well, all the common implementations

07:51.000 --> 07:53.000
of foreigners is like stringling,

07:53.000 --> 07:56.000
count with the fact that strings are null terminated,

07:56.000 --> 07:58.000
you have the null terminator byte,

07:58.000 --> 08:00.000
but what if you don't,

08:00.000 --> 08:02.000
what if the string doesn't end,

08:02.000 --> 08:05.000
then, well, that loop would look forever,

08:05.000 --> 08:08.000
not something you want from your BPF program, right?

08:08.000 --> 08:12.000
So, we had to cover with that different solution,

08:12.000 --> 08:16.000
and unfortunately, it turned out that the only good enough solution

08:16.000 --> 08:19.000
was to re-implement everything from scratch,

08:19.000 --> 08:21.000
hopefully, well, luckily,

08:21.000 --> 08:25.000
the string functions are sort of simple,

08:25.000 --> 08:28.000
and this is what it looks like right now.

08:28.000 --> 08:30.000
So, it's a bit more complicated

08:30.000 --> 08:32.000
that what we have seen on the previous slide,

08:32.000 --> 08:33.000
but it's not that bad.

08:33.000 --> 08:35.000
I'm going to show you,

08:35.000 --> 08:38.000
let's see the features of these implementations.

08:38.000 --> 08:40.000
The first of all, we disable page folds

08:40.000 --> 08:42.000
because we don't want page folds occurring,

08:42.000 --> 08:44.000
execution of BPF programs.

08:44.000 --> 08:48.000
This is something that is going to be called from inside the BPF program,

08:48.000 --> 08:50.000
in the BPF context.

08:50.000 --> 08:52.000
So, first of all, we disable page folds.

08:52.000 --> 08:55.000
This card thing is kind of a nice,

08:55.000 --> 09:00.000
it relies on a nice feature of compilers,

09:00.000 --> 09:03.000
which will, here, insert, like,

09:03.000 --> 09:05.000
disableing of a page fold,

09:05.000 --> 09:07.000
and then they will enable page folds

09:07.000 --> 09:10.000
whenever this function ends, just kind of a nice thing.

09:11.000 --> 09:14.000
And then, instead of plain interference,

09:14.000 --> 09:17.000
we would use this special kernel micro,

09:17.000 --> 09:20.000
which is quite low overhead wrapper

09:20.000 --> 09:22.000
over standard interference,

09:22.000 --> 09:25.000
which just doesn't fall,

09:25.000 --> 09:27.000
doesn't go into a page fold.

09:27.000 --> 09:30.000
If the memory is not there,

09:30.000 --> 09:31.000
what it does instead,

09:31.000 --> 09:33.000
it jumps to this error out label.

09:33.000 --> 09:36.000
And then, we would just return, you know,

09:36.000 --> 09:38.000
error code for the function,

09:38.000 --> 09:41.000
saying that, sorry, we couldn't read the memory, you provided,

09:41.000 --> 09:44.000
but we are crushing, and I think we're just, you know,

09:44.000 --> 09:46.000
reporting to the user that the,

09:46.000 --> 09:48.000
we couldn't process the string,

09:48.000 --> 09:50.000
what that was passed,

09:50.000 --> 09:52.000
and let the user deal with it,

09:52.000 --> 09:54.000
get any way they want.

09:54.000 --> 09:56.000
And the third thing is,

09:56.000 --> 09:58.000
we need to make sure,

09:58.000 --> 10:01.000
if the string is not now terminated,

10:01.000 --> 10:04.000
that the function eventually ends,

10:04.000 --> 10:06.000
which means that we chose

10:06.000 --> 10:08.000
and basically arbitrary,

10:08.000 --> 10:10.000
a polimit on the size.

10:10.000 --> 10:12.000
In this case, it's,

10:12.000 --> 10:13.000
except x, x,

10:13.000 --> 10:14.000
editor,

10:14.000 --> 10:15.000
size max,

10:15.000 --> 10:17.000
which is something like 65 kilobytes,

10:17.000 --> 10:20.000
which is kind of a big enough limit,

10:20.000 --> 10:22.000
you know, to handle most of the

10:22.000 --> 10:24.000
common strings you will you will encounter.

10:24.000 --> 10:25.000
However,

10:25.000 --> 10:29.000
it makes sure that we will always terminate,

10:29.000 --> 10:31.000
which is something BBA programs must do.

10:31.000 --> 10:32.000
Any case we don't,

10:32.000 --> 10:35.000
we would again return an error code

10:35.000 --> 10:37.000
to the user so that he can,

10:37.000 --> 10:39.000
you know, he is not defined and the function,

10:39.000 --> 10:41.000
did something and expected.

10:43.000 --> 10:46.000
Okay, so when it comes to the verified support,

10:46.000 --> 10:48.000
as I said,

10:48.000 --> 10:50.000
so as I said,

10:50.000 --> 10:52.000
verified does have some sort of limited support

10:52.000 --> 10:55.000
for handling or checking some properties

10:55.000 --> 10:58.000
of the K-Funk arguments.

10:58.000 --> 10:59.000
So in this case,

10:59.000 --> 11:01.000
we're dealing with two kinds of arguments.

11:01.000 --> 11:02.000
First of all,

11:02.000 --> 11:03.000
obviously we are passing the string.

11:03.000 --> 11:06.000
So we are passing typically not,

11:06.000 --> 11:07.000
not terminated,

11:07.000 --> 11:09.000
but not necessarily natural,

11:09.000 --> 11:10.000
not terminated strings,

11:10.000 --> 11:12.000
which can be located in,

11:12.000 --> 11:14.000
in BBA or in the curl memory,

11:14.000 --> 11:16.000
which we have to,

11:16.000 --> 11:17.000
from the verified perspective,

11:17.000 --> 11:19.000
we just have to treat them as any,

11:19.000 --> 11:20.000
like,

11:20.000 --> 11:21.000
generate unsafe pointers.

11:21.000 --> 11:23.000
We can't say much about them.

11:23.000 --> 11:25.000
Since they can be in the curl memory.

11:25.000 --> 11:28.000
And then,

11:28.000 --> 11:30.000
we have variants of the string.

11:30.000 --> 11:32.000
Some string functions have,

11:32.000 --> 11:33.000
like,

11:33.000 --> 11:34.000
pounded variants,

11:34.000 --> 11:36.000
so you can actually say that you want to,

11:36.000 --> 11:37.000
run this,

11:37.000 --> 11:38.000
you know,

11:38.000 --> 11:40.000
search for a substring,

11:40.000 --> 11:41.000
but you want to,

11:41.000 --> 11:43.000
to pound it by some integer,

11:43.000 --> 11:44.000
so we can have some integers,

11:44.000 --> 11:46.000
which can be to channel integers here.

11:46.000 --> 11:49.000
So when it comes to verify support for these,

11:49.000 --> 11:50.000
like,

11:50.000 --> 11:51.000
K-Funk arguments,

11:51.000 --> 11:54.000
there's a couple of special suffices

11:54.000 --> 11:58.000
that you can pass to the or you can give to the functions,

11:58.000 --> 11:59.000
sorry,

11:59.000 --> 12:00.000
to arguments.

12:00.000 --> 12:01.000
So what's the following,

12:01.000 --> 12:03.000
underscore underscore STR,

12:03.000 --> 12:06.000
which stands for string literals,

12:06.000 --> 12:07.000
which is not useful here,

12:07.000 --> 12:09.000
because we don't want only literals.

12:09.000 --> 12:10.000
We want to,

12:10.000 --> 12:13.000
you know, pass the pointers to the strings,

12:13.000 --> 12:15.000
located in the curl memory,

12:15.000 --> 12:16.000
instead of just,

12:16.000 --> 12:17.000
you know,

12:17.000 --> 12:18.000
always like,

12:18.000 --> 12:19.000
dealing with literals.

12:19.000 --> 12:20.000
Then,

12:20.000 --> 12:21.000
similarly,

12:21.000 --> 12:22.000
we have underscore,

12:22.000 --> 12:23.000
asy,

12:23.000 --> 12:24.000
which,

12:24.000 --> 12:26.000
represent like a size of a buffer,

12:26.000 --> 12:27.000
but again,

12:27.000 --> 12:28.000
it has to be a literal,

12:28.000 --> 12:29.000
not something we want here,

12:29.000 --> 12:31.000
we just want channel integers for the,

12:31.000 --> 12:32.000
for the second time of the argument.

12:32.000 --> 12:33.000
So again,

12:33.000 --> 12:35.000
not something useful for us.

12:35.000 --> 12:39.000
So what we ended up doing is we basically ended up,

12:39.000 --> 12:42.000
using the third thing,

12:42.000 --> 12:44.000
which is telling the very fire,

12:44.000 --> 12:49.000
just ignore any sort of verification for this argument.

12:49.000 --> 12:51.000
Which is something we can afford,

12:51.000 --> 12:52.000
because,

12:52.000 --> 12:53.000
thanks to that,

12:53.000 --> 12:54.000
you know,

12:54.000 --> 12:55.000
page disabled,

12:55.000 --> 12:56.000
and get curl,

12:56.000 --> 12:57.000
well,

12:57.000 --> 12:58.000
no fault.

12:59.000 --> 13:00.000
We,

13:00.000 --> 13:02.000
we essentially have time of

13:02.000 --> 13:03.000
safety,

13:03.000 --> 13:05.000
so we don't need the very fire to,

13:05.000 --> 13:06.000
give another layer of,

13:06.000 --> 13:07.000
you know,

13:07.000 --> 13:08.000
static safety,

13:08.000 --> 13:11.000
because we are certain that the functions are safe,

13:11.000 --> 13:12.000
by definition,

13:12.000 --> 13:14.000
so we don't need to very fire,

13:14.000 --> 13:16.000
spend any time on dealing,

13:16.000 --> 13:18.000
or proving that those,

13:18.000 --> 13:20.000
those arguments are safe to access,

13:20.000 --> 13:21.000
and as we,

13:21.000 --> 13:23.000
as I said before,

13:23.000 --> 13:24.000
it wouldn't even be able to,

13:24.000 --> 13:26.000
at least not with the current,

13:26.000 --> 13:27.000
you know,

13:28.000 --> 13:29.000
okay,

13:29.000 --> 13:30.000
so let's see,

13:30.000 --> 13:31.000
let's see what we have there,

13:31.000 --> 13:32.000
what,

13:32.000 --> 13:33.000
what you can work with at the moment,

13:33.000 --> 13:35.000
so the initial patch set,

13:35.000 --> 13:36.000
added like,

13:36.000 --> 13:38.000
10-ish functions for like,

13:38.000 --> 13:41.000
the most common read-only operations for now,

13:41.000 --> 13:42.000
only.

13:42.000 --> 13:44.000
So comparing strings,

13:44.000 --> 13:45.000
getting blank,

13:45.000 --> 13:47.000
searching substrings,

13:47.000 --> 13:50.000
searching characters inside the,

13:50.000 --> 13:51.000
the strings,

13:51.000 --> 13:53.000
and what is this,

13:53.000 --> 13:54.000
all these are like,

13:54.000 --> 13:56.000
searching groups of characters inside the string,

13:57.000 --> 13:59.000
and then,

13:59.000 --> 14:02.000
a couple of folks added a few more functions,

14:02.000 --> 14:04.000
mainly dealing with string,

14:04.000 --> 14:05.000
comparison,

14:05.000 --> 14:06.000
or,

14:06.000 --> 14:07.000
yeah,

14:07.000 --> 14:09.000
comparison and finding substrings,

14:09.000 --> 14:10.000
without,

14:10.000 --> 14:11.000
well,

14:11.000 --> 14:13.000
in a case and in sensitive way,

14:13.000 --> 14:15.000
because apparently these are useful

14:15.000 --> 14:17.000
when dealing with some network protocols,

14:17.000 --> 14:19.000
so they are kind of used.

14:19.000 --> 14:20.000
So yeah,

14:20.000 --> 14:21.000
it's the,

14:21.000 --> 14:22.000
the API,

14:22.000 --> 14:23.000
or the,

14:23.000 --> 14:24.000
the library,

14:24.000 --> 14:25.000
the function is kind of growing,

14:25.000 --> 14:27.000
feel free to contribute,

14:27.000 --> 14:29.000
if any other string functions,

14:29.000 --> 14:30.000
it's,

14:30.000 --> 14:31.000
it's not hard,

14:31.000 --> 14:33.000
actually just read whatever is there,

14:33.000 --> 14:35.000
and get inspired by the implementation,

14:35.000 --> 14:36.000
it's in,

14:36.000 --> 14:38.000
kernel slash BPS,

14:38.000 --> 14:39.000
helpers,

14:39.000 --> 14:40.000
or something.

14:40.000 --> 14:41.000
I mean,

14:41.000 --> 14:43.000
feel free to contribute.

14:43.000 --> 14:44.000
Okay,

14:44.000 --> 14:45.000
maybe one,

14:45.000 --> 14:46.000
a couple more like,

14:46.000 --> 14:48.000
specific about the,

14:48.000 --> 14:50.000
the strings,

14:50.000 --> 14:51.000
sort of sort of string functions,

14:51.000 --> 14:53.000
where it comes to comparison,

14:53.000 --> 14:54.000
which standard library functions.

14:54.000 --> 14:57.000
So you all know string length from,

14:57.000 --> 14:58.000
uh,

14:58.000 --> 14:59.000
C standard library,

14:59.000 --> 15:00.000
or,

15:00.000 --> 15:01.000
uh, other,

15:01.000 --> 15:02.000
you know string functions,

15:02.000 --> 15:04.000
but there are some specific that we have here.

15:04.000 --> 15:05.000
So first of all,

15:05.000 --> 15:06.000
one specific is that,

15:06.000 --> 15:07.000
uh,

15:07.000 --> 15:08.000
the,

15:08.000 --> 15:09.000
the string,

15:09.000 --> 15:10.000
a function,

15:10.000 --> 15:11.000
always return integers,

15:11.000 --> 15:13.000
which means that whenever,

15:13.000 --> 15:16.000
a standard library function would return the pointer,

15:16.000 --> 15:17.000
like,

15:17.000 --> 15:18.000
this function,

15:18.000 --> 15:19.000
STR,

15:19.000 --> 15:21.000
C-H-R,

15:21.000 --> 15:22.000
uh,

15:22.000 --> 15:23.000
gets a point,

15:23.000 --> 15:23.500
gets a string,

15:23.500 --> 15:24.500
and a character,

15:24.500 --> 15:26.500
and it returns a pointer

15:26.500 --> 15:30.500
to the first occurrence of that character inside the string.

15:30.500 --> 15:32.500
The BPSK function,

15:32.500 --> 15:35.500
instead returns an index.

15:35.500 --> 15:36.500
Uh,

15:36.500 --> 15:37.500
why is that?

15:37.500 --> 15:38.500
Well,

15:38.500 --> 15:39.500
the first reason is that,

15:39.500 --> 15:43.500
since we have to treat the input pointer as unsafe,

15:43.500 --> 15:45.500
we also have to treat,

15:45.500 --> 15:49.500
we would also have to treat the output pointer as unsafe,

15:49.500 --> 15:52.500
meaning that the rest of the BPS program,

15:52.500 --> 15:56.500
shouldn't the reference that pointer directly.

15:56.500 --> 15:57.500
Anyway,

15:57.500 --> 15:58.500
it would have to, again,

15:58.500 --> 16:01.500
do something like BPS property to whatever.

16:01.500 --> 16:03.500
So it turned out that,

16:03.500 --> 16:05.500
actually issuing our returning,

16:05.500 --> 16:06.500
uh,

16:06.500 --> 16:07.500
indices is,

16:07.500 --> 16:08.500
uh,

16:08.500 --> 16:09.500
is kind of simpler.

16:09.500 --> 16:10.500
Here,

16:10.500 --> 16:11.500
um,

16:11.500 --> 16:14.500
and what it gives us as an advantage,

16:14.500 --> 16:16.500
we can return negative articles,

16:16.500 --> 16:18.500
which is a difference from the traditional,

16:18.500 --> 16:19.500
uh,

16:19.500 --> 16:20.500
traditional,

16:20.500 --> 16:21.500
standard library functions.

16:21.500 --> 16:22.500
We can actually,

16:22.500 --> 16:23.500
in the fall of the user,

16:23.500 --> 16:24.500
the something went wrong,

16:24.500 --> 16:25.500
something,

16:25.500 --> 16:26.500
you know,

16:26.500 --> 16:27.500
I've already talked about,

16:27.500 --> 16:28.500
like returning e-fold when,

16:28.500 --> 16:29.500
uh,

16:29.500 --> 16:30.500
the memory is not there,

16:30.500 --> 16:32.500
or returning e-to-beek when the string is too big.

16:32.500 --> 16:33.500
We have a couple more,

16:33.500 --> 16:34.500
like,

16:34.500 --> 16:36.500
e-rent when the strings are outside of the kernel,

16:36.500 --> 16:37.500
address space,

16:37.500 --> 16:38.500
or,

16:38.500 --> 16:39.500
uh,

16:39.500 --> 16:40.500
particularly for these,

16:40.500 --> 16:41.500
like,

16:41.500 --> 16:42.500
string,

16:42.500 --> 16:45.500
also,

16:45.500 --> 16:46.500
sorry,

16:46.500 --> 16:47.500
character,

16:47.500 --> 16:48.500
such functions,

16:48.500 --> 16:49.500
instead of returning something like,

16:50.500 --> 16:51.500
uh,

16:51.500 --> 16:52.500
expressive enough,

16:52.500 --> 16:53.500
uh,

16:53.500 --> 16:54.500
for the user that the entry,

16:54.500 --> 16:56.500
he was trying to search doesn't exist.

16:56.500 --> 16:57.500
Okay.

16:57.500 --> 16:58.500
Uh,

16:58.500 --> 16:59.500
I'd like to,

16:59.500 --> 17:00.500
give,

17:00.500 --> 17:01.500
uh,

17:01.500 --> 17:02.500
uh,

17:02.500 --> 17:03.500
example of,

17:03.500 --> 17:04.500
of how we could use these.

17:04.500 --> 17:05.500
So,

17:05.500 --> 17:06.500
let's get back to the,

17:06.500 --> 17:08.500
to the example I had in the beginning,

17:08.500 --> 17:09.500
uh,

17:09.500 --> 17:10.500
again,

17:10.500 --> 17:11.500
this is the same function.

17:11.500 --> 17:12.500
On the left,

17:12.500 --> 17:14.500
this is practically what we have already seen.

17:14.500 --> 17:15.500
So,

17:15.500 --> 17:16.500
what you have to do traditionally,

17:16.500 --> 17:17.500
you,

17:17.500 --> 17:18.500
uh,

17:18.500 --> 17:19.500
then you would,

17:19.500 --> 17:20.500
well,

17:20.500 --> 17:21.500
this is just,

17:21.500 --> 17:22.500
the chat,

17:22.500 --> 17:23.500
some check for the very fire,

17:23.500 --> 17:25.500
and then you would implement a loop,

17:25.500 --> 17:29.500
where you would search for the last occurrence of a slash,

17:29.500 --> 17:31.500
and then basically your base name is at,

17:31.500 --> 17:32.500
well,

17:32.500 --> 17:33.500
plus,

17:33.500 --> 17:35.500
the location of the slash,

17:35.500 --> 17:36.500
plus one,

17:36.500 --> 17:37.500
because that's where that,

17:37.500 --> 17:38.500
uh,

17:38.500 --> 17:39.500
where it starts,

17:39.500 --> 17:41.500
implementing exactly the same,

17:41.500 --> 17:43.500
using string headphones,

17:43.500 --> 17:44.500
uh,

17:44.500 --> 17:45.500
is on the right side,

17:45.500 --> 17:46.500
and you can see that it's,

17:46.500 --> 17:47.500
considerably shorter,

17:47.500 --> 17:48.500
uh,

17:48.500 --> 17:49.500
you just call and,

17:49.500 --> 17:50.500
in this case,

17:50.500 --> 17:51.500
STR,

17:51.500 --> 17:52.500
our CHR,

17:52.500 --> 17:54.500
which searches the string from the right,

17:54.500 --> 17:55.500
uh,

17:55.500 --> 17:58.500
and searches for the last occurrence of a character,

17:58.500 --> 17:59.500
in this case,

17:59.500 --> 18:00.500
slash,

18:00.500 --> 18:01.500
and then you would get the,

18:01.500 --> 18:02.500
you know,

18:02.500 --> 18:03.500
index,

18:03.500 --> 18:05.500
and the only thing you have to do,

18:05.500 --> 18:07.500
then is to check that,

18:07.500 --> 18:08.500
uh,

18:08.500 --> 18:09.500
well,

18:09.500 --> 18:10.500
check for the error code,

18:10.500 --> 18:11.500
and,

18:11.500 --> 18:13.500
and then you can do whatever you want with that.

18:13.500 --> 18:14.500
If you want to,

18:14.500 --> 18:15.500
like,

18:15.500 --> 18:16.500
if you want to read that string,

18:16.500 --> 18:17.500
like the base name,

18:17.500 --> 18:18.500
you still have to do,

18:18.500 --> 18:20.500
BFF pro breed.

18:20.500 --> 18:22.500
The difference is that,

18:22.500 --> 18:23.500
in this case,

18:23.500 --> 18:25.500
you have to read the entire string,

18:25.500 --> 18:27.500
so you have to read the entire path,

18:27.500 --> 18:29.500
which can be long.

18:29.500 --> 18:30.500
In the,

18:30.500 --> 18:31.500
in our case,

18:31.500 --> 18:32.500
since we have,

18:32.500 --> 18:33.500
like,

18:33.500 --> 18:34.500
dynamic safety of,

18:34.500 --> 18:35.500
of the string k-fun,

18:35.500 --> 18:36.500
you just have to,

18:36.500 --> 18:38.500
read the base name,

18:38.500 --> 18:40.500
which is generally short,

18:40.500 --> 18:43.500
and it usually will fit your BFF stack,

18:43.500 --> 18:45.500
which is good enough.

18:45.500 --> 18:47.500
Um,

18:47.500 --> 18:48.500
cool.

18:48.500 --> 18:50.500
Another use case we have,

18:50.500 --> 18:52.500
and this is actually the first,

18:52.500 --> 18:53.500
like,

18:53.500 --> 18:55.500
reason why I came to implement these functions,

18:55.500 --> 18:58.500
is that I'm maintaining this tool called BFF trace.

18:58.500 --> 19:00.500
I hope you've heard.

19:00.500 --> 19:01.500
And,

19:01.500 --> 19:02.500
so historically,

19:02.500 --> 19:03.500
it BFF trace,

19:03.500 --> 19:06.500
when you would add new functionality,

19:06.500 --> 19:07.500
you would,

19:07.500 --> 19:10.500
you have to implement BFF code using,

19:10.500 --> 19:12.500
BFF code using BFF code,

19:12.500 --> 19:13.500
so you had,

19:13.500 --> 19:15.500
basically have to write,

19:15.500 --> 19:16.500
the functionality,

19:16.500 --> 19:18.500
manually in LFF instructions,

19:18.500 --> 19:19.500
which is,

19:19.500 --> 19:20.500
trust me,

19:20.500 --> 19:22.500
not something you want to do.

19:22.500 --> 19:23.500
Uh,

19:23.500 --> 19:24.500
so thanks to this,

19:24.500 --> 19:25.500
k-fun,

19:25.500 --> 19:27.500
it's much more economic to do this now,

19:27.500 --> 19:28.500
so you just basically,

19:28.500 --> 19:29.500
you don't call this,

19:29.500 --> 19:30.500
built in,

19:30.500 --> 19:31.500
uh,

19:31.500 --> 19:32.500
string k-fun,

19:32.500 --> 19:33.500
and thanks to that,

19:33.500 --> 19:34.500
we finally have,

19:34.500 --> 19:35.500
like,

19:35.500 --> 19:36.500
nice set of functions for,

19:36.500 --> 19:37.500
like,

19:37.500 --> 19:38.500
manipulating strings,

19:38.500 --> 19:39.500
like most importantly,

19:39.500 --> 19:40.500
strings,

19:40.500 --> 19:41.500
which is kind of,

19:41.500 --> 19:43.500
thing that people want to do with BFF trace,

19:43.500 --> 19:44.500
uh,

19:44.500 --> 19:45.500
but then,

19:45.500 --> 19:46.500
war functions are coming,

19:46.500 --> 19:47.500
like,

19:47.500 --> 19:48.500
getting the length of the string,

19:48.500 --> 19:49.500
etc.,

19:49.500 --> 19:51.500
which allows you to,

19:51.500 --> 19:52.500
kind of, like, do,

19:52.500 --> 19:55.500
kind of complex filtering inside your BFF trace scripts,

19:55.500 --> 19:57.500
so inside the kernel,

19:57.500 --> 19:58.500
uh,

19:58.500 --> 19:59.500
which is very efficient,

19:59.500 --> 20:00.500
and, uh,

20:00.500 --> 20:01.500
and you don't need to,

20:01.500 --> 20:02.500
uh,

20:02.500 --> 20:03.500
you know,

20:03.500 --> 20:05.500
write C code in this case,

20:05.500 --> 20:07.500
because BFF trace is much more like easy,

20:08.500 --> 20:09.500
to, to the BFF world.

20:09.500 --> 20:11.500
Um,

20:11.500 --> 20:12.500
okay,

20:12.500 --> 20:15.500
so the last thing I want to talk about is some,

20:15.500 --> 20:16.500
like,

20:16.500 --> 20:18.500
ideas for future directions,

20:18.500 --> 20:19.500
uh,

20:19.500 --> 20:20.500
up for discussion,

20:20.500 --> 20:21.500
or if you have any other ideas,

20:21.500 --> 20:22.500
let me know.

20:22.500 --> 20:23.500
So first of all,

20:23.500 --> 20:25.500
we can obviously add more,

20:25.500 --> 20:27.500
read only functions for now,

20:27.500 --> 20:28.500
if you have an,

20:28.500 --> 20:29.500
as some ideas contribute,

20:29.500 --> 20:30.500
please,

20:30.500 --> 20:31.500
uh,

20:31.500 --> 20:32.500
it's already happening,

20:32.500 --> 20:33.500
if we have seen like,

20:33.500 --> 20:34.500
functions are coming,

20:34.500 --> 20:36.500
uh,

20:36.500 --> 20:38.500
the second big part of the functions we have,

20:38.500 --> 20:40.500
omitted for now,

20:40.500 --> 20:42.500
are those that actually do manipulate the memory,

20:42.500 --> 20:43.500
like,

20:43.500 --> 20:45.500
do copy or move the memory around,

20:45.500 --> 20:46.500
like,

20:46.500 --> 20:47.500
string copy string,

20:47.500 --> 20:48.500
move it to trap.

20:48.500 --> 20:49.500
Uh,

20:49.500 --> 20:51.500
the reason we haven't implemented these at the beginning,

20:51.500 --> 20:52.500
is that there are some,

20:52.500 --> 20:53.500
well,

20:53.500 --> 20:54.500
tricks you have to,

20:54.500 --> 20:55.500
or there are some problems,

20:55.500 --> 20:56.500
which will come,

20:56.500 --> 20:57.500
uh,

20:57.500 --> 20:58.500
for instance,

20:58.500 --> 20:59.500
like,

20:59.500 --> 21:02.500
when the source and the destination buffers overlap,

21:02.500 --> 21:03.500
in,

21:03.500 --> 21:05.500
uh,

21:05.500 --> 21:07.500
in standard library functions,

21:07.500 --> 21:08.500
you just can't,

21:08.500 --> 21:09.500
you know,

21:09.500 --> 21:10.500
undefined behavior,

21:10.500 --> 21:13.500
but you can't afford to have undefined behavior,

21:13.500 --> 21:14.500
in BPA programs.

21:14.500 --> 21:15.500
So this would have to be,

21:15.500 --> 21:16.500
results on how,

21:16.500 --> 21:17.500
like,

21:17.500 --> 21:18.500
for instance,

21:18.500 --> 21:19.500
like,

21:19.500 --> 21:20.500
verify,

21:20.500 --> 21:22.500
would have to check that those two buffers don't overlap.

21:22.500 --> 21:24.500
So we have to have to teach the very fire to do that.

21:24.500 --> 21:25.500
Uh,

21:25.500 --> 21:26.500
it shouldn't be that hard.

21:26.500 --> 21:27.500
It should be like,

21:27.500 --> 21:29.500
it's a problem that can be solved.

21:29.500 --> 21:30.500
Only until now,

21:30.500 --> 21:32.500
we haven't seen a use case for such functions.

21:32.500 --> 21:34.500
So if anyone does have a use case for,

21:34.500 --> 21:35.500
you know,

21:35.500 --> 21:37.500
string copying functions,

21:37.500 --> 21:39.500
or if someone wants to do like,

21:39.500 --> 21:41.500
string copying inside your BPA programs,

21:41.500 --> 21:42.500
just let me know.

21:42.500 --> 21:43.500
Uh,

21:43.500 --> 21:46.500
and when it comes to like BPA trace,

21:46.500 --> 21:47.500
uh,

21:47.500 --> 21:48.500
which is something I work on,

21:48.500 --> 21:50.500
that's why I'm mentioning it here.

21:50.500 --> 21:51.500
Uh,

21:51.500 --> 21:52.500
So first of all,

21:52.500 --> 21:54.500
what we need to do is evaluate this,

21:54.500 --> 21:55.500
appropriating.

21:55.500 --> 21:57.500
So I was saying that BPA,

21:57.500 --> 21:58.500
thanks to this case,

21:58.500 --> 22:01.500
because you don't need to read the entire memory in advance,

22:01.500 --> 22:02.500
unfortunately,

22:02.500 --> 22:03.500
BPA trace still does it.

22:03.500 --> 22:05.500
We'll have to work on this,

22:05.500 --> 22:06.500
uh,

22:06.500 --> 22:08.500
to make it more efficient when it comes to string handling.

22:08.500 --> 22:09.500
And,

22:09.500 --> 22:10.500
uh,

22:10.500 --> 22:11.500
yeah,

22:11.500 --> 22:13.500
adding forever for more functions would be useful.

22:13.500 --> 22:16.500
So the BPA trace gets even more like,

22:16.500 --> 22:18.500
capabilities when it comes to,

22:18.500 --> 22:19.500
just string handling.

22:19.500 --> 22:21.500
Um,

22:21.500 --> 22:23.500
and that's it.

22:23.500 --> 22:24.500
Uh,

22:24.500 --> 22:25.500
thank you for your attention,

22:25.500 --> 22:26.500
and I'm happy to take questions.

22:27.500 --> 22:29.500
Thank you for the talk.

22:29.500 --> 22:30.500
Uh,

22:30.500 --> 22:31.500
I have two questions.

22:31.500 --> 22:32.500
First one is an obvious one,

22:32.500 --> 22:35.500
because there is an influx now of new read-only,

22:35.500 --> 22:37.500
uh, functions to work with strings.

22:37.500 --> 22:40.500
There will be differences between the lens kernel,

22:40.500 --> 22:43.500
when different functions are available probably,

22:43.500 --> 22:46.500
just any tips on how should we handle that in our programs.

22:46.500 --> 22:48.500
So the question is,

22:48.500 --> 22:49.500
if I was incorrectly,

22:49.500 --> 22:50.500
um,

22:50.500 --> 22:52.500
that in all the words,

22:53.500 --> 22:54.500
if I was incorrectly,

22:54.500 --> 22:55.500
um,

22:55.500 --> 22:57.500
that in all the version of the kernel,

22:57.500 --> 22:59.500
you will not have these functions available, right?

22:59.500 --> 23:00.500
Well,

23:00.500 --> 23:01.500
um,

23:01.500 --> 23:02.500
yeah, it's a good question.

23:02.500 --> 23:03.500
Um,

23:03.500 --> 23:04.500
and I don't have a,

23:04.500 --> 23:05.500
get better answer than,

23:05.500 --> 23:06.500
you know,

23:06.500 --> 23:08.500
update to the latest kernel.

23:08.500 --> 23:10.500
What BPA trace does actually,

23:10.500 --> 23:11.500
is that it,

23:11.500 --> 23:13.500
for most of the,

23:13.500 --> 23:15.500
for most of the functions,

23:15.500 --> 23:16.500
it implements like fullbacks,

23:16.500 --> 23:17.500
which are,

23:17.500 --> 23:18.500
uh,

23:18.500 --> 23:19.500
handy,

23:19.500 --> 23:20.500
and see,

23:21.500 --> 23:23.500
so we do have like these fullback functions,

23:23.500 --> 23:24.500
but obviously those have to,

23:24.500 --> 23:25.500
you know,

23:25.500 --> 23:26.500
copy things on the,

23:26.500 --> 23:27.500
on the,

23:27.500 --> 23:28.500
and let's copy and the,

23:28.500 --> 23:29.500
or to the map.

23:29.500 --> 23:30.500
So yeah,

23:30.500 --> 23:31.500
there are less efficient,

23:31.500 --> 23:32.500
but that's the basic interview.

23:32.500 --> 23:33.500
And one more,

23:33.500 --> 23:35.500
what about text encoding?

23:35.500 --> 23:36.500
Sorry,

23:36.500 --> 23:37.500
what about text encoding,

23:37.500 --> 23:38.500
when you want to,

23:38.500 --> 23:39.500
for example,

23:39.500 --> 23:40.500
compare,

23:40.500 --> 23:42.500
multiplied characters.

23:42.500 --> 23:43.500
Um,

23:43.500 --> 23:44.500
good question.

23:44.500 --> 23:46.500
I think,

23:46.500 --> 23:47.500
well,

23:47.500 --> 23:49.500
this is obviously not implementing right now.

23:49.500 --> 23:51.500
I can't imagine,

23:51.500 --> 23:53.500
and you're string-cafying in the call,

23:53.500 --> 23:54.500
which deals with this.

23:54.500 --> 23:55.500
But again,

23:55.500 --> 23:57.500
I guess that's the only,

23:57.500 --> 23:59.500
that's the only way we can,

23:59.500 --> 24:01.500
we can do here.

24:01.500 --> 24:04.500
So I do have an answer to your,

24:04.500 --> 24:05.500
uh,

24:05.500 --> 24:08.500
a question about dealing with it on different kernel versions,

24:08.500 --> 24:10.500
which you can do if you can,

24:10.500 --> 24:11.500
uh,

24:11.500 --> 24:13.500
mark a gay funk as week,

24:13.500 --> 24:15.500
and then the loader will,

24:15.500 --> 24:16.500
um,

24:16.500 --> 24:17.500
if it doesn't exist,

24:17.500 --> 24:19.500
it will still load your program,

24:19.500 --> 24:21.500
and you can check with a,

24:21.500 --> 24:22.500
um,

24:22.500 --> 24:23.500
um,

24:23.500 --> 24:24.500
believe it's, uh,

24:24.500 --> 24:25.500
called,

24:25.500 --> 24:26.500
uh,

24:26.500 --> 24:27.500
does gay has,

24:27.500 --> 24:28.500
has gay sim,

24:28.500 --> 24:30.500
or does gay sim exist?

24:30.500 --> 24:31.500
And then you can,

24:31.500 --> 24:32.500
in a core,

24:32.500 --> 24:33.500
like way,

24:33.500 --> 24:34.500
like dynamically fallback.

24:34.500 --> 24:36.500
So you can write a program that runs home,

24:36.500 --> 24:38.500
on all kernel versions,

24:38.500 --> 24:40.500
and then you would have to fall back dynamically.

24:40.500 --> 24:41.500
Yeah,

24:41.500 --> 24:42.500
let me be,

24:42.500 --> 24:43.500
we have has a way to check if,

24:43.500 --> 24:45.500
sort of a gay funk exists in the,

24:45.500 --> 24:46.500
the current,

24:46.500 --> 24:47.500
run a kernel,

24:47.500 --> 24:48.500
and core,

24:48.500 --> 24:49.500
you can help you to handle that situation.

24:49.500 --> 24:50.500
Yeah,

24:50.500 --> 24:52.500
but you will have to implement it fall back,

24:52.500 --> 24:54.500
or fail,

24:54.500 --> 24:55.500
this up to you.

24:57.500 --> 24:58.500
From there,

24:58.500 --> 24:59.500
Daniel.

25:00.500 --> 25:01.500
Yeah,

25:01.500 --> 25:02.500
I'm sorry.

25:02.500 --> 25:03.500
Uh,

25:03.500 --> 25:04.500
thanks for the presentation.

25:04.500 --> 25:05.500
Uh,

25:05.500 --> 25:06.500
you mentioned that,

25:06.500 --> 25:07.500
um,

25:07.500 --> 25:08.500
contributing,

25:08.500 --> 25:10.500
these gay functions is relatively easy.

25:10.500 --> 25:12.500
I wonder what's the general appetite for,

25:12.500 --> 25:14.500
like accepting them in the kernel?

25:14.500 --> 25:15.500
Uh,

25:15.500 --> 25:16.500
if, for instance,

25:16.500 --> 25:18.500
I'm doing something very protocol specific.

25:18.500 --> 25:19.500
So one,

25:19.500 --> 25:20.500
uh,

25:20.500 --> 25:22.500
the reason I'm asking is a context of the DNS protocol,

25:22.500 --> 25:24.500
where we use strings as domain names,

25:24.500 --> 25:27.500
but the encoding is really complex to parse in a BPF currently,

25:27.500 --> 25:28.500
because you have like graphics,

25:28.500 --> 25:29.500
length,

25:29.500 --> 25:32.500
and go the labels until you reach the terminal label.

25:32.500 --> 25:33.500
Uh,

25:33.500 --> 25:34.500
so I wonder,

25:34.500 --> 25:35.500
uh,

25:35.500 --> 25:36.500
yeah,

25:36.500 --> 25:37.500
was the key for deciding whether it should be,

25:37.500 --> 25:39.500
whether it's like general enough to be accepted,

25:39.500 --> 25:40.500
and,

25:40.500 --> 25:41.500
uh,

25:41.500 --> 25:42.500
and why not when I just have to write and see.

25:42.500 --> 25:43.500
Yeah,

25:43.500 --> 25:44.500
I mean,

25:44.500 --> 25:47.500
it's probably the question for the maintainers of the,

25:47.500 --> 25:48.500
you know, BPF tree.

25:48.500 --> 25:49.500
Uh,

25:49.500 --> 25:52.500
I would say that if the function is like,

25:52.500 --> 25:55.500
usable in a variety of domains,

25:55.500 --> 25:57.500
then it should be fine.

25:57.500 --> 25:59.500
If it's a very specific to a single domain,

25:59.500 --> 26:00.500
yeah,

26:00.500 --> 26:01.500
it could be harder to,

26:01.500 --> 26:02.500
to get it.

26:02.500 --> 26:04.500
So thank you.

26:04.500 --> 26:05.500
Yeah,

26:05.500 --> 26:06.500
I think Daniel has,

26:06.500 --> 26:07.500
uh,

26:07.500 --> 26:08.500
question.

26:14.500 --> 26:15.500
Um,

26:15.500 --> 26:17.500
I've took two questions.

26:17.500 --> 26:18.500
Uh,

26:18.500 --> 26:20.500
have you measured the overhead,

26:20.500 --> 26:22.500
like when you're disabled and re-enable,

26:22.500 --> 26:23.500
page calls,

26:23.500 --> 26:24.500
I think it should be pretty low,

26:24.500 --> 26:25.500
but yes.

26:25.500 --> 26:26.500
Uh,

26:26.500 --> 26:27.500
uh,

26:27.500 --> 26:28.500
I,

26:28.500 --> 26:29.500
I didn't have some like,

26:29.500 --> 26:30.500
very,

26:30.500 --> 26:31.500
uh,

26:31.500 --> 26:32.500
incomplete experiment,

26:32.500 --> 26:33.500
let's say,

26:33.500 --> 26:34.500
which would show that,

26:34.500 --> 26:35.500
uh,

26:35.500 --> 26:36.500
it's really a bit of like,

26:36.500 --> 26:37.500
units of percent,

26:37.500 --> 26:38.500
maybe even less.

26:38.500 --> 26:39.500
Uh,

26:39.500 --> 26:40.500
but I did have time to,

26:40.500 --> 26:41.500
you know,

26:41.500 --> 26:42.500
like,

26:42.500 --> 26:43.500
proper measurement there.

26:43.500 --> 26:44.500
So that's something I would,

26:44.500 --> 26:45.500
I would like to do,

26:45.500 --> 26:46.500
uh,

26:46.500 --> 26:47.500
didn't have time yet.

26:47.500 --> 26:48.500
And the,

26:48.500 --> 26:49.500
the question was,

26:49.500 --> 26:50.500
um,

26:50.500 --> 26:51.500
have you looked into the kernel,

26:51.500 --> 26:52.500
like,

26:52.500 --> 26:53.500
maybe under the library,

26:53.500 --> 26:54.500
so if there,

26:54.500 --> 26:56.500
some functionality that would

26:56.500 --> 26:57.500
implement,

26:57.500 --> 26:58.500
like,

26:58.500 --> 26:59.500
simplified,

26:59.500 --> 27:00.500
like,

27:00.500 --> 27:01.500
matching,

27:01.500 --> 27:02.500
for example,

27:02.500 --> 27:03.500
and whether we could also have this for,

27:03.500 --> 27:04.500
BPS.

27:04.500 --> 27:05.500
Right.

27:05.500 --> 27:06.500
Uh,

27:06.500 --> 27:07.500
yes.

27:07.500 --> 27:08.500
So many things matching.

27:08.500 --> 27:10.500
Uh,

27:10.500 --> 27:11.500
it was a different location,

27:11.500 --> 27:12.500
but I was checking,

27:12.500 --> 27:13.500
if there are some,

27:13.500 --> 27:14.500
like,

27:14.500 --> 27:15.500
magics matching things in,

27:15.500 --> 27:16.500
in the kernel,

27:16.500 --> 27:17.500
and,

27:17.500 --> 27:18.500
there,

27:18.500 --> 27:19.500
there,

27:19.500 --> 27:20.500
there's not many,

27:20.500 --> 27:21.500
I think,

27:21.500 --> 27:22.500
just one or two,

27:22.500 --> 27:23.500
which are very simple,

27:23.500 --> 27:24.500
but I think it was,

27:24.500 --> 27:25.500
on the last,

27:25.500 --> 27:26.500
uh,

27:26.500 --> 27:27.500
plumber,

27:27.500 --> 27:28.500
that,

27:28.500 --> 27:29.500
there were some,

27:29.500 --> 27:30.500
like,

27:30.500 --> 27:31.500
talks about,

27:31.500 --> 27:32.500
uh,

27:32.500 --> 27:33.500
uh,

27:33.500 --> 27:34.500
uh,

27:34.500 --> 27:36.500
rags matching in BPS.

27:36.500 --> 27:37.500
Yes,

27:37.500 --> 27:39.500
I think this could be a way to implement those,

27:40.500 --> 27:42.500
I think it could be useful for BPS trace,

27:42.500 --> 27:43.500
in particular,

27:43.500 --> 27:44.500
I mean,

27:44.500 --> 27:45.500
like,

27:45.500 --> 27:46.500
there are definitely use cases,

27:46.500 --> 27:47.500
because I've seen a couple of talks on,

27:47.500 --> 27:48.500
on the topic,

27:48.500 --> 27:49.500
uh,

27:49.500 --> 27:50.500
so yeah,

27:50.500 --> 27:51.500
I guess,

27:51.500 --> 27:52.500
there is,

27:52.500 --> 27:54.500
there are use cases for this.

27:54.500 --> 27:55.500
So,

27:55.500 --> 27:56.500
given that the,

27:56.500 --> 27:57.500
that the new work is,

27:57.500 --> 27:59.500
mostly driven by use cases,

27:59.500 --> 28:00.500
or BPS trace,

28:00.500 --> 28:02.500
how does that translate into BPS trace,

28:02.500 --> 28:04.500
is that more in terms of performance improvement,

28:04.500 --> 28:06.500
when internally you process strings,

28:06.500 --> 28:07.500
or is that,

28:08.500 --> 28:09.500
um,

28:09.500 --> 28:10.500
new features,

28:10.500 --> 28:11.500
new helpers to,

28:11.500 --> 28:12.500
that you're exposed to,

28:12.500 --> 28:13.500
you should be both.

28:13.500 --> 28:14.500
First of all,

28:14.500 --> 28:15.500
yes,

28:15.500 --> 28:16.500
it should be like faster,

28:16.500 --> 28:17.500
uh,

28:17.500 --> 28:19.500
easier to implement new helpers for BPS trace,

28:19.500 --> 28:20.500
thanks to these,

28:20.500 --> 28:22.500
and second,

28:22.500 --> 28:23.500
uh,

28:23.500 --> 28:24.500
once we get to,

28:24.500 --> 28:25.500
you know,

28:25.500 --> 28:26.500
implementing those,

28:26.500 --> 28:27.500
like,

28:27.500 --> 28:28.500
avoiding those current,

28:28.500 --> 28:29.500
well,

28:29.500 --> 28:30.500
pro breed,

28:30.500 --> 28:31.500
it should be much more efficient,

28:31.500 --> 28:34.500
and you should be able to handle larger strings,

28:34.500 --> 28:35.500
uh,

28:36.500 --> 28:38.500
I think there was a question over there.

28:38.500 --> 28:39.500
Maybe once we're coming,

28:39.500 --> 28:40.500
I guess,

28:40.500 --> 28:41.500
like from a user perspective,

28:41.500 --> 28:42.500
I mean,

28:42.500 --> 28:44.500
this would be transparent to the user,

28:44.500 --> 28:46.500
from BPS trace point of view,

28:46.500 --> 28:47.500
right?

28:47.500 --> 28:48.500
So you would do the plumbing underneath?

28:48.500 --> 28:49.500
Yes,

28:49.500 --> 28:50.500
of course,

28:50.500 --> 28:51.500
of course,

28:51.500 --> 28:52.500
yeah,

28:52.500 --> 28:53.500
it's, well,

28:53.500 --> 28:54.500
for the user,

28:54.500 --> 28:55.500
I guess the only,

28:55.500 --> 28:56.500
like user visible is that,

28:56.500 --> 28:58.500
now it's much easier to add new functions,

28:58.500 --> 28:59.500
so,

28:59.500 --> 29:00.500
we should get more Leo functionality,

29:00.500 --> 29:02.500
when it comes to string handling,

29:02.500 --> 29:03.500
uh,

29:03.500 --> 29:04.500
into BPS trace.

29:05.500 --> 29:06.500
I have two questions.

29:06.500 --> 29:07.500
The first one,

29:07.500 --> 29:10.500
whether the K-Fung helpers here,

29:10.500 --> 29:13.500
have also been extended to cover memory search and general,

29:13.500 --> 29:14.500
so,

29:14.500 --> 29:15.500
mem,

29:15.500 --> 29:16.500
and mem,

29:16.500 --> 29:19.500
CHR for searching large memory blocks of known links,

29:19.500 --> 29:21.500
and the second one,

29:21.500 --> 29:23.500
whether anyone has already tried to create

29:23.500 --> 29:27.500
a little rust nosed on the tailper for IRRS.

29:27.500 --> 29:28.500
Uh,

29:28.500 --> 29:29.500
so,

29:29.500 --> 29:30.500
for the first one,

29:30.500 --> 29:31.500
uh,

29:31.500 --> 29:32.500
I don't think so,

29:32.500 --> 29:33.500
uh,

29:33.500 --> 29:34.500
we haven't,

29:34.500 --> 29:35.500
like,

29:35.500 --> 29:36.500
implementing the general memory search,

29:36.500 --> 29:37.500
uh,

29:37.500 --> 29:38.500
algorithms,

29:38.500 --> 29:40.500
although it should be conceptually the same,

29:40.500 --> 29:41.500
so,

29:41.500 --> 29:42.500
uh,

29:42.500 --> 29:43.500
I guess there will be some,

29:43.500 --> 29:44.500
like,

29:44.500 --> 29:45.500
smaller differences,

29:45.500 --> 29:47.500
but I don't see any reason why those should not be,

29:47.500 --> 29:48.500
well,

29:48.500 --> 29:49.500
except it.

29:49.500 --> 29:50.500
And for the second one,

29:50.500 --> 29:51.500
if I disagree,

29:51.500 --> 29:52.500
it was about rust,

29:52.500 --> 29:53.500
uh,

29:53.500 --> 29:54.500
rappers,

29:54.500 --> 29:55.500
already.

29:55.500 --> 29:56.500
Right,

29:56.500 --> 29:57.500
I,

29:57.500 --> 29:58.500
um,

29:58.500 --> 29:59.500
I don't know,

29:59.500 --> 30:00.500
to be honest,

30:00.500 --> 30:01.500
I don't work on those,

30:02.500 --> 30:04.500
but I think there are a couple of maintainers of those,

30:04.500 --> 30:05.500
maybe in the room,

30:05.500 --> 30:07.500
or there are some later talks on rust,

30:07.500 --> 30:08.500
so,

30:08.500 --> 30:10.500
you can definitely ask those people that,

30:10.500 --> 30:11.500
uh,

30:11.500 --> 30:13.500
better audience for a question.

30:14.500 --> 30:15.500
Uh,

30:15.500 --> 30:16.500
so,

30:16.500 --> 30:17.500
the status of K-Funks,

30:17.500 --> 30:18.500
in IIS,

30:18.500 --> 30:19.500
that it's still working progress,

30:19.500 --> 30:20.500
there is a PR up,

30:20.500 --> 30:22.500
but it's going to be much soon.

30:22.500 --> 30:23.500
And after it gets in,

30:23.500 --> 30:25.500
we are happy to add as many rappers

30:25.500 --> 30:27.500
for the K-Funks this,

30:27.500 --> 30:28.500
there will be.

30:28.500 --> 30:30.500
Thank you.

30:31.500 --> 30:35.500
Any more questions?

30:35.500 --> 30:36.500
Yes.

30:36.500 --> 30:37.500
Uh,

30:37.500 --> 30:39.500
we're going to regard in the string copy.

30:39.500 --> 30:41.500
You were saying about the use case,

30:41.500 --> 30:43.500
and I think there is one that is really stupid,

30:43.500 --> 30:45.500
but I think it's a pattern there a lot.

30:45.500 --> 30:46.500
So there is this API,

30:46.500 --> 30:47.500
or like a API,

30:47.500 --> 30:49.500
like a agreement and deep path.

30:49.500 --> 30:50.500
If the file is deleted,

30:50.500 --> 30:52.500
it's going to be returned as file,

30:52.500 --> 30:54.500
space deleted.

30:54.500 --> 30:56.500
And every time you have to remove this

30:56.500 --> 30:58.500
freaking thing in user space.

30:59.500 --> 31:00.500
So maybe this is a small thing,

31:00.500 --> 31:03.500
but one of these use cases could be there.

31:03.500 --> 31:04.500
Yeah?

31:04.500 --> 31:05.500
Thanks.

31:06.500 --> 31:07.500
All right.

31:07.500 --> 31:09.500
When do we get the K-Funks to your best

31:09.500 --> 31:12.500
the string as a product for an LLM?

31:13.500 --> 31:16.500
Well, someone accepted it into the,

31:16.500 --> 31:18.500
you know, three, two.

31:18.500 --> 31:19.500
All right. Thank you.

31:19.500 --> 31:20.500
Thank you.

31:20.500 --> 31:22.500
Thank you.