 Yeah, okay. I have some slides basically I didn't expect it to talk about this right now But yeah, but I will still do anyway. It's kind of surprising So as I said, I just said I made a very rough slide to give you some ideas and the challenges we have some background is that in Google we kind of develop a lot of Internal stats to connect to the kernel performances traditionally we implemented the stats that are in the kernel in the C group of the system and the stats are for the runtime performances for containers for jobs that are running in the Container and we exported these stats to the user space by the C group file system So there's a stat the two properties that important is that stats are different defined as implemented in the kernel and What they're tightly integrated with a C group subsystem? So the motivation for this problem is that we want to migrate our internal stats in patients Into a BPF based Implantations so then can so can easily be extended and changed from the user space and allow faster iterations for the stats The there's some high-levels ideas to solve it to do this migration to really mean that it's pretty simple We have have this we have a tube BPF program to set a BPF program actually Why is for collection the basically I think of a that's a tracing program that the collector stats and then put into a map And then we have another set of our programs that extract the data from the map and export it to the user space There's a high level idea Let's talk first talk about the part of the exploitation the data exploitation from the kernel to the user space One important usage for the is to have a iterator BPF iterator program that to read the data from the map and Export it to the user space So we need a slight extension to the ether link so a program can Can can attach to the target and then we can create a link to the eater program And this link is actually primatized by the C group ID single name whatever and then we ping this eater link into the BPL file system so we can export this data through a Hierarchical way in the file system So every you and open the permission of the file to be readable by non-later users So anyone could read the file and when reading the file the BPA for eater program will dump the stats to the users who read it This is pretty much a simple design but however, there's a problem in that design is that because non-private users non-later users they can create a C groups And the while they are creating a C group they still want to be able to read the stats of their C groups But the BPA for this call is actually restricted to router users So the non-later users, even if they can create a C group, they cannot create a eater links or Png the links in the file system because the privileged operations So which means that they have no way to create the BPA of basis stats of files without the help from a privileged process or demons So just a short illustration is that the The last two steps the attaching and the pinning will require privileges. So the non-later users Drops running the container. They cannot do this. They will not get the stats of files automatically So to solve this some ideas that's already had the first idea is that we can have a dedicated a demon that to implement maybe an service interface and then when the C group When they come when the job run when the jobs want to create a C group They can send a request to the service and to say that hey, I'm creating a C group Can you pinning attaching and pinning to create this BPA basis stats file for me? And then We can we can get the stats by reading the files But this idea is not liked by our container runtime team the reason is that so we want to add a code in their demons and This will add the overhead and they have to implement this service for them and the second problem is that the Demons will not be highly available. It could crash at any time Which means that it crashes if you mean for you can create a C group But they may not to guarantee to have the corresponding stats files So that's our two problems and not like to buy the container runtime Just have some questions. Um, I was just gonna I was gonna let you get your next idea But that's fine. Um, we've had the same request as well. And this was also rejected because the The run the person running the BPF program. This is like a nested environment, right? Like it's so in our case. There was nested Docker environments, right? They have they have Kubernetes running the insight Kubernetes first for whatever reason And so there was really just no way that the team that manages the nested Instance could talk to the, you know, some root demon. They just think they were firewall There was no they didn't want to have anything to do with each other. So but yeah, yeah You don't need if you just give the right permission to the directory in a secret directory And is there anyone could create a directory in that parent directory and then that will create a So it's creating the secret but then what about how does the group Manages the permissions when somebody finally like move the processes around so because process is a file I think you need to like write the PID or something in Some implementation details is that when the container is created or runtime We will bind the mount a root will bind the mount a C group directory to the Inside of the container and then give the right permission to the directory and then you can Whatever you can do whatever inside your mounted C group directory and then that will give you You can do anything and though the we system our system doesn't track whatever you do So it's and if I recall the C group is a C group fs is a single mount, right? So there's only one instance in the whole Right system. So when you bind mount you still like all of the containers still see the same C group, right? Like you have a You have a C group name space as we will be do the isolation Group name spacing Not right now, but So basically it already has some isolation as a group and then we allow Our goal is to allow the arbitrary the number of users to create the C group So it has a flexibility to managing their processes running the container in whatever way to for the resource control. That's a go Yeah, so there's a mismatch between the C group capabilities and the BPF capability right now we provide basically That's a problem So the this is a general architecture of how this goes just the job creating a C groups and then asking the previous demon to say create the stats for me and then The privileges diamond will do is attaching pinning creator files Not okay and in the previous slide that it will do loading to or not We can assume that loading is Down at the boot time the kernel can do that and then what you do is just really in the kernel So but in the case that I was mentioning where they have nested pods and doctors and things They would want to also load programs from the from the nested thing, right? so so even that is like You would I guess if you were to do this you'd have to sort of pass the program through to the privilege demon and It was sort of a no-go Okay So the runtime team doesn't like this idea because they don't want the logic sitting there And and you don't want to run an extra team in just because you want to do this dance Yes, right, right exactly exactly So Continuing this we have a second idea basically How about this if we don't have this demon can we actually implement this demon at the bpl program So the so the the method here is that we can deploy a bpl program, uh, which monitors the C group events like creation and deletion And then the the program which monitors that will create the stats files Uh, uh, once it have a monitored detected events So there are need some extensions for uh for this for this idea is that we first We need to have a sleepable trace program points Because the operations that you do in your program is to do attaching and pinning this bpl for this course They will sleepable they will sleep So we need to have is a sleepable trace Program a three point program that to monitor the events and then to do the operation We also need to insert the sleepable trace points for in inside the C group code basically to attach to the Would be at the hook at the C group creation and deletion And we also need to enable link create the bpl for pins this course To allow it to for allow them for the sleepable trace point bpl pro so the The the the the solution here is like this. We don't have the demon, but we can deploy a program Probably by the kernel at early boot time Which monitors the C group events and then when you detect the C group creation The program will create this bpl of fs files and it could be readable by the jobs. So we don't have a demon So this was this is the same solution we came to by the way And we also use this we are also talking about Using this for checking signatures as well of those bpl programs So we can talk about it more. I think in the In the in the nested case, yeah, it is because they're well It's more like Too much container Yes, basically, but I'm Thinking that maybe signal migration or other stuff we also need to monitor But it's more complicated than just a simple creation deletion. Is it is it because you're trying to Restrict the C group stuff they can do or are you trying to Maybe miss this. So so in my case, it's like they want to load a bpf program Yeah, right and so when when they do the load you want to make sure that they're not doing something with that program That would be sort of outside their bounds of permissions Like like reading maps or whatever, right? It's certain helper calls, right? It's sort of more fine grain than And sort of just cat bpf It's like Yeah But that's this is slightly different in this case we we want to have some statistics files appear, right? So although ideally it would have been the some some unprivileged logic to have like Do some bpf system calls it ends up at that policy angle when you want to read maps there But here it is just like the only sort of permission issue we ran into when we were doing this was that there is this program That it's in the helper it tries to do a bpf syscall And this program could be triggered in an in a task context that is an unprivileged context The helper goes into the same sort of pathway as the syscall like would normally do So ob spin and then that that that track and then I think how I did a check if you're calling from within a bpf program That has been loaded from a privilege context, right? You wouldn't do the the privilege check there I was I was thinking that we need to do the syscall path from the bpf program Or we could create some helpers that would create links in the kernel But I think the syscall is working fine for us now. Yeah See there are some details basically we need to grant permission To the syscall helpers Because it's calling a task in a task context not from a interoper context So when the the permission there's a permission check in the bpf syscall That's the checks the current tasks permission to say I might allow to Create a direct trace in the file in the directory or something like that. Uh, so we also need to Do some modification in the permission check In the bpf syscall some details here, but I didn't list in the slides just to show the High-level architecture just just to like recap the flow a little bit right because I was unstructured There's a bpf program that is attached to a trace point in the kernel Right this this trace point can get Gets triggered by like a when a process an unprivileged processor. It's a cgroup The bpf program then does a syscall a bpf syscall from within the program itself And this ends up running although this is like Code that has been loaded by a privileged program It is running sort of in an unprivileged context in a current where the current itself is unprivileged So you can't create directories you can't do syscalls and these checks are the ones that have to be modified Exactly, exactly. So we that's why we need also need some modification in the permission check here This is the second idea and how does this interact with the cgroup namespaces? It's an independent issue Yeah, I mean you I guess you can just map it to like in your bpf file system in a different way, but yeah This is all the stats file exported through the bpf file system So what we what we are planning to do is to bind the mount a sub directory into the container We don't have a namespace for the bpf file system. So it doesn't have the same level of Isolation as the cgroups But here a bind amount could give us some some level of protection isolation here So Well, you have different mounts for a bpf file system if you want to right? Uh, yeah, we can mount multiple times I think I maybe missed something. So are you are you trying to like Pull links from privileged into this unprivileged cgroup? Is that one way to think of it? You can say that we I what I want to do is actually to Allow some unprivileged Stuff that to the unprivileged users for example creating these files Or this files. I think creating the stats files could be pretty safe to for unprivileged users to read So then I'm just trying to get my head around this So then when you like there's a syscall to do that right to create the file Right, and then you're saying you'd have a bpf program run there and do the permissions check At that point no no no no no the I have a program that calls the bpf syscall But inside the bpf syscall it has a permission check That's only allowed for previous users But at the core site of the bpf syscall you are in the unprivileged context So in that way you need to say that when you permission check you need to say that Okay, if it's called from a inside the bpf program, and then I want to allow it for our own previous users So you're kind of circumventing the syscall permission check by doing a bpf call that then does the syscall Only if it's called from inside the bpf program in the kernel context, right? I get it now Right right right right So if if you are going to modify the syscall permission checks to allow special case for bpf Maybe it's cleaner to just do like bpf says create link bpf says Optipen and like they will reuse the code, but we'll skip the check There's no actual like syscall like they will just be calling the sysbpf the way that If I understand correctly the way that syscall bpf program type does it just calls directly into it doesn't do syscall It's calls into bpf sysbpf, but it's not a syscall. It's just a function at this point Yeah, I understand but like permission checks are one we still go through this like multiplexer of commands and all this stuff. So like Should we have the helpers? Well, you have like this switch, right? Is it map create is it this no? Oh in that sense. Yes. So like instead of doing this like and pretending like we are doing syscall We can like have every command as a separate thing and like it will Potentially work slightly different in bpf context if it's called from bpf I think we can do something it will save it will save the demux only but Big deal Well, now that like we are working in like a different security Domain sort of I don't know that might be a little bit masterful. Just an idea. I know. Yeah But you're basically saying that we don't need to enable all the functionality from there, right? I remember correctly Disable Like when we do this Inside of it. There is no current check, right? No, this is no nothing. I know this part this part will be fine. Yeah, this is fine. This is fine. Yes It's only the syscall.c In the bpf this is a Global scuttle. So it's only this one, right? Yeah, those are this one. It's only this one And this is the capability check If you bypass these two lines Yes, so once you Want to go in here like here there's no no no no no one going to check that all should go through that works We'll come back Then you don't have to limit it to like a syscall program type, right? Like you can do it from everything like where it kind of makes sense sleepable Yeah, right So part of the change was actually to extend this call helpers to the sleepable trace points And then you need to insert the trace sleeper trace points into the c-group code and then And then be careful if you want to insert it into a sleepable context not in an atomic context Can I continue? Yeah There are maybe something I want to talk about is related to this idea There is a notion it's called demon nest container engine in the container world Um, it's a concept in the container world because that it allows the spawning container Demon nest container engine allows spawning containers without the help of preva Demons what do we actually do here in the previous slides is that so we dedicate the demons? Operations into a sleepable trace points to do it inside the kernel at the bpl program So the open question I want to ask you here Maybe some discussion possibly putting some discussion is that Can we do more operations to dedicate to the bpl sleepable trace points? This may be helpful for the uh for the move over demon nest container engines But that's not a point the key point for this talk, but what would be the example Yeah, I was also wondering the same I don't know. I'm just because this what I did in the last slide reminds me of this notion Just to say but people who are familiar with this demon nest container engines if they have some ideas Could bring this up and then probably we can do but if no, then should be fine Yeah, I think the answer is Why not? Yeah, we certainly can especially there will be like sleepable Events inside the kernel and there you will do all sorts of stuff like creating directors loading programs Peeling etc, but what would be this container management like operations you'll be like killing tasks Sure, why not we have a way to send the signal already so we can't kill stuff But yeah, I I don't know yet I'm just calling out to say if people have some ideas could bring this up And then maybe we can we can do something with a sleepable trace point to accommodate Yeah, this is not the end of the stuff if anyone I think the main thing to check is The main thing to look for is like Explain what are the benefits of the demon less container engine right and that would be That would be a catalyst for figuring out what operations need to be done I could say that it will make the demon for this for managing the containers a thing And they will reduce the the required privileges operations less so which Potentially improve the security in the system And that's the at least that should be that's something that's a demon less container is Is that they're talking about Yeah for better security potentially better security I would say I Maybe I'm just being slow, but I I don't get why how this demon less You you have a less operations performed in a privileged the context in user space and got it. Okay But the user space has a the unprivileged user space has a larger surface now to interact directly and That might be a that's the tradeoff there from a security perspective You have a monolith or trusted monolith demon that you that you sort of That you know the security properties often you sort of have some guarantees and the other case you have these individual user space these unprivileged bits but like I don't know the surface may increase We have to think about it a little bit more carefully from a security perspective at least I do see other benefits there like what what we know that where where demons would end up consuming more memory and stuff there, right? So Security angle we need to think a little bit more. Yeah, this is just a this is just a Question that's I I don't have a clear answer. I just raise this up. Yeah Okay, I'll go on There may be another possibility I was just thinking over the last weekend is that since the root problem is the privileged requirement for link create and the pinning Can we actually enable it for just for unprivileged users? That was of all the problems because we can have this runtime container runtime to do this but how What I'm thinking is that actually can we implement a fine grained access control list for these BPF assist corporations more specifically we may I'm thinking can we actually to enable these two operations as a per Program per operation basis as they just grant this link create and object opinion to the C group starts eater and Stats eater links So we can just have a better control over what the unprivileged users can do And then if we allow these two operations for the non-reusers, they can do it by themselves Basically just modify the user space part not inside the kernel part I was thinking I don't know if this is possible is that maybe we can implement such a policy engine using LSM BPF to have this fine grained policy to For better control because I do think as the the unprivileged BPF scuttle is a big hammer So why why not to like do full entry? What's the concern? I don't know. I think as the scuttle was there was just uh For I'm kind of a very conservative person I think we should do allow some operations, but for majority of them should be disabled. I don't know. It's my opinion I don't know how the upstream community would take this but Some discussions maybe I guess like for the for the BPF file system itself, right? I mean, it has its own dedicated permissions. So potentially just could allow it Right, right, right Yeah, like right now everything is under this big hammer like disabled unprivileged But the file system has all information checks pretty So Technically you could map the content of the file if you have permissions without going with the BPF sis call If you have permissions on the file with the ft the ft implements an mmap operation, right? So the it's just the BPF sis calls scuttle sort of ends up in the middle Adding an extra check whereas you could get the contents of You then you need to get the file descriptor In order to get the file descriptor you need to another BPF sis call get a reference and get a reference is also Part of the BPF sis call. Can you not just open the file and get the ft like a normal thing? I Believe yeah, you get a reference basically calling through the BPF sis call. Okay so this was I this was The forum I had this discussion and I'm not going to quote the person but like yes We we thought that you could already mmap as an unprivileged user if you had permissions on the file Part yeah, so what would we try it? Follow all the standard file system style So if there is an fd if you got an fd you like do everything with it So like so here the only like deviation from this model will be link create because link create itself creates an fd But I think like This is scuttle is there realistically only because of the well Spectrum of down stuff and it makes sense to think realistically only for loading Because loading program is what creates all of the security issues like If I think on the lot if it that's the only thing that stays under the under this is scuttle like everything else Potentially can be removed at least I don't see how Like what harm it will do Yeah, no, yeah, that's that's separate that that that's this admin forever. That should also stay Otherwise you can read them from I don't know different names Yes, yeah, yeah, I mean I mean the other operations like look up update like Ops pin, I think all of this is fine Especially like Ops pin object because they go through the file permissions like bffs has all the normal stuff So like x-races control like doesn't buy anything realistically link create is interesting Because link create is actually attaching so actually attaching is Like yeah, you would have you'd got to have an fd of the program to attach it somewhere so You expose the Yeah, but you need to write permissions there. So that's the difference like so you have file system So file system doing all of usl checks already whereas link create doesn't have like extra like it's just like Final you only got to have an fd So, um, I just want to mention I have something very similar to this one have lsm to control who can do this bpf like Probably cover that later, but like Just I think it's a good idea to and it could be very powerful in like other other Other metrics The other thing Like like for for example where we could also Attach some of the Operations to I mean like as you mentioned like given there's the file system You have all the permissions. This should probably be independent of the unprolished this detail, but if you have other stuff we could also um Add this somehow under some Final-grain lockdown policy for example if we wanted to write I mean there's also room for that where you can say okay With a given cap setting you can have this set of applications where you want to grant this but others not in the same Yeah, yeah Like a like a final-grain lockdown thing right like I mean similar what we have with the Right to the to to to user space to modify to to modify a program code. This is also under lockdown right now, right? But I mean Just to just to extend on that idea it would also be possible even though But probably not through the lockdown like lockdown but not lockdown Yeah, yeah, exactly Uses does it create like a so this is I I'm not the expert here So I'm asking people who do some bit of hardware security. I'm learning in this area But can you like use map writes in the kernel memory space is an unprivileged user to Like do some cache collisions and create a scope cache based side channel like a probe flush prime probe attack somewhere or like Or a flush tree or like some one of these cache attacks Well, you can of course like it's arbitrary code, right? Like that's why it's unprivileged disabled. That's why this is control is that Like cash is just one of the things right so like it's the first thing like specter. We want is what you describe me Yeah, I mean I'm saying like if you give map access like the oh just map access Yes, just just look up updates into map. Correct. Yes. Is it is it doesn't take the user into an address space that they wouldn't normally have access to Now they have sort of write access to that is to that to that location It's not executable. So in that sense, it's just memory like if you did like a map with a lock You'll get exactly the same stuff. It's just the region of memory So it's not But like the specter Well case a lot is different That's unrelated to that You need these things to form like an attack uh and explore there, right? But they're the same as in map, right? So like yeah, you could do it with a lock and you get the memory So how is it different? Like not related to bpf at all just like any kind of memory It's a memory No, what i'm saying is like they yeah, I I I need to I need to See where this is allocated like can you share some like where this Is it it's in the it's in the kernel it's not in the kernel text section, right? This is all vmalloc So it doesn't matter came out like a vmalloc. It's memory, right? It's a data memory. It's not executable So like it's same stuff as any other memory But you need a bft, right? Yes, I'm still I'm still don't see the concern like it's a memory like it's there are plenty of ways to get the same memory so like I don't see how like Allow on privilege like look up updates into the map would Do anything more than like existing just a map anonymous memory Same stuff I'm going to give you an answer and I try to find out what the question Okay, so I I mean you you would also need your bpf program crafted in such a way and I have permissions to load that right and if you don't and The only thing you probably do is like causing cash trashing, but okay. I think we diverge in a lot Yeah, I would say I want to I want to just mention that I also attempted to have this developer patch for mmappable task local storages Partly because of this reason, but anyway just one Head of architecture is that so we have this policy engine inside the kernel and then so the job can directly create the signal files could read the stats simple The third approach, yeah, this is the third approach Not not to circumvent the privileges, but to give a fine control over the Privileges Yeah, this is unprivileged. So grant the Creating of the files the privilege to create the files. Yeah This is sort of so I present a team summary. I presented I proposed three ideas The first is not okay I have a dedicated demon and the second is that using a sleepable trace points and the third is that so we give we develop a Fine-grained the policy engines to grant permissions some permissions to the unprivileged users. That's a three approaches here This is for only for the exporter parts There are not a part for the collection part because that's also needs some work That the C group stats is often hierarchical The stats that we collected often aggregated over the C group sub trace because for example, you have a job That's how well the container engine will create a top level C group and under this root of C group The our jobs could create a child C groups to do resource control But the stats we exported are often aggregated over these the child C groups and exported as the top level C groups So actually this is the collection side was worked by my colleague usri afman Uh, he's saying that it's almost a code of complete, but still testing Hopefully get some rfc patches posted in the mailing list soon Some idea is that the idea for the collection is that so we will be extending the our stats Our stat is the infrastructure that built in the call of C groups for collecting the C group stats And it's basically a framework allows the each controller in the C group to extend Basically this defines How do you flush the stats and then how do you? Aggregate to these stats. So we Use this idea is that we want to plug in after discussion with the Is the maintainers in the bpf office hours is that we want to plug in it's a bpf into our stats So we will introduce a new program type for the our stat flush a flasher the flasher is a Is that can attach to a C group subsystem and defines the logic for how to aggregate the stats across cpu's and hierarchies and then how How do you do the flushing? I don't have much details Until we see usri's rfc patches Yeah, still working almost code complete by testing The last the final bits for this work is that the the storage is for these stats So currently we put all the stats in the hash map. This is the workable hash map is indexed by the C group IDs, it's unique. So we put the stats there But it would be desirable if we can make the C group local storage to be usable In our cases because we believe that would be probably faster than hash map I Actually not quite get it because this question was raised by usri. I think it's a secret currently In my understanding my understanding is secret local storage used for network right now only used for network is not generically usable by Tracing or other program types. I don't know if that's a case that case probably that's what I mean I think what You're trying to refer here is like why not a secret local storage can only have a one-to-one mapping So each program bpf program can only one use can only use one secret local storage So at the low time if the bpf program is associated with Is a secret local storage a for example, it cannot use any other secret local storage, but Think about soccer local storage right a bpf program can use more than One one soccer local storage Okay, I think I don't know whether anyone remember that in a early discussion when we try to extend the Current secret local storage The program and the secret local storage has a one-to-one mapping. So that was one of the things bought out But in tars local storage soccer local storage, there's no Dislimitation, okay, I think that's I don't know why the secret I think I think what what um When secret local storage created is more like a sad local storage That's why the the whole design I think I think secret local storage was implemented first Right, and I forgot why And the one that are like two most there is secret local storage and they shared something And that's how it stayed but I don't think there is any like fundamental reason why it cannot be right Yeah, I think we can definitely extend the Tars local storage or soccer local storage idea to to the secret also I mean essentially you you have a ponder in the secret data structure Like socket and tars already has Okay, that's the last bits of this pipeline, um, thank you everyone. I take a lot of time and uh, Generally a lot of discussions So one more question. Thank you So, uh, I just want to ask so we try to convince the cgroup maintainers to take that directly into cgroup fs so Do you think we should try that again? I do think that's going to simplify a lot of the stuff I know maybe the challenge is not so So good, but do you think we still give it another try? I I can try I can try But but I I do think that as I said, uh, in my own opinion is that the last two approaches the Policy engine and the city for trade points both have their pros and cons Uh, I just want to get an opinion from everyone in the community to say which one Is cgroup local storage performance wise a little bit faster than like other local storages because we avoid like searching for for this So that might be what we can create another secret generic secret Yeah, yeah, okay That's all um, I recently hit a problem not exactly cgroup, but but it's also uh about the unprivileged is like So the program Used to be working. Okay. It has a it has the bpf and ccm in privilege and then So that demon is trying to read the map or Did it update update something or look up something from the map and one day that demon maintenance started using the user name space and then And everything's Broke it cannot even read the map. So is it a particular reason we cannot support user name space in in the people at church church I think so far it was mostly paranoia like security paranoia Mainly the paranoia in in this case like userness doesn't will not we cannot Be a different route like userness is still a fake route from everything bpf point of view Even if you're rude inside the userness, you still unprivileged You're still just a normal process from like anything bpf related So that's scuttle is the main point, but it's kind of orthogonal to userness What we discussed just just before like allowing map of uh Update and look ups based on fd only without requiring like privileged says it mean probably would solve that that issue Because like once you have the map of d you can just like go and update it right was like being unprivileged process But they they may not do they may not only only do they update a map Right, they may they may want to create a map or things and then suddenly they switch the user name space and everything broke so Yeah Is creating a map it's creating a map and putting it into a map of a map a safe operation to do for like pretty much anyone Or actually you will have a view of the map in the map, right? So you can you can still control that okay Well creating the map probably also should be fine for unprivileged like there are like Other checks there right so the main thing was creating a map the main issue is that it's locked right So we might need like ipc check for ipc lock stuff capability cap ipc or Whichever one is it? But that was the Mem log right? Yeah, but that's gone right? Yes, so now you have to Anyway, yeah, so map create might be tricky not to like directly to unprivileged but need to think more like how to Make sure that unprivileged user cannot dose the system So that's the only thing like once the map is created like look up update delete all fine but Like map because of max entries like what we can do like whatever Different max entries some other limits, but the mcg should really be the answer Did anyone try to implement policies with the bpf lsm for the bpf syscall itself? I think Robert has a question so I try to implement a policy for Adding a new element to the map but Because when I use that the bpf map security uke it was not Precise When you try to do bpf to map least they also tries to get the map right permission And this was not Good if you just want to protect the update Can you can you repeat what you mean like update is the right? So So the when you do the update that you ask for right permission, but bpf tool just to iterate over the maps also ask for the right permission So when I when I try to deny the the right bpf tool Stopped that the map for which the permission was denied. I don't know. Maybe maybe it could be a so bug or Yeah, if you have a chance, please follow up with that. I mean, maybe it can be fixed I don't know bpf tool probably runs as root and then you're denying root the permission to read To like write or some to the map and then bpf tool sort of there is an iteration that breaks like it sees an error When it tries to read that map and bpf tool assumes that hey, I should have access So there's some tooling that needs to be updated to understand that I don't have an access I have a permission error. I just just continue iterating on that But there's no problem with the lsm hook in particular, right? You were able to implement the policy that prevents updates for a certain map this dialogue So and understand that the bpf tool need the right permission when you do bpf tool map update element But not when you just need to list list them up So when I it was just leasing a map bpf tool map list and I had I wanted to deny Right and bpf tool stopped at that etc the map where I denied And so I didn't continue to to show the other maps after yeah, that's a tooling issue, right? It's not an lsm hook issue Yeah, it could be could be could be that Or I don't know. Maybe yeah, so it could be how the bpf map is implemented because it is the one that Um Generated the permission I actually think it's a tooling issue It shouldn't be on the like the map It just stops iteration at that map where it sees the access is denied So you need to probably add a check that says if error equal to e minus e perm continue or something like that Right because it doesn't expect right now by policy that maps will be denied access to while iterating on the maps Yeah, you should be able just to to list them It'll be good to see the snippet of the code actually when you present your lsm stuff. It's easier. Okay. Yeah We still have a few minutes Any more questions or comments? All right. Yeah, thanks. Thanks a lot So break for so we'll do we'll do a break right now. So uh for how long?