policy enforcing everything and then the thing I see that's a problem with that is other processes that are highly privileged can also just talk to the kernel and they're unaudited and we need to have some kind of kernel enforcement, which the policy file could then move into the kernel and be stored there somehow and we get into the problem of how we want to update the policy file. The thought I had was to essentially add a signature to the program itself and the signature is going to encode some extensions. So we add a code sign instruction, which must be the first byte. This allows us to quickly determine whether we're able to enforce code signing on the first byte from a kernel. Then we have the signature, the signature extensions in the EVPF program. The signature covers the extensions in EVPF program. What I would propose is binding the identity and there is some haziness here for me personally because I'm not very familiar with SC Groups work, but I think we want to encapsulate identity at a very granular level and this could allow for a program to run as a lower privileged user based on a higher fleet-wide policy and then we would add some kernel flags for enforcing signatures and a default trust public key. Yeah, go ahead. This is basically more, since it is very security related, right? Could you explain what you think about, what does identity mean here? Is it a user, public, private key or something or how does that work? So the identity I was thinking would be, so it will be a delegation and the identity I was thinking of was we would map it to something on the machine at runtime essentially. I don't think we want to do a public-private key pair because you don't want to ship the private key with everything and that is why. So what we're going to trust is a root key and I think if you're familiar with the SSH certificate format, something similar to that might be more apropos for EVPF or you have principles that are allowed to be, this is allowed to run as essentially. Did you have other questions there or does that explain everything? Or did you want to? I think this makes sense. So I want to introduce the content of a like signatory service which may or may not be on the same machine. We should definitely have a reference limitation that ships on the machine to make it very easy to test this but if you're talking a fleet scale or like a big business where you have a bunch of machines, you may want to have this off somewhere else kind of like your identity and access management. So essentially the user makes a request to the signatory service after they've generated the program and says hey, I want to sign this and then based on that user's abilities it will sign the program with the appropriate allowed capabilities on it. And then that program is sent to the kernel and the kernel verifies this at load essentially and it says you are, when it goes through the verifier it should be able to, before we even verify, we should be able to check the signature and say this is a signature that goes to the trusted root key. And then the capabilities are pulled out and make sure that all the capabilities and the extensions match the capabilities that the program is actually trying to use in the verifier. And if any of that fails, give up error, no permission. If that succeeds then go off to do all the dynamic translation necessary just in time and try and run your program. There are some open questions I have. So does the edited model like break down somehow with C-groups, like how do we represent like what needs to be represented when you start talking about namespaces? Do we need to support revocation lists?  If you use short-lived programs where you re-sign them constantly now you have the problem of I need to have a pretty high up time signing service that deals with this all the time. Or you can insert the concept of like time bounded into the credential itself and say that some of these are 15-minute programs for an engineer that's delegated or and these other static programs that the fleet deploys on a regular basis are good for months and that would potentially solve that problem. But there's a trade off to be made here and I don't have the answer and I don't know if there's a one-size-fits-all answer for this. It may be something that we might want to have flexibility on. So I just wanted to separate because the unprivileged and the editing concepts are a little bit more advanced to the on a very basic principle, right? If we have an EDPF instruction by that is signed by a trusted authority and that that signature can be verified in the kernel. There's a couple of differences we last talked about this, right? We were talking about file-based signatures, right? There's no concept of a file in a BPR program. So the signature is effectively in the program by code itself. Yes. That is sort of one key difference here. And I don't know what identity at like we in a privileged like sort of user space where BPR programs are only allowed by rule. I don't think identity matters that much as long as the program is signed by a trusted authority or the generator of the program in case of dynamic. I mean, we could also eliminate that if we think it's not a useful feature, right? Like start with the smallest thing that works. Yeah. But yeah.  Because I worry about identity because identity means different things to different people, right? And I'm not sure like in this model, do you have more slides, by the way? Am I cutting off other slides? No, no, no. I kept it short because I figured this would be like we've had a very open-ended conversation on this for quite a while from what I've heard into. So in my view, I think that the kernel piece should be a BPR program that I can write and then you can write your BPR program. And then we can sort of evolve independently if we want. And eventually probably some there'll be some common thing that lives there. I would suspect over time, but we don't have to agree on identity at that point, right? Like my identity can be whatever my customers want and your identity can be whatever your fleet wants. And I actually know we have customers with different notions of identity for whatever reasons, right? And we also, I would say like we have, I know people want revocation lists in this, I've heard people talk about it. So like, but maybe that doesn't make any sense to you, right? So like I'm not sure, like, I guess I would be trying to break it down to like what do we need in BPF to support this and like try to remain as flexible as possible so that we're not encoding something into the kernel that everybody has to do. So I would say that what I would like to see is the kernel become the enforcement point for the checking of the signature and whatever extensions you want to support. And if we want to make a helper program for different policies in that certificate, that might be an appropriate place to do that so that you could have that concept of identity segregated for each use case and user thoughts. I mean, so there's a, there's a, we alluded to yesterday about a mod verify sake sort of helper yesterday. I think like we may not, there is an instruction byte. We have access to the program and the BPF program is being loaded. We could encode the signature verification in the BPF verified itself and add a kernel config, but that sort of disallows the flexibility, John, you were talking about. So you could do this signature verification check in BPF pro in that hook there. Use the helper that we discussed yesterday of some sort. And then we have verification. And you don't need to do anything. You do need to make sure this comes up.  I do think you need to get that program in an early boot and we need to have a way to freeze it so it can't be unloaded, right? Because you do want it to be in the trusted boot probably with the PM at the bottom or whatever your platform does. There are two pieces that we connect from yesterday, right? Like Roberto's use case about early boot BPF and in the block area as well. And then the signature verification stuff. So I'm looking at this from the cross platform perspective because I want something that works on both Linux and Windows. And I think everything that we're talking about is actually applicable to both. And I agree with John's comment about, you know, using the gatekeeper style thing instead of hard coding it into the verifier or the kernel or whatever else.  And that's the one part that I find perhaps questionable as to why you put it in the program. And I'm thinking about scenarios like I want to take the same program and have multiple signatures. So I take your program, I vet it, and then I re-sign the same program with my signature for use in my fleet, right? Even though you wrote the program and you sign it first, I'm going to counter sign it or replace the signature or whatever. And it seems to me like that's much easier to do by putting into maybe a separate elf section and then passing it down along with the program because as long as you have the same key signing it and you're signing the same bytes and the signature matches, it shouldn't matter exactly how you encode it. And I can imagine the encoding could actually vary by platform. I don't know if it needs to vary by platform, but it could, right? That's kind of what I'm wondering. So what you're proposing or like what is proposed here is the, you don't need to change the bp of syscall here. In that case, you have a file, you have the attribute, you will need probably a .sync field. So one way to put those two together is to say that on Linux, the way that you map it into the syscall is by putting it back to back and saying prepending it, right? And on a different one that uses a different syscall mechanism, right, that has, passes two fields, you wouldn't necessarily have to do that. So it could be that the prepending stuff is a Linux specific thing as opposed to an ebpf generic. I would also say that the instruction byte code doesn't prohibit anything you said there and so much that you could still wrap an instruction byte code with an instruction byte code. And that would be a payload wrapping mechanism as long as your kernel understands that it would still be fine. Maybe I didn't fully follow. Wouldn't it be simpler just to put it as a field in the attribute that you load? Like we could just add it at the end and here's the signature array for implementation. Yeah, because if I look at, say, in Mateo's patch, he did something that was alongside not in the program or whatever, so that's what made me think about it because this is a new way of talking about it or whatever that's different from, say, how Mateo was. So the one thing I want to strongly talk about is that when we do this signature, however we do it, that we are assigning both the capabilities and extensions as well as the ebpf program. The easiest way is to get those aligned side by side so they don't get messed up is inline. If you start splitting the program different and putting the capability somewhere else, it's a chance to screw up the verification or a chance to allow somebody. So in this case, I'm calling the capabilities potentially an identity, what the ebpf calls may be allowed from the core framework as well, things like that essentially. Are you allowed to write data or are you only allowed to read data? These could be things we could do. None of these are mandatory, but I'm calling capabilities just a generic catch bag of extensions that could be added based on use cases. Yeah, the concept of capability shows up in a bunch of other security contexts, whether it's a specific term and use of certificates and IPsec, the term escapes me right now, it's EKU, so it's similar kind of an EKU usage. It says you're authorized to do the following things and you can't go outside that. So I think that's a good idea. An EKU is the common way of doing it, yes. So I think that part is a good idea, so it's just everything else, it seems to me like it's, it could be done either way, that whether you encoded prepend or whether you encoded as a separate field or whatever depending, seems to me like it's isomorphic either way, anything you can do with one, you can do the other one and so if we say that this should be done cross-platform, that's okay. I don't know if that's gonna cause any other constraints, I don't know, that was my question, so. Just, so this is how I map it in my head and you can correct me if this is correct. This is an incorrect representation of the capability stuff, right? You have this byte that verifies the sort of, who built this program, right? Who signed this program, that bit is checked there and then there is a mini sort of LSM-like policy there. This is what you can do with this. You should be able to do based on your credentials and that I've given you this permission, right? From an external entity and this is what you're allowed to do and your mod verifies, I say in the BPF pro LSM hook just basically then after verify signature expands this policy or capability stuff into various checks that it can make. Okay, these helper calls, this stuff, right? That bit I think is more advanced, right? Like currently the mechanism that we're looking for at BPF programs, especially due to like side channel stuff is all or none, right? Like, or programs that are generated by trusted command line delegates. I agree that it is more complex. I also would state that it's not necessary for the first cut of anything. These are all, that's why I'm calling capabilities like this grab bag or whatever we want for whenever we need it. But you're right in pointing this out because this is not a one, two, three year thing, right? We want this to live long enough that it can be extended. Yeah, I don't think we wanna deal with like an API change for how we do signing and I think that's why this has been stuck up so long, potentially. Don't be sensibilty, like now we don't need to use it. Yeah, it's very different from like simple engineering stuff that is you ain't gonna need it again, but it's more, it has to be future proof in when you're designing the stuff. It's design resilience. And maybe we never use any of it except for like whatever use cases that immediately come to mind to the people in this room. I think identity is something that some people care about. At which point and what are you signing? At which points? So the signatory service is doing the signing of the program. The byte code. Which byte code? Like before it got like relocated, all the sub-programs got added and all the stuff were after. I was saying before and then any translation that happens in the kernel essentially. So like use cases like BPF trace are just like out of the question in this. So what I would think is that BPF trace could still work if it had the ability to talk to the signatory service as a flag. And if we standardize the way that works then signing still works, right? So you're saying like you will trust BPF trace to do the signing? To talk to the signing service. Like what was the mechanism of trusting BPF trace I guess? Cause like it doesn't seem BPF related at all, right? Like how? Yeah, there is, I have a talk today about like the way we could do this. Like we can do it with like, you can create a policy domain of like dynamically generated BPF programs that are actually trusted and are allowed to run unsigned code at that point, right? Or they can, as Jason mentioned, you can talk to a signatory service and hey, hi. So in that scenario, like if you allow BPF trace to like do its own signing verification, right? Like what does BPF trace provide to the kernel to prove to the kernel that like this BPF program is okay to run? Yeah. I can't do it. So for like our case we would do you would when the BPF trace started, right? It would be signed. So like you would know that that application is BPF trace. And then you would also know things like where it's running, like what's the context? Like you'd have the UID, the GID, like all of this stuff. Like is it in a pod? Like and you probably would also know you might care about the attach point but probably like first cut probably not. And so you would say like, okay, at least I trust this application and I trust it to run in this context, right? And at that point we would probably just audit it, right? But then there is no signature that you assign it to the kernel, right? I mean, like these... You could still do the signature, right? You could still apply a signature in BPF trace. But what does the signature mean, right? Like why? All the signature, what the signature gives you is it lets you put enforcement on at the kernel, right? So now the kernel can, if you want enforcement on it, it works. That would be a sort of imagine the signature has some capability checks there, right? And the capabilities in code where BPF tool should generally be allowed to do. And if BPF tool somehow generates something that somebody's found a thing that is trying to exploit something in BPF tool, or BPF trace, sorry, then it would, signature would be like, hey, you're not supposed to do that and you're doing that. Okay, so signature is not just like some hash function of the bytes. It's like something more composed of like bits, what's allowed and all that stuff. Yeah, I think some of this was, you'd ask the question, how does the signatory service know that BPF trace is the thing that's doing it? And I think that's what we were just responding to, it says, okay, as long as BPF trace is signed and so on, the kernel would trust whatever key the signatory service has, which could be unbox, right? Which is what Jason was saying before, right? So there's such like a local RPC call, right? And so the signatory service, if the kernel is the only key that it trusts is if you're using public private keys, right? And the private key would be held by the signatory service. Using something other than keys, it's whatever it is, right? That the kernel has. And so the signatory service is what is then checking all that, is it running in a particular context? Is it really BPF trace and so on? So I think that's what the, we were trying to answer to your question of how does the signatory service know the kernel still only trusts the signatory service in Jason's diagram? I don't know if that answers your question, but I think that was- That was- I'll just say there's like the other option is to just not use the signatory service for BPF trace and have the kernel verify, like I know that this application and I know that this UID and this all this kind of stuff. And I think that's what you were saying when you were saying that you could just put it all into an BPF program and one BPF program would know that it's BPF trace, another one would just use signatory service keys and we don't have to agree on that because people can use different gatekeeper programs. I'm just a little- Yeah, they can get complex and we should avoid complexity where we can. And this may not be the right solution, maybe there is a better solution we can come to in this meeting, right? Like that's why we're here today. I like this picture because he specifically said the signatory service could be on box or off box. And I guess I like the left half of this picture. I like the right half of the picture in the other one that was John's diagram that had the gatekeeper program on it. I mean, I think you could still combine these two together. Right, exactly. That's my point is I would combine these two, put the gatekeeper on the right side of this one and the signatory service in the left side of this one said the signatory service could be on box, out of box could be bundled into the application. Like if the signatory service was bundled into BPF trace, you could get one variation we were talking about.  But I would put this picture and the other picture together into one diagram. I saw the rim, it's like by the solution and I picked up the mic, so let's see. No, let's say it's high. I'm curious to see what you folks think about this. Well, just wanted to remind everyone what Andrei was alluding to, that the programs themselves, it's a completely useless piece of thing to sign because there's so much BPF does after it's parsing, like doing the relocation and adjusting sections, missing the function, so it's the only thing. So it's only the most trivial programs that don't use maps at all can be just simply signed and will not be modified by the user space loader. I agree with this, right? This is, the signature here assumes like that the bytecode that is generated by the compiler itself at that point, before runtime relocations is sort of, could we, have you ever considered like doing these relocations in the kernel? Like is it ever going to be the case that we're gonna do these relocations in the kernel? So, well that's what we've been doing for the last year, right? So slowly moving all of the pieces that BPF does into the kernel. Once they are in the kernel though, then you have the capability of putting that all behind a signature check. Sort of, so the way it is right now, we have this loader program that can be generated, that's part of this like light skeleton. What it consists of at the end, like it has consists of two main pieces. One is a big map array of one element and the program. So both need to be signed. So this program, this loader program essentially is executor of the instructions, the pseudo instructions that are in this array. And inside the array there can be 10 different programs with the attachment points, 20 different maps, how they create, how they populate it, and so on and so forth. Just gonna add that I like the idea of having all the relevant relocations here be done post signature in a trusted component. On Linux that's in the kernel, on Windows it's in a trusted user land process that basically runs with the same privileges as the kernel, it's just different address space. And so that same direction that Jason is proposing, if you do that, then I think that is abstract enough to work even though the details are different between Linux and Windows, the concept is exactly the same between the two of them, which is you check the signature, you do all the relocations in the appropriate spot on the trusted side, that you don't do any of the relocations until after you've confirmed that the signature matches and that you're gonna be doing what you're gonna be doing, and then you can do other relocations before you actually install the jittered code or whatever it is, so. So I think fundamentally, right, like you have what you mentioned here, right, there is a loader program that encodes the actions that are being going to be taken by an intermediary like libbpf or something, right, and then what you do is you sign these actions plus the original instruction blob, right, which is fine, the format of the signature that Jason proposed is a byte in the beginning of the program. What follows is all the other stuff, right, the actions that are going to be taken by the loader program and the actual instruction byte itself. So the issue is with the verification check on how you're going to verify that stuff. So just another quick comment on this first signature, first new instruction encoding the signature, I still don't see any point of doing that instead of just providing the signature as like another property when you do BPR pro globe, right? Is there any benefit to like embedding it into the instruction set? Why? Either way you need to change kernel, right? So you just extend the syscall. You don't have to change the syscall to the answer that that would happen. But like you have to change the kernel, like even if you don't change the syscall, like just to support this, right? If you want the enforcement at the kernel then you have to change the kernel anywhere. You don't though, right? Like currently you just need a helper that Roberto proposed yesterday. Okay, yeah. And then you verify it in the BPF program. And we add the, sorry, I forgot that we're talking about the BPF gatekeeper hybrid model right now. The kernel API or ABI changes the helper that we add and the helper is beyond this particular signature used. Do you have a microphone? Yeah, sorry. But like if verifier doesn't know about this instruction and doesn't skip it or does something with it, the program should be rejected. So like either way you need to teach verifier about it. Like if you are going to teach verifier, you might as well just like teach the syscall to get like this as a separate property. I agree. I think this is like the verifier change to me is not an ABI, like it's fine. The verifier is going to skip instructions. Instruction set is an ABI. Yeah, it is. It's an ABI, let's say. It's like even stronger basically. Like cause like part of the syscall you sort of can like deprecate like while this instruction set is. I'm personally indivulent as to how we encode the signature is. So that was one, like, but another one, like I want to make this more interesting, right? So let's say we even solve all this problem that like program code itself is like not changeable unless until it gets to the kernel, right? What do we do about like different attachment points, right? So like you can verify the U probe or K probe and then attach it to many different functions. And that might be, might have like some security implications, right? The capability stuff. This would say that like the, this function should be always attached. Now, like if you encode this. So basically like this magic signature encodes like everything that's possible to do in BPF.  Cause the capabilities of like BPF are like super diverse, right? So like K probe targets, U probe target, like F entry targets and like other different, like they are not always like just one string that you attach to, right? It's if you care about this, right? Like if you care about the attachment point there, if you, if you consider that like you don't, you don't have an extra policy that is sort of enforcing the stuff and you want this to be in the signature, then it could be in the signature. Otherwise you could just say like, look. So this signature is like pass through into like some custom BPF program in the kernel and like kernel meaning like very fire, let's say, doesn't know about its format. Is that the idea? That's what we are proposing, yeah. I see, okay. So this is like some black box set of bytes. Yeah. Which is like wire through into like custom BPF program that makes ultimate decision. Some work like that in my head, yes. Okay. I don't even, it wasn't clear, sorry.  If not, like we just ignore the signature basically. I would just like put it as another field in the struct to pass it all the way through, pass that attribute to the. The important, like the thing that I didn't understand, like the important thing is like this signature, like very fire and kernel itself doesn't need to understand like it's format because if it is, then like it's this whole committee discussion, like what I put there and okay. Which is why I think it's best to put it in the program. So we keep it like custom black box to like specific solution, right? Yeah, okay. That's fine. I was wondering, do you have a, or like would there be a use case where you have several sections of the program with different signatures or incapabilities maybe at some point, like if it's encoded. So you're assuming like a helper that's more restricted than the parent or? No, no, like so that basically your pseudo instruction for the signature verification would only cover some part of the program and then you can have like a different part with different signature and capabilities, for example. I was not envisioning that. Okay. It seems like a lot of complexity. But that would be an argument in the favor of putting it in the instruction set. That's what, yeah. If you can, if you have multiple signatures in the instruction byte code, then you're... Well, it gives you the ability to wrap multiple signatures, but he's talking about actually partially signing the program, I believe. And partial signatures, like I struggle with a use case for partial signatures. I really don't like the idea of new instructions here. Like they are not like, there is nothing like PPF instruction set is like X86 and ARM and MIPS and all combined. Do you have an instruction X86 that says verify mis-signature? I don't know, are we talking about SGX? So, I thought about it. Even as JX is different. So, I think under his question about what are you signing and is it before or after? And I said, well, this is what Jason's proposal was. And I had a chance to think about it myself to see what would the equivalent be on Windows or potentially other runtimes? On Windows, the verifier is not in the kernel. It's up in trusted user land. And so, the question is are you checking, so if you were to think about the gatekeeper program or checking of signatures, is that done before or after verification? Now, in Jason's answer, you do it before verification. What that means is that if you were gonna do the verification, sorry, if you're gonna do the signature checking in a gatekeeper program, that means you need the gatekeeper program to be running in user land prior to verification. Because of verification, you never even hit the kernel. That's complicated. It's possible to run a BPR programs in user land, but we haven't done any of that work. And so, that's actually fairly complicated. You could also say it's done afterwards. You could say that it depends on your implementation. Just like if you have multiple gatekeeper programs, you don't have to agree. You can just say, oh, well, that's up to the platform. You could actually have multiple gatekeeper programs, one before, one after, if you wanted to apply that concept. Or maybe it varies by platform. So, all of these I think are possible here that I think if you said, and if you said that the gatekeeper program needed to run after verification, then having it be in the instruction set is odd because now the verifier runs on something that has this extra instruction. It's just odd, right? So that's why I didn't like the separate instruction thing. It's possible to do. It's just work, right? But I did want to think about the notion of saying the signature checking, I can imagine cases for doing it both before and after verification, either for different platforms or even different use cases in the same platform. So I think Andre's question was- I'm not sure how to work on Windows when verifiers separately, but at least in the Linux kernel, what we can do is to check the verifier, the signature before starting the verification, but then it only will be like a Boolean flag. Did it pass the verification? Then during the verification, we will have several LSM-like callbacks that will check whether this particular helper is called and so on and so forth. During the verification, there will be many times the secondary gatekeeper program will be called. And at the end of the verification, that will be the final decision because verification itself, like after verification, we cannot do the signature check because verification changes the code as well. Like it massages the code quite a bit, so the code is not at all as it was in the beginning. So it has to be like many, many steps, one in the beginning, then several calls during and then. Another direction that we're looking towards for the future, and I think those conversations happen across platform, but I don't remember which context it was in, whether it was in BPF meetings and the BPF summit, a leaf meeting or a BPF for Windows meeting or some combination of all of those, which is, is it possible to run the verifier off box? In other words, if the fact that something has been signed, does that mean it has been signed and verified by the signatory service and therefore you can skip the verification step because you know the verifier is already passed with the current kernel version. Is it possible to offload that in which case you get a bunch of CPU cycles back because you're avoiding the verification step? So is it possible to do that? Is it a bunch of work? Yes, but is it possible to say my gatekeeper program causes it to bypass verification because it knows the signature has that thing set that says the signatory service has already done that for me? Is that possible to do? Is it might be a good long-term direction? It is one that is being discussed. And so I think some of the things that Jason is talking about is actually aligned with helping in that direction should people wanna go in that direction. I don't think there's anything prohibiting what you just described. That's right, that's one of the things I like about this is it certainly doesn't prohibit it and it may even make some things be easier. For the Linux, we can give this initial signature check passed. We can skip probably 90% of the verifier but not all of it. Like that code elimination, you have to like, I don't even know if you can skip 90, right? Like for that code elimination you actually need to trace the state and know like which ifs are taken and not. So, but really like in practice, like is it that much CPU time spent like in verification? You verify once and around it like millions and billions of times. So far it was never like really such a big problem. If the verification is like considerable concern, like the verification time itself, like CPU use for verification, let's say. So, does anyone have a use case where they're loading BPF programs like very often that need to be signed? So not very fast. It would be useful if somebody had statistics for like recovery from a DOS attack, right? Where you don't have a lot of CPU cycles. How much of a difference does it make to have to go through verification? Does it slow things down because you're already maxed out? I don't know. So if somebody has stats, it'd be interesting. So, there's probably my naive understanding. The signature is like you claim what you do and you need someone to verify you actually, this is what you do, you didn't do anything else, right? No, that might be wrong, but I think that's my own understanding. Let me know if that's totally wrong. But the thing that's the state of truth is what this program is doing is in the verifier, right? The verifier knows exactly this program. Does this help or is it not that help? To me, like the signature service should be together with the verifier. It's the verifier to say what this program is really doing, that's the state of truth. And why do that twice? So signature certificate is like a verification or a stamp or a certificate of authenticity, right? Like I built this, this program was, I know about this program, I, there is some reference to the I here, like who am I, that is a part of the signature, right? And I certify that this BPF program, blah, blah, blah. So that is what the signature represents here. It's more than just policy checks. Also if you're doing enforcement in the kernel, maybe you have a workflow where you want to not allow an engineer to do something with a BPF program in production unless somebody else signs off on that. And it's very hard to do that without some kind of additional service sign off on that. And that's what the signature service allows you to do is to build in that additional complexity for a large fleet. I think there is still two sides. One is like what does the program actually do? And the other side is whoever initiate this program, load this program, whether he's capable to do that. I think that's the two part of it. I think the verifier is still the owner to is the state of truth of what the program actually do. Yes, but what if you wanna disallow, even though they have root privileges, what if you wanna disallow somebody from making right calls to something? So that's, like let's go back to, I think that's the idea is like you do the verifier, verifier say this program do, then after the verifier you'll say okay, this program does this and here's my ticket, I can do this. So I think there will be the after verifier. Oh, that's the keeper. So just to like do concepts here, right? This is what Jason mentioned there is the capability of the MAC aspect of the signature that we talked about. That is a secondary goal of the whole signature thing. Now, talking about the secondary goal, the MAC policy hook for BPF is located before the verifier. It's like BPF prog hook is before the verifier logic itself. This is where you read the instruction code and try to decipher. You have the Cisco arguments, you have the instruction code. You see, is this a BPF program that my MAC policy allows to be going further? And the verifier is actually doing as Alex mentioned, significant changes to the instruction byte code. So the MAC policy checkpoint is already established in the kernel and that is before the verifier. So if we need to move that check after verify, then that is independent of this discussion, right? We can move it after verify if you think this is the right place but that is independent of this particular discussion. The other aspect of signatures there is, I think you probably understand that. The main aspect is to establish this BPF program is known to be a good program, right? From by this entity. And it represents the sort of connection between this entity and this program. That is what the signature sort of represents. So it's just the capability part. The signature service only provides a capability part. And the signature service is just acting as a stamp of approval. So the signature service will not do analysis of the byte code? The signature service can do whatever you want it to do but it could do analysis of the byte code. It could also skip analysis and be like, yep, that's a program and here the capability is assigned with this identity. And if those turn out to be not true later that could be a different problem to be solved at the verification time. For example, I want to say that like all BPF programs should be built on this machine. That is my like trusted builds out, right? And then I need to ensure that when the kernel loads this program, this part of the BPF program being built in a trusted build server is checked. This is done, if you have a private key in that trusted build server, it signs the BPF program. The program is shipped with the signature. The signature is verified. So that would be. So this signature, right? Like it's like cryptographically signed so like you cannot like spoof it, right? So like random like an unprivileged incorrect process cannot just like substitute it, right? So this is important point. Like probably would be nice to like for non-security folks to emphasize it. Like this signature, once you get it, right? Like you can verify that it's truthful, right? How did you get it? That's not like the kernel's concern basically, right? And then like to song's point, right? That like we will need to teach verifier like about all those capabilities. If we do that, then the signature format becomes like the API, right? Cause like verifier needs to understand. I think like the alternative to that would be like to instrument verifier, right? Like with interesting points, right? So like helper like is called and like stuff like that. And then like maybe call program. I think we talked about this, but like kind of summarizing, right? We'll have like hook or trace point or whatever some mechanism to make decisions before the program is verified. During the program is verified, like we'll have like helper called, map was created, stuff like that, right? And then after that, like we can still pass like the finalized like that code removed BPF instructions, maybe jittered instructions and let the program also like process it if they really want to. That's like a lot of complexity, but if someone wants to go to the great lands to do that, they can actually analyze BPF instructions, right? Like we have BPF loop now. So I think that would be like the way to like keep this signature completely black box to the verifier, which would be good, right? And that to the capability part of the signature, which I think currently is... Microphone? Yeah, this is the capability part of the signature, right? Where we think like this is a future extension that we will need or like the first basic... Agreed, agreed. I like the proposal for the capability verification if this needs to be in the verifier as Song pointed, right? But the other thing which I wanted to like for the signature part, the basic thing is to establish that identity based, the verification of this. Like there is a, I have a signing key. I've signed this program, right? There is a verification key in the kernel that verification key verifies a signature. All of this is cryptographic math, nobody can speak. So there are these components. You can correct me if I'm wrong. I think that is where we have landed right now, yes. All right. So, and it just, it's just feel weird to me. It's like the verifier is check every bit of your DNA and the security build server just give you an ID. This is a valid, like the trusted person, but like the verifier is looking at this like much more great details. So I think in the model that Andre was mentioning, then the job of the verifier is just to check safety. It's not whether it's authorized, it's whether it's safe. And it happens to generate, oh, by the way, here's what it did, right? So it used the following capabilities, but it doesn't, it only checks safety. It's then the gatekeeper's job, whether or the signature checking job, right? To say, which could be before or after the verifier. And I think doing what you said actually allows it to be done either before or after because you're basically doing an AND gate that says, okay, as long as it is safe and as long as the signature only authorizes the capabilities that the verifier says that it uses, right? Then it doesn't matter which order you do the math. Because what some of you are proposing is a question to the threat model that is a signature strength to solve. So I'll give you an example, right? I built a BPF program. The BPF program is a valid program. The verifier is going to accept it. And I write some C code. This is compiled by Clang to generate some byte codes at the end. Now, it was not built on a trusted server. So the Clang is a malicious Clang, right? What it does is it adds a little side channel gadget into the middle of the program which the verifier cannot detect. Valid BPF code does branch target but for poisoning, right? And then, yes. So verifier has no way to know that this was generated by a malicious Clang, right? And has added instructions in the middle. So what that signature represents is your trust essentially for our use case or use case for this is this build tool chain that I used to build this program is trustable. I would put it that verifier checks like technical correctness of the program. So like array bound checks while signature provides like the intention correctness. Like yes, the intent is like no one and we are okay. Was it given it's correct technically, right? So verifier like still does it as if it was root. It was like all the capabilities but like then we need to make decision whether like to pass it like further if it's correct. I think that's how you, right? I have a question regarding like, so if you have like a BPF trace version and it's running on a machine. So how does it talk to the signatory service and how does signatory service make sure it's actually the BPF trace it pretends to be? So how does it look in practice? I mean, I'm just. So are we talking on like a personal computer or we're talking on like fleet scale? So what I would imagine is some kind of like we would define some kind of if we were going to have BPF trace be able to talk to a signatory service, right? We would define a like an API contract for how you talk to a signatory service and anyone can implement that doing whatever they need to do, right? And if my signatory service wants to do some additional verifications like that you're coming from a certain location in the world and you're running as this UID GID and I can map that to this internal identity then we can do that, right? And it's just a contract for the like I want to sign this, here's the information I have and then if all of that checks out the signatory service will apply the signature. All we want to establish is this BPF trace is something that I trust to be, right? So one way of sort of establishing that is an FS verity like partition. So I will say that all executables are like or any execute, the very minimum, right? Any executable that is generating dynamic BPF bytecode is going to be run from this FS verity verified partition and then the signature service can sort of ensure that based on your environmental setup this is coming from an FS verity verified partition and verify that hash for the FS verity partition. And we could extend the model to have like a pre-signed binary section as was described by John earlier, right? Like there's nothing prohibiting that. Yeah, I mean, early on at Netflix we tried to get system tap going and it had its remote compilation thing and it was a nightmare because service teams had implemented firewalls and when there's an outage and you're trying to run scripts in a hurry I can't even connect to anything. Networking is slow when I can connect to things. So it becomes a fairly big barrier to entry but I understand you could just say that's an operational issue and people just have to figure it out. Like my actual question is is there any, sometimes when it's just urgent and we're ready to throw anything at it is there any way to have like an NMI or a magic sysRQ to say don't do verification this system is toast. I just need to run BPF trace. So I mean, if you put the verification in the gatekeeper program right and keep it out, right? And there's nothing prohibiting you from having this magic like the secret you released to just disable everything, right? That would help a lot because it's that situation where it's like Netflix is down.   It doesn't matter. Although it does sound like an interesting opportunity for a social engineering attack. I mean, even if it is a good opportunity I'm assuming that they have an audit trail when they release that kill key. Just, I mean, like, does anybody here have a signature service running already with like strong identity and like a real fleet?  Not for BPF. Okay. Yeah, yeah. So you could, well, I mean, I know lots of people have but like usually it's quite complex set up, right?  I mean, it doesn't really involve BPF necessarily but like that's like a whole committee of work. So I think where we've landed though is that the gatekeeper processes like per team, right? And the gatekeeper processes doing the appropriate verification. I'm fine from a BPF side. I think the gatekeeper works fine. I mean, it's just more curious like if people sort of have scoped that what this signature service involves it's not a light undertaking as always. I think this is very valid, right? Once we hash out how the signatures are going to work the questions around relocation and this stuff, right? Can we do relocation in the kernel? Do we sign what Alexa proposed? We signed the BPF program, the loader program and the bytecode of the program. The actual implementation of the signature stuff it should be left to experts who already are doing that, right? Like I don't think I can, I have the requisite expertise there. What I would say is that like the reference implementation for like a signatory service, I would say it would be something like SSH Kijin's level of like a signatory service, right? Like I need this, I have the root key somewhere on disk and I need to do something with it. It is a toy. And then that's why you have all the other bigger, better implementations that will become someone's GitHub project most likely. But for it to be actually useful in the ecosystem, right? Some CA should be able to do this, right? And this you can think about the Istio CA or whatever, sort of implementing a signatory service with this stuff. But there's a lot of groundwork that needs to happen before that. I'm talking about the BPF stuff. This looks like an Istio project. You can put Istio there and then Envoy and... And CNCF look...  Cool. So I would like to echo some of your point that I think I finally get is like... It's kind of... What my point initially like correctness is... Oh, like it's totally safe, it's very difficult. Like even Firefire is the best to know that. But even that is probably not possible to be 100% sure that it's like, it's secure. But I do see the point like you have a signature service you could be able to get the trust going on or at least say I have a BPF trace. The least thing I'll do, I will log everything I do. So if you intentionally do something bad, it's log and you will be caught later. I think that's probably what we do a lot in production. I mean, it's always good to have detection after the fact, but prohibiting a problem before it can become one is even better. This is like different like BPF trace is like the extreme case too. So it's hard to prove it's always safe. It's hard to make it safe. Like the other extreme is gonna be very simple. Like just exactly that program, you know that program. That's the other end. It's more like a great signature provides the spectrum of coverage and whether it's absolutely safe or at least I know who is doing the bad thing. Yeah, I agree. I was going to answer Brandon's question there. Like the Brendan mentioned, there's an external security service which has sort of availability concerns and then in the middle of an outage when you are on the limited availability spectrum, right? You can't reach the signature service what you do. In that case, there's a thing that I'm proposing today as well, where you say that look BPF trace will be allowed to run unsigned code as long as it is in the FS variety partition, right? And then we do what you said we do, right? Like we log all the SysCalls that are being, we anyways log all the BPF SysCalls, the payloads and all that, ship all the byte code that is being done, that is being generated for like offline verification or whatever you want to do with that, right? To do more threat analysis after the fact. But it's one solution if you want to tackle, if your operational needs do demand that, which I think is a fair ask, right? Like having to talk to a BPF trace talk to a signature service might get more complicated. So I thought that I understand what's going on. And then like you said, like we still need to figure out like the real locations and all that stuff. And now I'm confused again, cause I thought that like we don't really need to figure that out cause that's signatory services problem. And like signature service is like custom implementation for each probably big customer, right? So why do we need to figure out like, who does relocations and like when they are done and like what kind of relocations? Well, what am I missing? So let's say like in this case, like you can teach your signatory service that like lead BPF is trusted partner and just take the elf as is before all the relocations before anything, just hash the elf and trust the BPF to process it correctly. What's the problem with that? Similar to BPF trace, we are saying like we trust BPF trace. I think that is a fair. All right. Yeah, I just wanted to make sure cause it's like the programs that like I use in lead BPF doing like a bunch of runtime modifications of like RO date and all the stuff. They are not going away anytime soon. So like we need to plan for that I guess as well. The only thing that we have to agree on is what the extensibility points are, right? So for example, we talked about capabilities. If you don't put those into there now it's really hard to retrofit them later, right? So which parts do you lock down right now as being the extensibility points and then you leave everything else to save? I got an impression by passing all that cause we are saying that the signature which probably would be better to call manifest cause it's like not really signature cause signature has like this hashing. But anyway, this signature slash manifest, right? That's like black box that's just passed through into like the custom BPF hook in the verifier, right? So like we don't need to agree on anything like. I think you're right. But like I think what you're saying right is like you can sign the application and trust the application which is like better than what we have now, right? Like just doing that probably adds a ton of security to the system. Well, I think what they're at trying to do is also sign the BPF programs themselves, right? Which would be like sort of, in my mind that's like at first sign the application solve that problem and then worry about the BPF program but that's fine. But at some point they have to have trusted application. So they can teach that trusted application to do this signature, right? I think all of this, right? The trust boundary for one environment, right? Where you can draw these trust boundaries is going to be very different from where you can draw these trust boundaries on another environment. I may be able to trust the BPF, right? In that case, three locations are not an issue, right? I can sign the program pre-relocation and I establish a trust boundary along for this particular use case with the kernel and plus some libraries and some tools along with that. Some cases I may not be able to trust that and we need to at least in this particular case we need to cater to all of that or at least ideate on all of these trust boundaries, right? My worry is that like if something like this is adopted by like Fedora or something they will just like, yes.  I would say that the key that's trusted should be like a writeable boot, right? Like with a fly. If you want to change the key, go for it. Like it would be like a PIM string, like decode this, right? I think it's, so say Fedora did this, right? Or some distro shipped with this, right? It's just a BPF program at boot and in it time. Like you should just be able to like delete the command line and be like, okay, now there's no BPF program, right? Like you shouldn't say like, that's why I don't think we want it as like a config flag that somebody can just turn on and then we're just stuck, right? Like your whole system stops working and there's nothing you can do and we give, you know. What if Fedora bakes this BPF program into the kernel? I think they probably can. They probably will.  Like they'll patch their kernel? The preload like skeleton, right? Like you bake it into the kernel and like it just automatically boots. It's simple like in terms of like deployment, right? So then like you can't really do anything about it. What BSE discussion, right? What prevents, like can we provide the same implementation now from ourselves? Like where we can, where we can provide a same reference implementation or this will eventually happen, right? Like. I mean, I don't see what would prohibit Fedora from doing this with like, why don't they just ship a kernel module that does this as well, right? Like they could lock it down however they want if they're shipping the kernel. By reference implementation, you mean like the reference implementation of the signature service? And who's going to implement that? Everything like the whole ecosystem, right? Like this is, these are how the signature verification is going to work in different trust boundaries. This is what we recommend. These are the goals behind the signature stuff to do. These are the goals, right? Like which we think is it's relevant for, not for gatekeeping or limiting BPF development. Honestly, like if a distribution is curtailing BPF development significantly, it's to their detriment. There is sort of a Nash equilibrium here, right? If you make the distribution less useful to somebody, the distribution will be less useful. So, and it'll be less used eventually. I also, I don't, maybe, I get the impression that some people believe and I sort of disagree. Like if you load a signed BPF program, you know that that's the BPF program that you're running, right? But you're not fundamentally changing the secure, we have lots of BPF programs. If you could write to the maps, you can totally break the system, right? So like you've kind of closed down one minor, in my viewpoint that like that's okay, so you've closed one minor security problem, but you still have all of these maps that you could DDoS, you could exfiltrate data, you could do like all sorts of things that are just, to me almost actually probably a bigger security problem than actually the actual BPF program. Because it's like a hook with a map that does an LRU filter on whatever, right? Very honestly speaking from my, the way I see it is it's all supply chain aspects, right? Like the signature service has the comp, I'm trying to call BPF helper foo, right? And the compiler is like, yeah, no I'm not gonna generate byte code for foo, I'm gonna generate byte code for bar, right? And this is, this could happen, right? Somebody could make your compiler sneak in a binary in the thing, but that thing shouldn't be allowed to sign your BPF program then. Just final remark, like I just don't want to make this, like I don't want us to design the system around the assumption that like you will be able to write like all possible, like majority of like useful BPF applications in a way that like their code will not be runtime modifiable because I don't think that's realistic, like majority of applications right now, they do some tweaking, like is it like the BPF or BPF trace generating or like you do like RO data patching before like the program is loading, like you change the code, well code or slash data logic basically, right? Like before you load. So like if you're saying like this will work as like reference implementation only for things that like you write and it's like unmodifiable, that's very limiting. Six, some use cases here, right? From my perspective that I see. You know these programs we talked about, how we talked about yesterday which are fundamentally sort of extending kernel functionality with C Group V1? We want them to be, we want to be sure that these programs are shipped and signed and verifiably built, right? Another use case is a group of BPF programs that you want to allow on the fleet. Like look, I want to deploy this when something happens and I want to be sure that those are verifiably built. In the dynamic use case we want to, we want to ensure that whatever we implement here we provide a solution for dynamic BPF code generation, right? This is very important because we understand that when you trust the application, the BPF program that ships to the application is also trustable because it has been trusted in the environment. But there are BPF programs that you sometimes are not attaching to an application currently. Like you have, you're just shipping BPF programs that I want to attach and do something with that. We do that as well. There's a question in the back. Plus one to KP, all of what you said applies in Azure as well, so same. For dynamic, so for program which do the modification, are you able to protect the chain until the program actually run? Because if you can verify the signature at the beginning and then you can protect. I believe that's only going to be possible once the dynamic location moves into the kernel. Is it or is not? It would not be possible until the dynamic relocation is into the kernel. Or some high trusted process and I believe the Microsoft case. Which is essentially I'm guessing the service account. Who's? He's not. Yes. I don't think anyone heard any of what you just said. Oh, so like, so if I can, is there a situation where we can move all of these things to the, you said this is possible with the loader program currently. Okay. We've already moved 90%, but there will be cases that it's just like not possible. There will be dynamic modifications. Like BPF traces is a prime example. Like you cannot. Sorry. So it's only through the signature service or pretty much sounds like what we'll do, like summarizing the discussion. We'll let the helper that can check signature of whatever, signature of the map, signature of the program. And a bunch of folks throughout the verifier at the beginning at the end, including that can be paired together with standard LSM hook. Like BINPRM, where it can do, let's say, IMA hash. And based on IMA digest of the, recognize that this is actually BPF traces running. And so, well, this is BPF trace is now trying to loading, connect these two events that BPF trace started to run. And BPF trace is doing BPFC's call. And at this point say, well, this is my policy. This is how I want to implement. I don't care whether anything that BPF traces loading has a signature. Just allow this process that initiates or based on the user. So it seems that the only thing, like, reasonable we can do is out, like, shooting ourselves and stopping the progress is to make it as flexible as possible, where the policy will decide anything, like, whatever combination it wants to enforce. So next steps then, right? What do we have to implement? We need the signature helper, right? We need these interesting hooks in the verifier. Yes. And that's it. And where is the signature stored? Where does it, sis call? Miner, after, no new instructions. OK. Damn it. Microphone. It would probably make sense to preserve this manifest. I like manifest more. But preserve it and, like, provide it in BPF broken for. So, like, BPF tool and, like, other tools can actually show you. Sure, yeah. But, like, the signature for me is, like, shot 256. That's signature. I'm not a security person, sorry. Any other questions on this from me? Or should we give someone else a chance to talk about signing stuff up here? Yeah, my topic is a very simple policy use case. So no signing going on there. Yeah, then you're the next one. Yeah. Thank you. I don't have a live demo, so we'll see. Thank you.


Welcome back everyone, CoasterData here, and having finally watched the annual Cedar Point Christmas video that was released way back on December 20th, 2019, I have some theories as to what could be in store for the park in the future. In closely analyzing the Cedar Point 2019 Christmas video, I noticed a few different things. First, I will address things that I think may be of little or no significance, but I still feel are worth noting in some regard. All of these things were definitely placed in the video with purpose, but maybe items meant to mislead us enthusiasts who are going to overanalyze this video, which Cedar Point is very aware of. However, these things may also have some significance all the same. As we go through the items, I will discuss things that I believe may have more weight to them. The first thing I noticed was at the 2 minute 13 second mark. I want to point out that there is a Snake River Falls boat being used for that particular number. Admittedly, I don't really have any compelling evidence toward this being anything significant, but I've thought for quite some time that Snake River Falls will not be around for much longer. The fact that they have a boat removed from the ride and displayed prominently in the video gets me thinking about what they are going to do with Snake River Falls in the next few years. I know the boats are always removed during the off season, which is why I'm presenting this as something purely anecdotal and not really supported by anything otherwise. This could mean something, or it may just be completely coincidental and me looking way too much into the video. The next item in question can be found at the 22 second mark. If you look here, there is a skeleton adorned with a Cedar Point Crew shirt, but this skeleton is also wearing a Kings Island Winterfest hat. While there are some Christmas ornaments adorning the Large Hollowicans Monster Prop as well. I mention this because there have been some rumors swirling about Cedar Point announcing their very own Winterfest for 2020. And though this has been largely debated among enthusiasts, it is still unclear as to whether this could be something worth pursuing for the park or very feasible given the harsh winters of Northern Ohio on Lake Erie and the way the park is accessed via the cause way. I am still pretty skeptical about this myself. While I love the idea of having a Winterfest so close to home, I feel like this may be a bit too much for Cedar Point. They surely wouldn't be able to run any of the coasters or major rides for this event I believe due to weather. More on that later though, as the next thing I will discuss, which also ties into the Kings Island Winterfest hat, is found 1 minute and 28 seconds into the video. Allow me to explain. Here, you will see a paper sign near the bottom left of the video attached to a barrel. The graphic on this paper shows a bear wearing a Santa Claus hat with the words, we wish you a berry Christmas and plain view. This barrel is also filled with huge Christmas ornaments. This, to me, also hints very clearly towards some type of holiday themed event. If you are not aware, a couple months back, a sort of new dark ride was announced for Nottsbury Farm. This ride is called Nottsbury Tales, a reimagining of a classic Nottsdark ride of the same name. This paper in the Cedar Point video actually uses the logo from the new Nottsbury Tales ride. In both the Nottsbury Tales ride logo and the Cedar Point video, you will see the same bear, but the bear in the Cedar Point video has a Santa hat. I don't know if this graphic in the Cedar Point video has been used at all around the park at Notts, but Nottsbury Farm is another Cedar Fair park that also has their very own Christmas event, which is dubbed Nottsmary Farm. In addition to reusing the ride logo, the graphic in the Cedar Point video also uses the same exact typeface as the Nottsbury Tales logo. What are your thoughts about Winterfest at Cedar Point? I am very much on the fence about this. On one hand, it seems it would be too much to take on in the harsh winters of Northern Ohio, but on the flip side, Canada's Wonderland has Winterfest as of 2019, which has seen tremendous success. Canada has very harsh winters themselves, in fact, even more so than Ohio, and it still seems they were able to pull it off. Canada's Wonderland even has a bit of a shorter regular season than a park like Cedar Point. I previously thought that Winterfest coming to Cedar Point was highly unlikely, especially seeing as Cedar Point tried a holiday in the park type event way back in 1994, and it was the only time they ever did this as it flopped. But that was over 25 years ago, and I believe the offerings would be much better, and it would be much more of an immersive holiday themed event if it were done in the current day 2020 with the current management. Moving on to the final piece, and what I believe is definitely the most significant component to this video, is what we are shown at the 1 minute 37 second mark. Here, there is a large photo displayed on a computer monitor with a confidential label reading Top Secret 2021 Plans. Why is this so significant? Well, let's travel back to 2016 for that year's Christmas video. In that one, we were shown a similar item on a computer monitor as well, which reads Classified Document 2018 Capital Plan Enclosed with the subtext prepared by Richard Michael Crosby. Richard Michael Crosby is probably a very familiar sounding name to many of you, as this was used in other instances to tease the announcement of RMC Mean Streak, which would come in 2017, now known as Steel Vengeance obviously, and uses the same acronym, RMC as Rocky Mountain Construction. Now, I believe that 2019's video is much less clear as to what exactly will be coming in the future. Many enthusiasts, myself included, believe that 2021 is when Cedar Point is likely going to receive their next roller coaster. So the fact that the park is teasing us with a very similar tactic would suggest that this is in fact the case. With the hint given in the 2019 video, there is a seagull displayed right next to the 2021 Plans text. I've seen other people suggest that this could mean there is a roller coaster coming to the park in 2021 that will break the 500 foot barrier, and even suggested that many birds fly around the 500 foot altitude. However, in my research, I failed to find any type of bird that typically would fly around this height barrier, and in fact, found that most birds fly below 500 feet in normal circumstances, per a Stanford University essay, which I will link in the description for you to analyze. So, what could this really mean? Well, personally, I believe we are pretty far off yet from a roller coaster that will break the 500 foot barrier. Maybe the inclusion of the seagull is indicating that to us? I think that would be much more likely. Whenever Cedar Point has teased a 500 foot coaster, it has been very blatant, and in my opinion, meant to obviously mislead and poke fun. I found a number online in an article by Mount Desert Islander, also linked in the description, that indicated the highest recorded flight altitude for a seagull is actually 124 feet, so maybe we were looking at something more along the lines of a medium altitude roller coaster, which would make a lot more sense to me. And actually, to spin off from that a bit, I've heard a lot of murmurings recently about Gemini possibly closing after the 2020 season. Gemini stands at 125 feet tall, only 1 foot higher than the 124 foot seagull altitude figure which I came across. So I think that maybe this video is hinting at the potential closure of Gemini and a new roller coaster taking its place, which does not reach 500 feet in height. Obviously, this is all speculation, and maybe Gemini is safe this year, but I do believe that Gemini will not be around for a whole lot longer, and this would support what many people have been speculating in the past year. Maybe the potential 2021 coaster will also be around the 124 foot mark or even smaller. I wouldn't be surprised to see Cedar Point adding a more modern style of family coaster, which I think they could use for their lineup. The current family coasters they have are pretty outdated, and I think we'll be biting the dust in the next 5 to 10 years. So something like a smaller scale GCI or a Gerstlauer family coaster may actually make sense, especially since Cedar Point has not had any type of family coaster added for a very long time, only massive thrilling steel coasters. Since Cedar Fair is obviously trying to focus more on the greater family experience rather than humongous record-breaking coasters now, I believe a modern family coaster would make a lot of sense for the park. Now I am not 100% sold on the idea of a family coaster being the next major addition, and I will be making an updated video soon discussing possibilities for what Cedar Point may add as their next coaster. But from my perspective, this would make sense, and is even something they could really use. The only coaster addition in the past 30 years that you could even begin to argue as a family coaster is 1999 with Woodstock Express, but even that is a kitty coaster, and doesn't satisfy a wide audience. I'm talking a true family coaster that many people can experience and be thrilled while not being overwhelmed by excessive forces. If you are still watching, thanks for sticking around and listening to my thoughts. I know that there is a lot of information to take in here, but I really wanted to get a lot of this stuff out there in order to facilitate a wider discussion. What are your thoughts about the information I presented and what is shown in the Cedar Point 2019 annual Christmas video? Obviously, none of my theories are factual in any way, but mere speculation based on things we've heard in the past, combined with hints given in the official Cedar Point video. Be sure to let me know your opinions in the comments, as well as subscribing for further content on roller coasters and amusement parks, as well as liking my page Coaster Daddy on Facebook and following me at Coaster Daddy Official on Instagram. Thank you all so much again. This is Coaster Daddy. Bye.


My fellow Americans, two days ago I visited with some wonderful neighbors of ours, the people who live on the island of Grenada in the Caribbean. I wish every American could have seen the joy in their faces. I couldn't help remembering that just a short time ago they were living in fear of forever losing their freedom. For years trouble had been brewing in Grenada. Power was seized by a radical group with close ties to the communist world. They kept insisting that they had no intention of stamping out their people's fundamental rights, the right to speak or to worship God, no intention of imposing a so-called dictatorship of the proletariat. We were told that those holding power in Grenada were simply idealists charting a new and better course for the future. All of this was part of a communist pattern of deception that has been repeated so many times in so many places. This time, however, tons of captured documents exposed these lies. Today, for example, we know that no one had to push the clique that seized power in Grenada into the arms of the Soviet Union and Cuba. From the very start, they aligned themselves with the international communist movement and, once in power, moved quickly to undermine the freedom of the Grenadian people. Their plan almost worked, but then some who were in on the scheme balked when the heavy hand of repression was about to come down. The brutal killings that followed were similar to the fratricidal bloodletting among Marxist Leninists in Afghanistan, South Yemen, and even among the Salvadoran guerrillas. Sadly, in Grenada, just like elsewhere, many innocent people were also victims. I vividly remember that morning when I was awakened in the early hours and told that we'd received an urgent call for help from the Organization of Eastern Caribbean States along with Jamaica and Barbados. These neighboring democracies asked us to join them in restoring order and freedom to Grenada. There were some 800 American students and about 200 other American citizens on the island. All were in peril. So on October 25th, American military units began Operation Urgent Fury. Within a short time, our citizens were safe and the people of Grenada had been liberated from the grip of tyranny. Some of our young medical students kissed the ground when they got back home and our servicemen were hailed as saviors by the local population in Grenada. The communists didn't succeed in Grenada, yet a similar chain of events had been happening in Nicaragua. We hear the same old lies while the Nicaraguan people see their freedom being stolen away. The communists have suppressed free speech and free press. These communist dictators have launched a systematic attack against the church, its priests and bishops, and government-instigated mobs mocked as holiness John Paul II. Meanwhile, the dictatorship is being armed to the teeth with Soviet military equipment and everyone from the Soviets, Cubans, East Germans to the PLO and Gaddafi's Libyans are turning Nicaragua into a staging area for subversion and aggression against their and our neighbors. But there's hope for the Nicaraguan people because freedom fighters are now struggling against the communist dictatorship. Their ranks are filled with campesinos, small farmers who own a few acres of land. Many of them fought against past dictatorships. All they want is to be free and to live under democratic government. Helping those fighting for their own freedom in Nicaragua is both morally right and vital to our national security. If the communists consolidate their power, their campaign of violence throughout Central America will go into high gear, bringing new dangers and sending hundreds of thousands of refugees streaming toward our 2,000-mile-long southern border. We cannot and we must not permit this to happen. We should learn the lesson of Grenada. My meeting with nine Caribbean leaders there showed me that they certainly have. One Caribbean prime minister summing up the discussion said, sometimes we wish we were a little closer to Central America so that we could give you more support. You're on the right course in Central America, he said, and we're begging you not to give in and allow any more communist beachheads to be established in this hemisphere. Nineteen American servicemen lost their lives and many more were wounded liberating Grenada. If we have the courage to do what is necessary now, helping those who are struggling to bring freedom to their country, the Nicaraguan people will be able to liberate themselves. They don't want our troops, just our aid.  Let's make certain we all live up to our responsibility. Until next week, thanks for listening and God bless you. I can hear you scratching the door. Get your overcoat on Rex. Yeah. You're scratching the door. Yes. Yes. No. No. No. That'll liven things up a bit. Because you know. That's this one smart fella. Who's that? Who's that? Who's this one? He knows. He knows. There were a dozen military representing each of the four branches. Each of the four branches that invaded Grenada. All the veterans of that battle were medal winners. Is that right? One young man, still a Marine, showed me. He's still partly crippled. He was in a helicopter. The two of them came in. His helicopter was shot down. He was critically wounded. And he gave his sidearm to the co-pilot and told him to take off. And then exposed himself to where the fire was coming from so they wouldn't notice the co-pilot. Was it? You're different. So the other dogs and the animals and the wide-open range. No adjustment at all. What do you want? Four other dogs doing their own way. Yeah, I know. Bye. It seems you're putting on even your clothes and things it means outdoors. I'm coming. I'm coming. Okay. Bye. Bye. Bye.


Hey Psych2Goers, welcome back to another video. Before we begin, we would like to thank you for your everlasting support. Our mission is to help you gain deeper insights into yourself and others in a fun and engaging way. We hope we've been able to help you in your times of need. Now, let's begin.  Not knowing how to deal with your emotions can lead to them becoming more intense, persistent, and problematic. While it may grant you some temporary relief, suppressing your feelings and being in denial about them may only lead to painful consequences that keep you disconnected from yourself and from those around you. So, here are 7 signs you may be suppressing your emotions. 1.  You get annoyed or upset when people ask about your feelings? Are you quick to brush off any concerns other people might have about you because you don't think it's any of their business? Maybe you're not comfortable opening up to others or dislike getting overly sentimental or touchy-feely. It may be a sign that you're emotionally repressed when you constantly avoid any and all conversations about your feelings. 2. You struggle with emotional intimacy. You have problems finding a friend to confide in or have trouble making a meaningful relationship last. This may be because you struggle with emotional intimacy. This being emotionally intimate with someone forces you to be vulnerable and to confront your true feelings. You may end up running away or getting defensive and struggle to emotionally connect with them. 3. You're always just fine. Do you have a habit of saying you're fine every time someone asks how you are? You may reassure your friends and family that everything is great and that you're doing really well when you don't mean any of it. You don't feel comfortable admitting when you're not okay or to let people see you struggle. Instead of asking for help or to confront your feelings, you just repress your emotions and bottle them up. 4. You rarely get emotional. Do people describe you as withdrawn, indifferent, or detached? You don't cry or get upset and you rarely ever get excited about anything. Not only do you dislike talking about your feelings, but you'd also rather not show anyone that you have any at all. You may have been badly hurt in the past and you don't want to feel overwhelmed by your emotions again, so you resolve to just close yourself off and not feel anything at all. 5. You have extreme mood swings.  Extreme mood swings and emotional volatility are clear signs that you're repressing very strong emotions. Instead of resolving them in a healthy way, you may be pushing them down and acting as if they're not there. But your emotions will come out in a much more problematic manner where you take all of your negativity out on yourself or those around you. 6. You deny all of your problems. You avoid your loved ones when they're mad at you or agree to things you don't want to do to make other people happy. This is a very common coping mechanism, since you may feel like it's much easier to pretend that your problems don't exist than to find a solution. This difficulty admitting to yourself when something is wrong could be a sign of a much more serious underlying problem. 7. You hold grudges against people. Do you have problems letting your feelings of anger and disappointment go? Harboring grudges against people and being vindictive is a very telling sign that you're holding back on your emotions. You may be having a hard time forgiving others because you can't come to terms with all the pain that they may have caused you, even if it was unintentional. But holding onto grudges only shows that you're not prepared to deal with your emotions and that you'd rather let them linger over time. Did you relate to any of these signs mentioned here? I know I did. Are you worried you might be emotionally repressed? Tell us about it in the comments below. If you enjoyed this video, please give us a thumbs up and share it with others who may find it helpful too. Don't forget to hit the subscribe button for more Psych2Go videos. All the references used are also added in the description box below. Thanks for watching and we'll see you soon.


Ya niya mazatu isfiki in tanze, niye tukwata usfiki in tanze the entire show and the little chakwe delema to wachiyama Tendere na intervim tanze tendere na tukiyen hao Alright I'm getting voice in iwa fanyikana sauti I think mande diyo tunapu muzikanga sauti panoa tutuna imbasa na matuna ubiri nage misazafu mande yungu ni kapatikana but I'm so blessed to be here so happy to have you we are so really humbled actually honoured to have you Abatu mezaia to male pastors male pastors today Watan eleo dilei day eleo dilei to go ah, afimu pasteran we are so honoured to have you alafutu me kutua leo resti diyako so it means a lot to us ok, let us just catch up with you paster let me just give you the opportunities we can introduce yourself right there at camera one amen my name is Anita Flo but my official name is Florence Mina and I am serving under Paster Timwangi in Lifechart Lemuru I am born again I'm preaching when I'm born again I'm a gospel artist I'm a servant of God and I am a business lady I thank a lot for being here today amen so many things but I'm so interested in that part of you being a pastor and you being a minister, worship leader you say life church right now what are you going to do? we are going to perform I've been with my kids I've been with school I've been in prison worship even in my youth life I believe I was born as a youth but I think I've been singing all my life na jipatangatu yulam singing then with the time watu na kwa mpia manzoku talented but nikiendele atu na jani ya kwa ima I discovered that I'm more than a singer I'm a minister of the gospel and so just juice it to like from 2 years ago doni me kwa pastor and the journey is interesting so far with God How was the calling for you? for you being a pastor I don't can be scary especially you being a female when I say my pastors they usually have a very big challenge on them but he was a female pastor how is it for you? mine has been I can't say I've been having any challenges I think I've been serving with very supportive men and for this matter in my church we are serving 10 male pastors and one female that is me I found myself in that council and I wasn't sure if I'm going to go to Kupu one day nikiendele kwa pastor he said my pastor needs boys he needs boys infact in this time I know there's a pastor who wants to join he wants to be a pastor and adapt to her life because I've been previously taking her to maybe lunch she wants to have boys by the time she comes to the 2nd one there's no one so I think I'll adapt to her life and I'll have juice and I'll have a half of her mama so I found myself in that council and I know there's boys so it has been interesting I'm learning every day I'm learning from other servants of God and every day has been a day of learning so far so good by the grace of God the grace of God is enampling me to do what I'm doing and for being where I am today two sides in mind glory to God that is so nice taking off the talents and the gifts in you and just pursuing them he's on zikizako music this one time I think this is the first time I saw you I think it was even my first time to enter that church to fellowship in that church and the first person I went to and he came up to me and I was like wow that voice that voice my goodness you have such a powerful voice and you've written such powerful songs as well and how is your writing process for you I am God you are blessed that day that you came somebody was telling us just the other day in the exchange conference that sometimes you don't know what you have until people you hear people telling you that hey manzei Miriam you're talented and you're like I thought I am a presenter like any other what you don't know what you have I love when I go to a farm when I go to a confidant of what God has given you you have asked about my writing music I started writing my music in 2017 that is when I wrote Musio Gopi the one that we first listened to and Musio Gopi was I wrote Musio Gopi in a season of fasting and I was in a prayer center and actually something I've never even shared with pastor T he came I was living in Nakuru for like four years I was working in Nakuru and one day he came to Nakuru he came to another church that is in Pipeline and we came with my bogey prison worship we were following pastor T wherever he's going and he was ministering in that church and he started calling people with a prophetic word so I went, dropped my offering it was a time of giving offering and he could see you and tell you something and at that moment he called me and what he told me he told me are you a worshipper I said yes do you write music I said no and he told me one of the things that God is going to do in your life you will be writing your songs in a prayer closet I didn't understand that but until I was in a prayer center and a song, actually a tune dropped in my spirit but I was reading the book of John so I could read a word and became so remember to me that I was writing in a song so I was finding myself the tune that I received I am putting those words the lyrics are coming actually the whole of that song it is from the book of John John 14 in Asema Kuhusu Holy Ghost in Asema you were not left as orphans the whole of that song I wrote in a prayer center and I was writing that song that is when I remember what pastor T told me so before I write I find myself writing songs when I'm in a mood of prayer so I can say it has been by the grace of God that I find my songs when I'm in a mood of prayer or to the glory of God amen and I can tell the song has done so well up on YouTube ki angale apale YouTube it has done so well because you've received so well even with you releasing your music now now you're just coming out and now doing music releasing it out there how do you think people have received your music besides you being a pastor now wow actually one of the things that are really encouraged me in my music journey is when a person calls you and tells you I was going through this and this I was suffering from this and this but your song kept ringing in my mind and it brought it brought so much encouragement let me just give a testimony of a lady who was in Thailand I think she was going through a season that was very tough she's in a foreign land things are not working out for her and God just directed her to listen to my music and she called me crying she was telling me oh my God floor I was listening to your music and I was so edified I'm so encouraged that you have not prayed to me you have not prayed for me but just by listening to your music it was on repeat mode it encouraged you know it encouraged someone it ministered to someone and that just means a lot to me that maybe not so many people have listened to my music but they feel that I've listened to my music and I think I minister to them I'm just so fulfilled and I'm just so satisfied that God can use me to minister to His people through a song yes I think you have to listen to what I'm saying focus on what you want but focus on the message and we really blessed a lot that the message is really transforming people across the world and that is so amazing maybe someone is watching really connecting with your message connecting with your song and they would love to listen to more of your song if you can just share your YouTube channel and you can share your social media handles my songs are on YouTube Anita Flo I have other songs that we have not sung today you can check on my YouTube channel Anita Flo Facebook Instagram Anita Flo Kenya Anita Flo everywhere I am there you will find me there give me a challenge give me a chance to collaborate if you are giving a chance if you are giving a chance oh my God Doctor Sarah Kay Doctor Sarah Kay if you are watching us this day collaborate with me please come back to me come back to me if you want to share the word today be sharing inspiration what Easter means to you what Easter means to us be sharing that later on before releasing you any shout outs any shout outs today Salam Salam my parents are tuned in they are from Muranga my sisters are tuned in from Rai 44 and my family from Lifechart International they are watching me and they say that I should say hi to them if you want to say hi to them please come back to me if you want to say hi to them please come back to me if you want to say hi to them I love you so much and thank you for tuning in I want to say hi to them but I really want to officially say hi to them he ensure that this happens bless you come later on to share the word but right now we will be sharing the word there is a french song that is called wumunene wumunene kujakwa microphone wumunene wumunene which means he is a great god he is great god alright


The study predicts that esophageal cancer, EC, prevalence, disability-adjusted life-years, dailies, and direct medical expenditure will increase in China from 2013 to 2030, with males experiencing a higher burden than females. The study highlights the need for policies to reduce the EC burden, as years of life lost account for over 90% of dailies. This article was authored by Yuan Yuanli, Zhu and Feng Siu, Yuxuan Gu and others.