All right, so the next term is if you are self-recenting the latest developments for
U-Procent K-Prox, I think I'll see you later, can I?
Thank you.
Okay, hello.
So yeah, my name is Yeriyoshah.
I work at high-development at Cisco, mostly working on that's about an English kernel.
This presentation is basically to give an update about latest data, how to attach
K-Pro programs, so that's the session attachment, so make people more aware of it.
And the other part is about E-POPs and about the effort to speed them up.
So let's start with the session, so if you have K-Pro program, you attach it to the
K-Pop, some true entry, or some kind of function, or to the exit.
And what you can do, you can use, like, either the legacy interface, or you can use the
per-flink, or a K-POP multi-interface, and you attach the K-Pop BPF program to entry, or the
exit.
Now, there is a session attachment where you actually have just a single program that is
attached to the entry, and to the exit, it's always this one program that is called
at the entry and the exit, and there are actually some benefits that I've mentioned
in the other side, but that's like the overview where the session attachment actually belongs
to, so it's just another way to how to attach to the K-Pop program with some benefits.
So I get to them, it's the same, very similar, on the U-POP side, so again, you have
K-POP program that you want to attach to the U-POP, you have a function, you'll attach
to the entry, and to the exit, again, you can use the legacy interface, or U-POP multi,
you always have, like, separate BPF programs to attach, with the U-POP session, now you can
actually, you have just one program that attach to the entry and to the exit, the same
as for the K-POPs.
So what are the benefits, so there's just one program that's sort of already benefit, you
have just one program, so maybe let's duplicate it, code, and just one file descriptor.
The other benefit is that the entry program can actually decide if the return program is executed.
That's actually, one of the reasons we did it, because in touch agon, very common use case
is that we attach for the entry and for the exit, and in the entry, we do a lot of filtering,
and based on the result of the filtering, we forced the return POP to some work, but
before session attachment, we actually need to execute the return POP, and it needs to
find out, do I have to work or not.
Now from the entry program, we can actually say, okay, skip the execution of the return
POP, and all the machinery to actually execute the return POP will be triggered, so we
say, some cycles there, the entry and exit program, another nice feature is that they can
actually share data.
It's not arbitrary size of the data, it's just 8 bytes, it's actually big enough to store
any kind of ID and the entry and exit program can use it to look up in the maps.
There are two special keyfunks for the session attachment, it's the BPS session is returned,
because we have just one program being executed in both context, and you need to find out
are you the entry program or exit, so that's the keyfunk for that, and the BPS session
cookie that will give you the pointer for the shared data, so normally like the entry,
entry probe store, some data for the return probe, just read that, okay, yeah, well it
is supported in the BPS, obviously the data on support wasn't managed yet, but it's already
the K-propsation support is in the CLEM EBPF goal library.
The thing with the CLEM EBPF library is that we need to wait for the stable release for
the feature to get to some stable release, so we can actually update the interface of the CLEM
EBPF library, so the U-propsation is turn of there, but it's coming, BPF trace, I don't
think it's in BPF trace it, but actually the proof of code for this feature was written
in BPF trace, so it's doable, and I guess it will happen at some time.
So there was the session attachment, so hopefully people will start to use it and find
it useful, now faster E-props, so there's been a development on the E-props to make it faster
because they're slow, there's sort of two ways to make E-props faster, there has been
like a bunch of generic E-props fixes made by the country, and other folks like to make
E-props more scalable, so when you have like many E-props, which many E-props, the throughput
of the system like throughput of the E-props going through the kernel, that's much, that's
much better now, the other way of speeding up E-props is actually related to X-86,
architecture on the 64 bits, and the idea is to replace the breakpoint with the C-scall,
as I were showing the next slide, E-props is based on the breakpoint, and the idea is to replace
with the C-scall because C-scall is roughly like three times faster than executing a breakpoint.
So just a quick, very high level overview, how it looks like when the E-props gets executed,
so when you decide you have a place in a binary that needs to execute the E-props, you
store the instruction at the breakpoint, then the application gets executed, hits the breakpoint,
goes to the kernel, run E-pf program, or any other E-props word that needs to do, then
it executes the original instruction because the breakpoint overwritten instructions, so it needs
to get executed, and it jumps back to the application to continue to continue the execution.
Now, the next slide actually explain just the idea, the view space on this slide can
not actually work in real work, but I mean it's simple enough to an ideal to explain
the idea.
So the idea is to replace the breakpoint with the C-scall, but you cannot do it like right
away, because the C-scall is some preparation, you need to store some data to the register,
to execute the proper C-scall in to save some registers, so the way you would like to do
it, and we do it at some point, is that instead of breakpoint, we use the call instruction
that jumps to the user space trampoline, and the trampoline itself executes the C-scall,
the C-scall goes to the kernel, does whatever the breakpoint would do, jumps back to the trampoline,
ideally execute original instructions, and return back to the execution.
This very common use case for the airport cannot actually work, because we cannot just
override those five bytes and get a wave at that. We are not in the control if you use
this application, so you have actually no idea what's happening in those five bytes that you
need for the call instruction, so any thread can be like any other path through the application
and go through that and jump in the middle of that instruction, so let's go to work,
fortunately there are some use cases that can work. One of them is URTPOP,
so I will tell you all the details how URTPOP is configured, at the end when there is a
URTPOP install on the function, there is a red instruction being called, and then there is a URTPOP
installed, it actually doesn't go to the original point where the function was called,
but it goes to the special trampoline that executes the breakpoint, and again breakpoint goes
to kernel, run BPF program and jumps back, so this is how normal URTPOP works.
Here we got really lucky, because we already have the trampoline, and we just had to
replace the breakpoint with the Cisco, that area, the unfortunate enough was big enough to actually
store all the instruction that we needed to actually execute the Cisco, so now the red actually goes
to the same trampoline, but the trampoline contains the call to the Cisco, Cisco goes to kernel,
actually in that's run on the slide, there's no execution of the original instruction
because it goes just right back where the breakpoint thing will go, so here it could actually
speed up on the probe with the idea, there's one more use case that seems that we can speed up,
and it is the URTPOP URTPOP URTPOP is sort of like
trace points in the kernel, so we have like the programmer decide there is the best place to put the probe
and the like with the pair for any other tool, you have the use data probe that you can connect to
and it installs the URTPOP, and you can execute your program on top of that, the way it works
is that you normally have like some kind of macro probably the system type of macro is the most
user one, and that just emit not instruction which is just one byte and that serves to actually
write on the breakpointer and the URTPOP execution that I explained in the previous slide though
happen, the idea here is to actually replace that one byte nope with the five byte nope,
which is just big enough to carry to store the call instruction for the user space trampoline
and with that we can just go to the trampoline, execute the C score and yeah there's no original
instruction here either and just run the EBPOP program and jump back, so with this approach we actually
know that those nope five, nope five instruction is there and nobody gonna jump in the middle,
so that's where we can do that, of course the probe there always are,
first probe is we actually update all the instructions, so it's kind of easy but not easy but
easier to write just one byte, the breakpoint when the kernel goes installing the UPOP writing
the breakpoint instruction it has to write just one byte with the breakpoint instruction,
now we have to do we have to write five byte and it's kind of tricky to do it in atomic way,
so we need to do some sort of procedure using the breakpoint and writing just like the
half of the instruction and then write the rest of the instruction, so that's that's one problem,
another problem is that as a compromise we started to use like five bytes nope, five bytes
growing instruction which has like one byte of the operation byte and the rest is the offset,
so we have four bytes for offset but it's a sign, so just half of that size and of course with that
you cannot cover the whole 64 bit other space, so as a result of that we actually have to
map the user space timeline closing up to the places that you actually want to do the
breakpoint install the UPOP, so it's still one page, so we don't waste memory but we waste
sort of well waste in 64 bits, it's not a huge waste but we waste the frames in that other space,
another problem, big work compatibility, so the feature that we do should not affect like
all the characters running from new applications and with using the not five instead of not
instruction the not five is not like emulated in the older characters so we cannot just switch
the macro to use the not five there needs to be, there needs to be some work on that so we don't
slow the older characters and the latest fun that we had is the second, so when I said that we actually
execute the Cisco we had to add new Cisco for that and for user space application that's kind of
seeming less, user space application never really executes like bytes have this new Cisco but
kernel does it for the application, so it's an application context, it looks like application
executed it but it was installed by kernel but second doesn't know about it for second it's just
another Cisco and of course there are plenty of configurations that that will just kill the
application because of the unknown Cisco, so looks like second people will allow us to have like
extra filter for for this Cisco inside of this second, so yeah that's that's current problem
that will likely get solved soon and yeah with that that's it you have any questions
sure I pick okay thanks for all the talk about the session you will mention in the beginning
I think the helpers will mention our headphones, is there a reason that those are not there
are here to get helpers? Ah so the question is if if while the k-funks are not helpers so helpers
was from like you cannot up anymore helpers anymore like anything that you need to helper for
now needs to be a k-funks, that's the reason
okay the question is okay about the
particular compatibility so there's a of the use dt-probes so there's a record for the use dt in
the elf note right for for each use dt there's a there's a record in the elf note and
I think as far as the note goes there's just the offset for the note so if there's one bite
replaced with the fight by an instruction I don't think this actually matters but I haven't
so for the issue that I mentioned we will actually have to maybe do some changes for the elf note
but to be honest we didn't get there yet we were more busy with those problems that I described
in the previous slide so are they? Is there any path forward optimizing entry for entry
to close as well as retro? So the question is if there's a path forward to optimize the entry
probes I don't think at the moment there's like any any thoughts on how this can be done
all this might be eventually speed it up with the new Intel CPU which name I just forgot
fret is just feature name of the CPU it's the feature so which claims like to speed up the breakpoint
like the traps so that might eventually eventually happen but like to speed up just the entry point
yeah there's this problem that I mentioned and I don't we don't see any work around for that
what is that set of things we're talking about with both programs of the U.S. problem
okay so the question is if the session will work in the in the go program
with regards to the problem with the return U.P. where so so the goal manages the text by itself
so that will work as long as normal U.P. works like that doesn't change the attachment at all like
it just change like you have just this one program that's shared now between the entry and the exit
but if you attach it to go program the manages its own stack you will be screwed again in the same way
uh if you modify that or not the duration right is there are there in your slides you will actually
allow this behavior even if you don't know if you don't modify the system of the creation
I'm actually not sure I understand but I mean by the kernel configuration for the capers
ah so that's like your kernel is missing so the question is that that's it please find me in the hallway
thank you thank you