Today, I am very excited to be ranking over 100 Nintendo Switch games from the absolute best to the, well, the absolute worst. I am on tiermaker.com and they actually, someone has already pre-made this for me. They have a very great selection of Nintendo Switch games, over 100 games here that I will be ranking all the way from SSS tier, the best, the cream of the crop on Nintendo Switch, all the way down to FFF tier, the absolute worst. And if you watch this channel regularly, you can probably already expect what's gonna be down there. Now, to the credit of whoever made this list, you did a great job, but there is a bunch missing and I've pulled those over into my photoshop here and at the end, I'm gonna throw those on the list as well. So if I end up missing one because of that, it's not my fault. Today's video is not sponsored by anyone, thank goodness, so I do want to thank my Patreon so I don't get to thank enough and I want to really quickly sponsor myself by mentioning something that I haven't mentioned in like a year. I have merch, I'm sure like none of you know that. Up on PixelEmpire.com, I have had beat em ups mugs and beat em ups shirts. We've got a Mario Odyssey version of me on a shirt, a beat em ups Mega Man version. Personal favorite, it's just my logo on this nice green warm comfortable sweater. Green, it's great. Anyway, if you want to buy some of my merch, I'll leave a link down below. Okay, well I think we should definitely get the obvious ones out of the way first and put Breath of the Wild and Mario Odyssey in the SSS tier because they are the absolute best Nintendo Switch games. They are untouchable. Like, I don't think, I mean, I'm not sure, I haven't gone through all of these yet, but I don't think we're gonna be adding anything else to SSS. And I'm looking for 1-2 Switch to add that to the lowest of the lowest tier, but I don't see that on here either. So we're gonna have to 1-2 Switch. Okay, let me add this really quick. Yeah, we'll work our way back around to that later. Dragon Quest Builders is absolutely an S tier game. Fell in love with that game on the Switch. It was the first game that made me do a video called I Am Addicted to This Switch Game. Pokemon Let's Go Eevee. I would say that's a A plus. I love that I can't see Let's Go Pikachu on here. I was gonna do a Donkey and put it down an F tier. Alright, I don't wanna pick and choose. I'm just gonna work my way down from the start. Hyrule Warriors. Yeah, that's like a B. It's nothing amazing. Oh, Smash! How did I forget about Smash? Yeah, that's a SSS. Damn, well, I mean, I was wrong looking at that. Oh, Stardew Valley is another S up there with Dragon Quest Builders. It's just one of them games that's dangerous to have portably because you can sink so much time into it. Um, World of Final Fantasy? I mean, yeah, that's fine. I mean, it's a good game. Adventure Powers. A lot of these that they put on this list are so random. Like, I can't believe they forgot Super Mario Party, but Adventure Powers is here. I mean, that's... It's not a bad game. It's like C and then same with that is C. Arms! Arms! Arms! Uh, it's not as bad as 1, 2, Switch. Like, just imagine 1, 2, Switch is in triple F right now, but Arms is... Okay, it's not that bad. It's a D. It's not that bad. Astro Bears is pretty good. I can't put it in B. It's a great game that's worth the five bucks, but I can't put it in the same tier as World of Final Fantasy. Axiom Verge is pretty good too. Um, put it in C. This is where I say these are just my opinions, by the way. Feel free to leave yours in the comment section or even make your own video. Actually, I looked up... I'll do it again. Nintendo Switch tier lists. I didn't see a channel called NintendTalk ranking every Nintendo Switch game. There's no way he did every one in 15 minutes. Oh, you did the exclusives. Okay, let's... come on. I'm doing 100. Pick up your game. It's not every. Oh, Jams did one. He did exclusives as well. So, I mean, there was a couple out there, but I was surprised that no one else did this. Battle Chaser's Night War is pretty good. I feel like I've dug myself into a hole here. I kind of want something between B and C. Oh, I can! What do I... What do I not quite be but death not see list? Um, I will move these up into there because I feel like... Yeah, I feel like that's better. I didn't know I could do that. Battle Chef Brigade, that's an A, in my opinion. I love that game. Bayonetta 2 is also an A. Bayonetta 1 is also an A. Actually, I feel like they're even an A plus for me. Blast of Master Zero. Now look, Blast of Master Zero in its own right. I probably put it up here in the not quite B, death not C, but just because that game released on the eShop and 3DS really early on in the Nintendo Switch's lifespan and played a huge key role in making the Indies what they are now on the Switch. Just for that, it's going to get one extra tier boost. Blast of Blue. Yeah, that's pretty good. It's a really good fighter. Let's go with B. Oh! And if any of you live in or near or around Houston, Texas, I'm going to be there this Saturday at Retro Palooza, Houston. It's going to be a great time. Please come and say hi. I haven't played Bleed. I actually have never heard of Bleed. I don't feel qualified to talk about Bleed, so we're going to put Bleed down here. Castlevania Blood Moon, that my friends is an A. That game is great. Blossom Tales is another B. Brawl Out, 8-0 Smash, gets a C. Celeste is up in triple. Double S, double S. I'm sorry. I'm sorry to excite all of you. That's up in double S. The Crash Port is pretty good. Oh, Crypt of the Neckroy Dancer is really good. I'm probably going to give that an A. I'll give it an A. Dark Souls is a fantastic port, actually. It looks great. It plays great. I'm not a huge fan of the game, but it's a quality port and it's a good game. It's just not my cup of tea. Darkest Dungeon is a really good indie game, actually. Dead Cells is also a double S. That was another game that I was very addicted to.  I downloaded it and I'm very excited to check it out. I haven't got around to it yet. I haven't played that one. Don't Starve is pretty good. Donkey Kong is overpriced. So whatever tier I'm going to give it, I'm knocking it down a tier just for that. It is a port of a Wii U game that all they did was add in one character that essentially ended up just becoming an easy mode. I love Nintendo, but this whole Nintendo Switch tax thing that bumps you down a tier regardless. Having said that, it is, in my opinion, the best Donkey Kong game ever made.  So that's an S tier. Except Switch tax, pushes you down to A+. So close to the S Nintendo, maybe if you just remove that Switch tax you'd be doing better on this tier list right now. Doomport shattered expectations of what was possible on the Switch. Also, I just love Panic Button and I love that game. So, do I give it an S though? No, I'm going to give it an A. But it's great. I was ecstatic when Dragon Ball FighterZ came to Switch. That's also an A. Another stellar port of a fantastic game. Earth Wars for $5 is a absolute steal on the Switch. Oh, Enter the Gungeon is an S for me. That's another one that I don't think I did a video about how I was addicted to it, but I was. For a while, that is all I played on my Switch. Great game. Fire Emblem Warriors, I have to rank at the same level as Hyrule Warriors. Flint Hook is another really, really fantastic indie game. It's not quite up there with the A, the A list indie games. It's on the B list as well. Golf Story is still, I think, the only exclusive indie game on the system until I guess Cadence of Hyrule comes out. So for that fact alone, it gets boost up one tier and I would honestly put it, I think in, oh, in I would put it in A plus. So I think, but by my logic that boosts it to an S. Hollow Knight. Oh, there we go. Throwing up there in the double S. The triple S tier that I have might only be one step above, but we only have three games in that right now and one tier below in the double S. All three of those are indie games. I mean, that really says something not only about the quality of indie games nowadays, but also just the dominance of them on the Switch. Haven't played that one. Throw it down there. Hyper Light Drifter is fantastic. That gets an A plus. IM Setsuna is fantastic. It would get an A plus, but because it never got a physical here in America or anywhere outside of Japan, I'm just annoyed at it and I'm giving it an A. Iconoclast is another great game. I'm gonna give it an A or B. I'm gonna give it an A. Enter the Breach is an A. Oh, and Kumiko is getting the same treatment as Blaster Master Zero. Whatever I would rank it, I'm gonna boost it up one because that $5 indie game, again really early in the Switch's lifespan, I would probably give it a B on a normal day. It's a great game again. It's just five bucks. It's a budget game, but I'm gonna give it an A. Is that above Blaster Master Zero now? Wow, it is. No, we can't have that. It's a B. Kirby, again, oh man, this is a tier just for being so overpriced. That game was like five or six hours long at best. Yeah, I don't know. I didn't love Kirby, man. I really didn't. I'm sorry. I'd probably give it a B and then with my Switch tax rule, it's not quite B, definitely not C. Actually, that sounds right to me. This might be controversial because I don't think it's a love or hate situation. I think it's either you appreciate and like Mario and Rabbits or it's not your thing and you acknowledge that. For me, I really liked it. I would go as far as to say I loved it and I would easily give that an A plus. Oh, not S. A plus. Mario Kart 8 is up there with those three Indies in SS. I know it was full price again, but there's just so much content in that game and it did release with all its DLC packs. The best Mario Kart. I can't help but put that in SS. Mario Tennis Aces was incredible for a tennis game, so I'm gonna give it an A. Moonlighter. I have to put that up there in S. Almost a double S. If there wasn't in between I would possibly consider putting it there. Now I'm seeing Dragon Quest builders here. The way that I've seen this list come together, I kind of want to move this bad boy up here. Oh, there kind of needs to be an in between, but I'll leave it. Octopus Traveler. Um, I'll give it an S. I love that game. I think that game is fantastic. Just visually, it's gorgeous. Gameplay wise, I absolutely love the term based RPG. Story, was okay and did get pretty repetitive, but it's an S. Okami I gotta give an A plus too. That game is beautiful. One strike, again for its price. Overcooked is great. The second one is better. Owl Boy is also really good. Pac-Man I haven't played. That I haven't played. That I haven't played. That I haven't played. Wow, that was a lot in a row I haven't played. Pokken tournament loses a point for Switch Tax. I don't think I would give it a B. I think it's better than a B. It's kind of in between A and B, but I'll put it in A so I don't upset too many people. Skyrim was a fantastic port. I'll give that an A. Sly Sam is okay. Snake Pass. Um, honestly that's probably a B not quite a C, but it does get that extra boost point that Kamiko and Blaster Master Zero got. Snipperclips, I never like Snipperclips. Oh, Sonic Mania though. That one is absolutely in A plus. I thought about putting it in A. Oh, yeah, it's in A plus. Oh wow, this is exhausting. I've gone through a lot of these. Splatoon is an aaaaaaaaaaaaaaa double S. Bomberman I hated. I did not like Bomberman. Messenger is another I'll give it an A plus but I'm sure a lot of people would put that in S. Maybe even double S and I wouldn't blame you. It's a fantastic game. Uh, that I'll give an A that was a really great game. Zero Drifter was pretty good for the price um, but it's really budget so C, uh, Yooka-Laylee I will give you already leaving the comment. Admit it, are you already leaving the comment? Uh, Yooka-Laylee, it didn't live up to my expectations. Um, Xenoblade isn't really there. I'm just trolling um, it's definitely not there with 1, 2 switch and inevitably WWE 2K18 I have said a billion times that while I didn't enjoy the game I never thought it was a bad game. I would honestly, I would honestly put it middle of the pack. I would put it in there with Hyrule War. Nah, maybe even I can't give it an A. I would take the argument if you actually enjoyed the game that it could be anywhere between B and S. Honestly, like just because I didn't enjoy it doesn't mean I don't see its quality. I would give it a B. I am noticing that the Torna, whatever it was called, I've already forgotten isn't here. I would put Torna or an A. So just imagine that to there. Um, but I will give, I will give it a B. I'm sure that won't make any of you feel any better but, now Yize now that's a game. That's a game worth putting in, uh, A plus. I really liked Yize. I thought Yize was great. Okay, uh, that's all of them. We've looped around to the ones I haven't played. So I'm going to screenshot that. I'm going to bring it over here into my Photoshop file. These ones are, ones they forgot, as I said, like Mario Party and Mario Brothers U, but also games that I've just taken a look at on my channel over the last couple of years. My writing stables. That is a F tier game. That game is one of the worst. Oh, and we're also missing. How did I forget about this? What, what, what was it called? Arc, yeah that's what it was. That is absolutely an F tier game. That game ran so poorly on Switch. Like, that, it's not a reflection on the game, guys. A lot of comments I got on that video was, you, you haven't played it on PC. It's really fun. You don't know what you're talking about. I'm sure the game is fantastic. However, I have been told otherwise. I'm sure the game is just fine. It just ran so bad on the Switch. Like WWE 2K18 still, even now, even after they patched it and they fixed it and they did nothing to change it. It's just, it's unplayable. It's literally unplayable. Yeah, second only to that game is Arc, Survival Evolved. Like, that game is almost unplayable. Payday 2 is an F. Um, it's not a horrible port to the system. In fact, I was really excited for it when I heard it was coming to Switch. But the port to Switch was like full-price $60. It received no support. It was a very ugly looking game. And it, like, year or two later into its release, it didn't even get a price drop. It stayed at $60, even with the poor sales, with a dead online and with no support. The world ends with you is an incredible game. A game that's up there in, I would say, S tier. Um, but purely just for the terrible controls. The absolutely awful controls that literally gave me arthritis. What's it down into B? Yeah, I'm gonna put it down into B. Uh, Starlink Battle for Atlantis, I'm surprised that wasn't on the tier list that this guy made. That gets boosted up tiers just by having Starfox in the Switch version. And also by being the only version of the game that actually made any money and any sales whatsoever. So, I'm gonna give it an A plus. Eh. I can't. It's not an A plus game. It's an A game. It's a good game though. Listen to me when I say these words. I'm not really ranking Fortnite itself on this one. However, I did really enjoy the game for quite a few months. But it is a good game. It really is. Um, and it, I had good memories playing with Sean. But just because it's free and you don't have to spend any money on it whatsoever. It was a really healthy and good move for Nintendo to put that on the Switch. I'm gonna give it an A. And I know that's gonna be controversial because it took Bob Zeno Blade. I just put Fortnite above Zeno Blade. Oh, please don't unsub.  Cuphead was just, it took me so much by surprise. And again, I have great memories of playing that game with Kim. So that's an S. Troll and I isn't as bad as the other games on the list. Mario Bros. U Deluxe. It gets knocked down one by having Switch tax. So it gets knocked down another one just for being boring. So that's two. And it gets knocked down a third tier because it's not Super Mario World 3D, which was the actual good Mario Bros. game on the Wii U that wasn't ported for some reason. So usually just because of how boring it is, I'd probably give it a B. But I'm gonna go ahead and give it a C because it's not, it's not good. Uh, Mario Party Okay, listen. I'll give it an A because it made great improvements over 9 and 10. However it only had four boards and they were so insanely uninspired and boring. They were literally just grid based boards. On top of that the online, you couldn't play the board game, you couldn't play the actual Mario Party part of the board game part of the game online with your friends. You could only play the minigames and then you could only play a selection of the minigames. And so many other people complained about it as well and Nintendo didn't fix a damn thing. So B, not quite C, you're rolling it Nintendo, you messed up your own game I'm sorry. Let's do one two switch Let's do one two switch. Why am I not grabbing it? Where is it? One two switch is double, triple F. I don't feel the need to even explain that one that game is horrendous. I wanted to add Toad because Kim loves this one. I, I would honestly put it around here but just because it was just nice to watch Kim play a switch and have a lot of fun with Toad, I'm just gonna give it an A. I have nice memories of that game just watching Kim play that game.  I reviewed this game recently on the channel, actually it's probably one of my favorite videos on the channel. I actually went out and not only rode an actual horse but groomed and took care of a horse just to see how realistic the experience was and guess what? Very realistic. And usually I would give the game a B maybe not quite a C but just because of how realistic it was, an open world game with extremely likeable characters that could barely talk English, I'm gonna have to give it an S. It's up there with Oped and Octopoth Traveler and I am not sorry. Now listen, this is just my opinion yours is of course going to be completely different especially with this many games but it is a pretty good approximation to my opinion on a lot of switch games. I did honestly have a lot of fun making this video and I hope you had a lot of fun watching it. If you did, make sure you smash like on it and share it with your friends so that we can all be on the same page with best and worst switch games. Check that link down below for my shirts and merch and stuff. Hey so I've been writing a new song, you want to hear it? I don't have a good way to end this video.


Well, so I feel very strange because I woke up at 3.30 this morning to go from countryside of France to here, so I really feel jet lagged. So I hope you don't feel the same, and at least I'll be able to be on time. So please help me, because I tend to be a little bit chatty. For those who do not know, Linaro is the arm ecosystem collaboration. So we have companies like Google, Facebook, Alibaba, Red Hat, Cisco, Ericsson, Huawei, Nokia, Kavium, NXP, TI, ST, well, I stop. So many of those companies are either building silicon or building systems on top of that. And we collaborate inside Linaro to produce things and to push technology in many different communities. And out of the members, there was a request to have a technology to sustain time-sensitive networking. We tried to do it with the kernel, with 500 MHz, 1 GHz CPUs. And the result is that the latencies or jitter are not really consistent with what the applications want. And when you have, when the latency is between 20 and 40 times what it should be and when the jitter is 200 or 600 times what it should be, even though we try to optimize, it does not look reasonable to think that we're dividing the figures by a factor of 50 on average. So that's why we had to find a solution on New Zealand. And then why not ODP, DPDK to handle that? Well, in the automotive industry, people have solved the problem for quite some time. And maybe they already have a TCP IP stack in New Zealand and access the hardware through proprietary systems or proprietary methods. So why not having a standardized method that is valid for everyone that is also consumable by DPDK or DP or even VPP directly? For example, one use case for VPP would be to have VETH access, direct VETH access for container networking and be able to have a very high performance. So we wanted to have a very generic solution. Now, zero copy, so why zero copy? If you look at the 100 gigabit adapter, that's 148 million packets per second, that's roughly 15 gigabyte per second and that's roughly 1 DMA channel. So if you have the ring descriptors along with packets plus what was just described as the virtual descriptors for an abstraction of that and then you copy the packets. Basically you have all the four channels of the CPU package that are fully used for that. So then for VPP you have zero memory bandwidth to look for the routes and if you have 1 million routes then you really have a problem. So for the design we want to make sure that even for 100 gigabit we still preserve memory bandwidth for the real application. Secure, so in the past we've been using UIO or things like that or VFIO, no MMU and in the context of specter and meltdown I would say that we probably want to make sure that the memory is a very well protected subsystem. So let's not do any other way than IOMMU. Usional network IO, so network IO is not about building a device driver, it's about just getting the packet queues and the packets themselves. Let's not initialize the hardware. If you look at the code size for a real tech adapter it's 10,000 lines of code and out of those 10,000 lines of code you may have 8,000 lines which are about the different initialization procedure for this particular flavor or this particular hardware revision and you don't want to replicate that whole thing in DPDK or VPP. So what you want is to let the kernel do what it's good at, at driving the devices but let the user now capture just the data path. And if we want to have dual stacks which means that one port can be used by the kernel and a user line application. So the very idea is you have net devs in the kernel that have rings and packets and through some communication what we want is to be able to have the rings accessible or visible in the user line and the packets also controlled through user line. But what we want also is that if you use normal if config or other IP routes to commands that they can influence the user line application. And if the user line application wants to change the MTU it will just use the equivalent of the net link interface or whatever IOCTL you need to change that. So that's the design goals. One way to implement was just described. Use FXDP and that's a very good solution. Now we have another topic which is if you go really high speed on the network what about storage? What about the other accelerators for crypto, compression, pattern matching? If you have a solution for network but you don't have a solution for the other aspects of the life cycle of communications then you may just solving a part of the problem. So we think we need a solution that addresses IO in general from user line in a very generic way that can be applied to storage blocks, to crypto acceleration, to compression etc. And also that is able to handle all the IO models that you can find on earth. And let's talk about the IO models a little bit. So that's a typical meek. So you have descriptors and you have packets. Usually everyone thinks of this model only. So you have a bunch of buffers, fixed size buffers, let's say two kilobytes and that represents the packet memory. And then you have the descriptors and before being able to receive packets you have to state in each of those descriptors where are the different buffers. So that's the typical model. In that model on a two megabyte huge page you can squeeze 1,000 packets, 64 byte packets or 1,500 byte packets. You can squeeze only 1,000 packets. Now there are other methods which is common in our mesocese environment. You have these descriptors but you may have multiple packet arrays. This is not about queues where you have RSS and when you want to distribute the load between different queues that's a different topic here. This is about having let's say packet cells that are 128 bytes. You have packet cells of 256 and packet cells of 2 kilobytes. What this means is that you can have multiple packet arrays and for a single flow you can have multiple packet arrays which means that if you're doing an IPsec of load in software or in hardware for a single tunnel you can have multiple packet queues. Well, sorry, multiple packet arrays that can be handled by different CPUs or different hardware blocks. So this for example in the AFXDP is not yet supported but maybe that was the discussion on the mailing list. Maybe the model can be extended to support that. It's yet not fully known. There is another model for packet reception and that's the tape model. So you have the descriptors. That's the only common thing in all those packet IO stuff. And then you have a non-structured memory area. You have no notion of a packet buffer at all. So all packets can or just put one after the other or between let's say with some placement rules. But the hardware decides exactly where it wants to place the packets. So in that case for example for a 2 megabyte area you can squeeze 32,064 byte packet which is a little bit more than 1,000. So those models why do they exist? This model is essentially to be able to have parallelism on a single tunnel. This one is to be able to beat the DMA transaction bottleneck that we have on PCI. On PCI on the Gen3 times 8 you have roughly 42 million DMA transactions per second. Regardless of its arm, intel or whatever that's a PCI limitation. Which means that if you have one packet equal one DMA transaction per second your limit is 42 million packet per second. So if you have a 50 gig line card which is in theory 74 million packet per second if you use that model you can't reach line rate. It's not because your software is not good. It's the fact that the DMA transaction limit the amount of IO you can do. So that's why those models exist. For transmit we have the same stuff and you have ways to again to beat the DMA transaction limitation on the output side. So if packet was good but we need more than just networking and we need to be able to support all the IO models. DMA buff has been around for quite some time but it's very well done for large buffers that were even more than 4 kilobytes. But not for 64 bytes packets and 148 million packet per second. If you use VFIO natively you lose the net dev support in the kernel. So we thought that VFIO Mdev which has been introduced by Intel to support virtual GPUs in QMU was the right underlying framework to support user land IO. For not only networking but also for other accelerators. And by the way the VFIO Mdev route has been well is being investigated by Intel which is Sun Ming Liang and Ren Hat on one side. And Huawei is working on leveraging the same VFIO Mdev for crypto device support. So one thing we ended up doing is we separate the packets and the rings. We say that the rings are the entities that are managed by the kernel. Creating a ring, creating a queue can be very complicated depending on the hardware. So we don't want the user land application to deal with that complexity. At the same time also when you transition from kernel to user land you don't want to have an undefined ring. You may have an empty ring but you don't want to have an undefined ring. So the idea was to keep the life cycle of the rings inside the kernel and just bring the packet memory handling into user land. And that's what happens for the life cycle of an application that uses NetMdev. So first of all we want to make sure that there is a limited or zero difference from a code perspective when the NetMdev is activated or not in the kernel. So if you have a four wheel driver, if you load it, it will behave exactly as if the additions, the patches were not there. But if you have this global enabled parameter then there is a little bit of change in the code path. What the change do is essentially make sure that we don't create security issues. So we make sure that the rings are page size aligned and a number of things like that. Once the driver is loaded we have to capture the queues in user land. So we do a set of configuration. Those configurations are coming directly from the Intel VFIOMdev framework to build virtual GPUs. But we use it to create virtual nicks. We ensure that the transition from kernel to user land happens in a very smooth way. And we leverage a very generic VFIOMdev framework to pass all the relevant structures to control the hardware. So the doorbells, the different, if it's a PCI device, the different config spaces, etc. So when the application starts it's again, it's just using the VFIOMdev system code. So we have not defined that, that's already in kernel 4.10. We just make sure that we added some semantics into the framework that is about packet queues and packet arrays. And then the user land actually does the allocation of memory in a way that is consistent with the different IO models we saw. And there is something that has to be done in this context as we're dealing directly with the hardware. There is one thing which is a little bit complex and that's DMA syncing. So in some architectures, DMA operations are always coherent, which means that you don't have to deal with cache validation or flushing in those architectures. But most architectures are not like that. And you need to deal with that. And so that means that at some point you may have to do what the kernel does but in a smarter way so that we don't lose the performance by doing DMA syncs on every packet. You may want to do like VPP, you may want to do DMA syncs on a vector of packets. So what this means in terms of code, we tried that on a number of systems. And that's the kernel driver code base. And that's the kernel and user land lines that have been added to actually do packet IO. If you look at the DPDK PMD for this, we're closer to 30,000 lines because it's replicating the same stuff. Well here we're looking at a very reduced. If we look at performance, so on this 40 gig card on the transmit side, we reached the DMA transaction per second rate. On this one, we don't know if it's a hardware limit or if it's the way we actually handle the hardware. For this shell show card, we beat the DMA transaction per second because they have an IO model that allows it. And we know that we don't know how to properly drive the hardware yet. And talking with the shell show guys, we know that for the T650 gig card we'll be able to receive and transmit at line rate. But that's the goal for the next few weeks. So what's next? I think I'm running, I'm good. We haven't yet pushed an RFC because we needed to make sure that at least it works. It was not clear. And we really would like to talk with the AFX DP guys so hopefully we'll be able to talk with a beer later today. We don't really want to say that that's the way to do things. We'd like that the community finds a way that is acceptable so that we reach a certain performance level and a certain, let's say, generous CT of architecture support and also maybe a goal a little bit beyond the network. So this is really about discussion. Now the kernel has no, that's a personal topic. Usually the kernel considers the hardware is good, that it drives it and that's good. But what happens with the management engine and all those stuff and the fact that GPUs have programs running on it, that network cards have programs running on it, you can't really trust the card to not do DMA on any area of memory. So I would like, we always consider that devices should always be now behind IOMMU so that whatever happens inside the device, the firmware, the software does not attack the kernel from outside. There is something else which is the coherent interconnects. So you have C6, you have OpenCAPI, you have Intel has, I don't know the name for that. I don't know if I should know the name for that. Anyways, those models will radically change how we should build device drivers. Because for example, we always think that there is DMA so we have a packet and we want to move that packet from the card to the host. But with coherent interconnects, you will just be able to pass a pointer and say that's the packet. And if you want to access just the header, you will just have, you will bear the cost of the header but there will be no transport of all the packet from the adapter to the host memory which means that typically we try to avoid scatter gather list and have a tell room and head room to be able to add tunnel headers but with C6 and coherent interconnects that may be totally useless. So I think this will change the way we do drivers and GenZ is almost multiplying the memory bandwidth by a factor of 6 to 8. So this will also change how we'll see memory. And because of that, I would like those ideas to be integrated in the user line frameworks and I'm done. So any questions? Why do I create a bidirectional mapping? You mean the ring descriptors? I don't see bidirectional. Sorry. In the middle. Ah yes, bidirectional. Because if you do a packet forward from port A to port B, when you first get the buffer, you don't know what you want to be flexible in the way you will be syncing. So you can allocate the buffers bidirectional and then do the mapping at the latest moment. But essentially what is important is that the IOMMU domain has to span all the IOVA has to span all the devices so that one IOVA address is valid for any descriptor that you will put into. I don't know if it makes good English. Descriptors are different. As they are maintained by the kernel, they are not in a separate IOVA but we can consider that they are in a separate IOVA on which we have a user line mapping. But we don't control the bus address of that because that's the kernel who decides. And when we map those areas from New Zealand, we never specify the DMA or the bus address. We just specify a VFIOM-DEV region ID which will be then translated so that we don't mess around with addresses from the kernel. Okay. So we have no more time for questions. I'm afraid. Thank you.


All right. Hello, everyone. Thank you very much for having me, and welcome to my talk. It's called the attacker perspective insights from hacking Alibaba Cloud's internal Kubernetes environments. And the story I'm going to tell you here today is kind of a unique story in the KubeCon view, because I'm not going to tell a Kubernetes story from the point of view of a developer, a DevOps person, or any of these things, but from the opposite point of view. How me as a hacker is looking on Kubernetes environments like real-life Kubernetes environments of Alibaba Cloud and trying to basically hack them, break them, and specifically how we were able to start from a database instance on Alibaba Cloud that belonged to us, contained our own data only. From there, we were able to gain control over the entire Kubernetes cluster and gain access to all the other customer's databases that use the same service on Alibaba Cloud. And not only that, but also we were able to gain right access to Alibaba's internal container registry containing all their images for different cloud services as well, poison their images with whatever malicious code that we wanted to insert into there, and have that code executed on all the other customer's databases as well, and on other cloud services on Alibaba Cloud too. So how do we do it? What sort of mistakes and bugs were we able to explore here to get this crazy level of privilege? And most importantly, how can you guys prevent yourselves from doing these similar mistakes when we're dealing with these sort of services? Let's dive right in. This is before we do. Allow me to introduce myself. My name is Eli Mesason. I'm also here on behalf of my teammate, Ronan Shustin. He couldn't be here with us, but he did a lot of the stuff that I'm going to talk about today. My name is Eli Mesason. As I said, my Twitter handle is very conveniently just at Eli. So if you want to hit me up there, I post cool research stuff from time to time. You're also very welcome to slide into my DMs. I am 24 years old, based in Israel. Very proud to be Jewish and very proud to be Israeli, especially during these tough times. And I am a security researcher as part of the WIS research team. What we do is basically cloud security related research, which translated means a lot of the time working with real life, big and complex Kubernetes and Docker-based environments in lots of different cloud services and cloud providers, such as Alibaba Cloud. Alibaba Cloud is the biggest cloud provider in the Asia Pacific region, and also generally a very big cloud provider. And just like the other cloud providers that you guys might know, Alibaba Cloud also offers a wide variety of managed database services to its customers. They come in all shapes, sizes, colors, and flavors. In this particular research, we decided to focus on particular one of them called Postgres SQL. Postgres SQL is a database. We chose that one because it's a very complex and feature-rich database. And on our experience, we found it to be relatively easy to exploit to gain code execution. Basically, what we found on previous cloud providers when working with Postgres SQL is that it's basically an open source project for databases that is inherently designed for on-premise environments. And all these cloud providers tried to modify it in order to be a cloud-based service-based solution. They did these sort of similar patterns of mistakes that we were able to exploit in many different cloud providers. If you're interested in learning more about those particular vulnerabilities, there is a link at the bottom of this slide. We have a very detailed blog about these vulnerabilities. And we also had a black hat to talk about this, which is quite interesting if that's what you're into. So we're not going to talk about that today. We're going to talk about Kubernetes. But just know that this is the reason we chose Postgres. So Postgres SQL is offered by two database services in Alibaba Cloud. One of them is called AnalyticsDB, which is sort of like the big data service that Alibaba provides. And otherwise, it's called EpsaraDB, RDS, which is just a regular database service. So let's talk about AnalyticsDB and how we hack that service. So we started out by creating a new database on our account and basically started looking for these vulnerabilities that just talked about these mistakes until we were able to gain code execution on one of these databases. And the first thing we asked ourselves after we gained code execution is, OK, we're running code on something. Where exactly are we running? What sort of infrastructure does the database have? We're running code on something somewhere, but what exactly is the underlying infrastructure? So we start looking at the file system, the processes, the network, et cetera, et cetera, until we figure out that this is a Kubernetes environment. Our database instance runs on a Kubernetes pod, which, of course, begs the question, how could we actually escape that pod? We don't want to be chained. We don't want to be in the matrix. We want to break out of jail and see what actually happens on the infrastructure of what we're doing. So how do we break out of prison? Basically, whenever we try to escape out of containers, we try to look for these similar patterns of mistakes that people usually make when configuring Docker containers that we can exploit in order to break out. So one of the popular things that we would be looking for, for example, is high permissions within the container, like what sort of permissions and Linux capabilities maybe does our user have that we can try to exploit? So in this case, we did not run as root. We ran as a user called adbpgadmin. It was, quite frankly, just a weak user.  It didn't have access to anything interesting. It didn't have any sort of permissions or capabilities that we were able to exploit, so that one was kind of a hit on the wall. The other thing we try to look for is any sort of shared namespaces. Do we have a PAD namespace, a mountain namespace, a network namespace that we share with anything else that we can try to exploit for our own good? In this case, we had none. So nothing, this was also quite of a dead end. Another thing that we try to look for is any sort of shared resources, and in this case, we actually found a persistent volume storage, which was our home directory. It was slash home slash adbpgadmin. This was a persistent volume storage, and this was the first maybe interesting find that we found, but it wasn't that interesting, because that folder was not particularly an interesting folder, it was just our home directory. It mostly contained the Postgres SQL data, our own database data, which had to be persistent because that's the service, but it didn't actually give us anything meaningful. So at this point, we looked at this list that you're seeing behind me, and we tried to ask ourselves, we took a hard look at the mirror and tried to ask ourselves, so what do we have here? Ultimately, the answer was nothing. We didn't really have anything interesting. As you can see here, our user is weak. We do not have any shared namespaces. We only have one persistent volume storage that we don't really have anything to do without, so we really did have nothing on our hands at this point. So we decided to go back to the drawing board and do what any good security researcher does best, and don't tell anyone because it's sort of a trade secret, but what a good security researcher does, a big percentage of the time, is just click on random buttons until something interesting pops up. So we decided to do just that. So we're back to the Alibaba Management Console. As you can see, there are a lot of buttons going around, so we decided to just click all of the buttons until something interesting will inevitably pop up, and then something interesting popped up. This toggle that you see here is labeled SSL Encryption, and as we saw that, that looked really interesting to us because SSL Encryptions implies that there has to be some sort of SSL certificate being installed. The certificate is a file, and when you do all these actions with files, you open up lots of interesting attack surfaces like symlink attacks, like fastest of permissions, all these sorts of stuff. This looked like an interesting direction to us. So we clicked on that toggle, and we clicked OK, and suddenly bam, all sorts of interesting stuff started to happen within our container, all these new processes started popping up. So we were like, OK, stuff is happening, that's very exciting, what exactly is happening? So let's go over these processes one by one. First process we see here is Run C in it, which is very exciting because it means a new container is being created, is being spawned, which is always exciting to see, but what exactly do we see that process here? It's a different container, why exactly do we actually see the Run C command? Well, the answer is that it must mean that we show this MPID namespace because we can see all the processes that are running within that container, it means that our container and that new container being spawned share a PID namespace. Great, let's move on to the second one. The second one is a Python script that is being run from that new container. It's running from a script that is on slash opt, but we wanted to see that script, so we went to slash opt and that script was never there. Quite weird, what does that mean? Well, that means that we have a different mountain namespace. Our containers slash opt and that new container slash opts are different folders, we cannot see that script, that means we have different mountain namespace. Cool, moving on. Third commanding run is making a new directory under our home directory under home pgadmin, and when we looked at that folder, we saw that the folder was indeed created, which means we have the same slash home slash adbpgadmin, which means we have a share of volume. That's exciting, we have another thing in common with that new container, that's cool. And finally, the last command of this script runs is the scp command. This command actually does not run as root, it runs as us, it runs as the adbpgadmin user. Okay, so scp, what the hell is that? So scp stands for secure copy protocol. Basically it's a utility for transferring files over an SSH connection between machines. That's how Alibaba chose to move the system from their machine to ours. And this is interesting to us because we thought, okay, if there is an SSH connection being created, then SSH will have to read the SSH configuration. But because this runs as our user, not as root, then the SSH configuration will be loaded from our home directory, slash home slash adbpgadmin. So we can write an SSH configuration, the scp will load it, and it will listen to everything that happens inside it. So we're like, okay, we might control an SSH configuration, what can we do with that? So we'll ask ourselves all these theories, maybe we can add a new library and do some sort of SO hijacking thing, inject ourselves to the SSH D process, et cetera, et cetera. But in reality, there's just a configuration called local command, it takes the command and it runs it, which is very, very convenient. Shout out to OpenSSH for that amazing configuration option. So basically we added this to our config file and then whenever scp runs and loads that configuration, our command will be executed. So little recap, we had our own container, the PostgreSQL container, right nearby that we had the Alibaba management container, both of those share the same home directory and the adnm space. Whenever that container will go to run the scp command on our container, it will load our malicious SSH configuration and bam, now we're running code on the Alibaba management container as well. So what does this management container actually contain? We're running a machine, we'll try to figure out what exactly we're looking at here, we'll try to look at files, processes, whatever, in this case mostly files, because that's the thing that was different between the two containers. And imagine our surprise when we came across the slash run directory and saw this file right here, docker.soc. We all know docker. How docker works behind the scenes is basically you have the docker API, it listens in to get all these commands, like run, create a new container, create a new image, point a new blah blah blah and it listens to these commands and performs them. It can listen on either a TCP connection or a Unix socket, which is a file just like this one, docker.soc, which means if we have access to write to that file, we can write docker API commands and the docker API is supposed to run them. So we're like, okay, fantastic. Let's create a new, let's send a command to docker API asking the docker API to run a new privilege container. Now the host run our own commands on a new privilege container, would that work? Well, it did. We ran a command, we were able to get a new privilege container and got a reverse shell back from the Kubernetes node itself. We got a new scary error message saying that it's like a production server. So, seems like we were successful. Let's have a little recap again on how we escaped that Kubernetes node. We started out with executing code on our own database, our own PostgreSQL instance. From there we were able to spread to this neighbor container, the Alibaba management container through the SAP trick. From there we were able to access docker API, create a new privilege container and once we were a privileged container we had access to run code over the entire Kubernetes node. Cool, so now you control the Kubernetes node. What exactly is on that Kubernetes node? So we started looking around and realized that this node did not contain anything besides our own data in it. We didn't see any evidence for other customers data which means that on this service each customer database runs on a different Kubernetes node. Basically this is the way for Alibaba to separate between different customers. So that means that even after we did all this escape and we control the entire Kubernetes node we still don't have any direct access to other customers data. Or do we? So, it's worth noting that if you're using Kubernetes for separation of nodes there is still one thing that keeps them together although theoretically separate which is Kubernetes itself. Kubernetes links all these nodes together through the Kubernetes API sort of complicates your, you know tenant isolation architecture. So after just, okay, we're a node in a Kubernetes cluster we have a service account. What exactly can a service account do? So we tried listing the pods and immediately we saw that something was fishy because we did not only see our own pods but we also saw other customers pods as well. So we realized, okay, this might be a strong service account what else can we do? Besides seeing the pods we were also able to see all the images that were used to create all of the spots basically all the templates that were used to create them. And the more interesting thing is that all these images used the same secret a Docker image pool secret that were basically the credentials for Docker to log into the container registry and fetch images. So we had access to that secret meaning we had credentials to log into Alibaba's internal Docker container registry. So we were like, okay, we have credentials to the Docker registry. What sort of credentials are they exactly? So we decided to check what sort of access token we get in these credentials. So we got this access token. And if you have very sharp vision from right there in the crowd you might notice that this token did not only allow pull but also push permissions. Meaning that we can push we can take our own images and push them into the internal container registry and basically poison every single image internal image on Alibaba Cloud whether it be our own service different services, insert whatever malware or custom code that we want to run and every single image on Alibaba Cloud every single container on Alibaba Cloud is created from that image we'll run our own code in it. Okay, a little recap. It's gonna be nice video. Nice video Jason. So we started out us as an attacker with our own Puskas SQL instance. We managed to run code on that with the Puskas SQL vulnerability and from there we were able to escape to the underlying node run code on the underlying Kubernetes node was we had access to that node we had access to communicate with the Kubernetes API server so we managed to fetch the Docker image pull secret using that secret we connected to Alibaba's internal Docker container registry and we were able to push our own malicious image and then that image would be pulled by every other analytic DB on Alibaba and not only that, it will also be pulled by a myriad of other Alibaba services for example, App Store DB that we talked about will also pull their images from our control registry and we will be able to basically run our arbitrary code on every single one of them. All right, so we're talking about analytic DB. Let's also talk a little bit about App Store DB the other database service that Alibaba provides. So App Store DB RDS, how are we able to escape from that one too? So it was kind of similar, but also not. We started out with the same exact vulnerability we were able to run code on our Puskas SQL instance from there we were able to similarly escape to a Alibaba management container. However, this time this management container was in itself a privileged Docker container. So we then have to do any extra steps. We were all the privileges so we were able to take over the entire Kubernetes node. So now we're on a different Kubernetes node it's a different service, a different infrastructure and we started to look around trying to figure out what does this node have? What exactly does it control? And imagine our surprise when we looked around and saw tons of other customers databases on the exact same node. Meaning that on App Store DB Alibaba does not separate between customers node it only separates between pods. So the minute that we managed to escape to the Kubernetes node we were already able to access other customers databases. So those are basically the vulnerabilities that we found in both Puskas SQL services in Alibaba Cloud. We reported all of them to Alibaba they responded very professionally and they applied multiple fixes. First of all they fixed all the vulnerabilities and misconfiguration that we just talked about obviously. They also interestingly created a new internal internally developed safe container technology similar to Google's GVisor but now Alibaba internal one. They applied it to all those containers as a matter to harden them. Basically make it harder for people to escape out of those containers. And finally they also restricted and scoped the nodes permission the service accounts permission within the Kubernetes cluster and also obviously the container registry permission so that people won't have right access anymore. All right let's talk a little bit about what went wrong here exactly. What sort of mistakes and bugs were we able to exploit here in order to get these permissions? The first mistake that happened here is first of all the unsafe namespace sharing between our container and the other container.  Whenever you intervene with our container you should know it's obviously a risky thing to do. You should do it with extreme caution and with low privileges as possible. The second mistake happening here is using the container as the sole security barrier between customers data between different tenants. Whenever you use container as a security barrier you should be aware of what exactly is needed for an attacker to bypass that security barrier. When using containers you're first of all prone to any sort of misconfiguration or unsafe resource sharing which is exactly what you saw here today. But not only that it's also worth mentioning that when you're using container as a security mechanism you're also exposed to any Linux kernel vulnerabilities. Because Linux kernel is the one that is responsible for basically enforcing those policies that means that whenever there is any Linux kernel vulnerability or one day that is not that uncommon in today's world whenever you manage to run code on the kernel you're also able to escape from the container. So all the attacker needs to do to bypass that security barrier is one of those two things. So it's worth mentioning that when choosing security barriers what exactly is needed for a skilled attacker to bypass them which is in that case not necessarily that much. Third thing went wrong here is the strong Docker registry credentials which also had write permissions. It's worth mentioning when you create a secret that is that powerful that any service account that has secrets permissions, pod permissions within the Kubernetes environment can potentially obtain them. And whenever it's obtained they can pose kind of unique risk that crosses different environments because both productive environment, their environment build test and even developers workstations all those people are pooling images in order to work. So whenever you can control a internal container registry it allows you to spread within all these different environments which normally an attacker wouldn't be able to do so easily. If you're interested in tent isolation in general there's a great resource that I highly recommend it's called Peach. It's basically an open source framework that is used for modeling and improvement, standardization and SaaS and pass applications. It was developed with the help of excellent people for great companies such as yourself so contributors are always appreciated. If you're working with multi-talented environments or even creating multi-talented environments I think it's a very good resource to consult with in order to make sure that you're separating things properly. And also if you know things that we don't then contributions are very appreciated. It's available at peach.wizio if you're interested in reading more. If you're interested in this research more I just know that basically what I told you here there was kind of just the tip of the iceberg. We have a very detailed blog about all the vulnerabilities and stuff that I didn't even get to touch on on it's called broken system. It's the top QR code here and if you're like that then we also had a very similar research on IBM cloud on a different cloud provider where we also were able to do some sort of supply chain poisoning. That's the bottom QR code right here. Highly recommended read, broken system and hell's key chain. All right, let's sum things up with some takeaways. First of all, it's worth noting that whatever you introduce Kubernetes cluster, Kubernetes pods to a multi-talent environment it's sort of complicated to security model because it provides additional attack surface. It provides the attacker with access to stuff like identity, service cal, share resources, network resources that are always better for expanding your attack surface. So it doesn't mean that you should never introduce Kubernetes to a multi-talent security environment but you should be aware of the risk that it poses and the new attack surface that it creates. The second thing is that containers should never be the sole security barrier. It should never be the only line of defense because it can be broken with, as we saw today, stuff that doesn't necessarily require a super skilled attacker. It can be a line of defense but it shouldn't be the only one and another thing that's worth mentioning that is whenever you use containers as security barrier you should definitely take a look into safe container technologies. Google has a very good project mapping and called GVisor. It's basically sort of a safe container solution to help make a very hardened container, stuff that is much harder to escape from than a non-hardened one. So if you're using containers as security barrier you might as well make them hardened. And finally, this is sort of a generic takeaway but it's also very relevant here. Pentes your internal environments. Assume that people will gain access to customer pods and start to work your way up from there to start to try to see what the attackers might be able to see. Let's hope that it won't be an access to overwrite every single image on your internal container registry. All right, thank you very much. Any questions? Thank you. If anyone has any questions you can go to the microphone. Just out of curiosity, why was the Docker socket available in that image that you were shared with? That's a good question. I can't really explain why because I didn't really build that environment but I think that because it was so many hops inside it was a more trusted environment. Like in the second case it was even more of a trusted environment because even the management container was in itself privileged. It was, I think that lots of times people assume that as long as the stuff you're building is more internal, is more business internal then it won't be, it doesn't have to be as hardened but that's always a mistake because it's always barriers upon barriers, right? When ever the first barrier is broken and you get the second one then you have to make new defenses. So I can only assume that's the why. When you pushed to ECR was there no audit that would have caught that unauthorized access? That's a good question. We did not obviously push any sort of malware but basically we just tested our login and managed to see that our token had push access. We later talked to Alibaba and they confirmed that it wasn't the push access just like we thought. We were able to operate all the files but we didn't actually try to do that in real life because that might be actually dangerous and we don't want to damage the actual production environment of Alibaba. But yeah, they also interestingly enough they said that during our research there was some sort of alert going on on a very specific part of the intervention which was the Postgres SQL code execution. They said that this is the part that they noticed. We started doing basically our entire thing there but we got rid of that pretty quickly. Like even after running code on the Postgres we managed to go to the other container and to the Kubernetes node. So we didn't really need that afterwards but they said that this was the part that they noticed internally. Thank you. Thank you. And you mentioned you did it pretty quickly but like how quickly? Is it like days, hours? Not hours, but yeah, it was days pretty much. It was like a week plus minus that entire story. Thank you. Thank you. Thank you, a great talk. Thank you. You did mention that there was an alert, right? What would have the incident responders do that would have stopped you? Like they got alert now. Could they have taken your role? I don't know. Like you have already controlled the Kubernetes cluster. So what action could they have taken to kind of break your steps? Thank you. That's a great question. I think that when they said that what they noticed was the Postgres SQL code execution that means that they can fix it. They did fix it, eventually, of course. You could try to limit the Postgres SQL permissions. You could try to even close the code execution vulnerability entirely. But the thing is that at that point, whenever you, at that point that they noticed us, at this point we were all pretty deep in, right? We managed to get rid of the Postgres SQL as a necessity because we were all running on the node. So at that point I think the smartest thing to do is after you patched the vulnerability and you maybe closed the access to actually try to consult your IR solutions to see what sort of stuff do we manage to do after running code in the Postgres SQL because it's naive to think that whatever this first line of defensive breach, that this is the last thing we did, right? We must have done something else. So if they were able to see all the commands that we run and all the things that we moved out early, they were able to maybe catch up the stuff that we did after and try to close all the rest of the stuff that we did after this. I don't know if they were able to get that conclusion before we reported it to them because in this case we reported it to them. But it's a good question on what happens when a bad guy does this, how will they be able to track the process that happens after Postgres because Postgres is not enough to close just this one vulnerability. So interesting discussion there. Hey. I've got a question that sort of Postgres extended where you've got basically a single tenant service that you're scaling to multi-tenants. And what's the best practice for isolation? So clearly pod-based isolation, unless if you really know what you're doing and are also lucky, that's a dangerous path. No-based isolation, also you pointed out has problems. Separate clusters, separate projects if you're on a hyperscaler and like separate GCP projects or where do you think that line is on where the isolation should be? That's a good question. I think that whatever you introduce like a security barrier or sort of a, something that separates between something and another, you need, what you need to think is what is needed to break that isolation because there's always something that you can do to break that isolation if it's a Kubernetes cluster then you would have to have permissions within the Kubernetes cluster. You have to have an upper-ledged service account, et cetera, et cetera. If it's, for example, an actual VM, right? A virtual machine, then it's still not unbreakable. You would just have to have a guest to host a vulnerability, which might be harder to find than a little sort of vulnerability just by judging what days that are coming out. And even if you have, let's go for the craziest part, you have two physical machines that are connected, actual pizza boxes connected to sockets. Even then, you would have probably some sort of network acts between them. Even then, you could, I don't know, plug USB into one of them, right? But I think that what you have to consider is how hard would you want it to be for an attacker to break out and what exactly does an attacker need to have in order to break out? Because there will always be something. There will be a Linux kernel vulnerability, or there will be a misconfiguration, a guest to host vulnerability, et cetera, et cetera. And as long as you go further deep, it might be more hard to maintain and more costly, but it will also be harder to break off, right? And that's, I think, the trade-off, like the cat and mouse game here. Thank you. Thank you. Hey. Just a little continuation on the monitoring question there. So you mentioned, obviously, it's important to follow up on that stuff. But any sort of guidelines surrounding that? As far as, do we know if there are projects within CNCF or anything else? Kind of, inevitably, we will screw up the configuration and everything else, right? So it's good to have best practices, but can we attack it from both sides and say, well, we're gonna do the best to configure it, but we're also gonna make sure that we're monitoring and have the observability in place because you would notice that they saw it, but it didn't sound like they had enough in place to really maybe see it fast enough or follow through, right? So any recommendations from that end that are more standardized or with tools, aside from just do it better? That's a great question, honestly. I think that generally in security, when you try to be able to secure an environment, you have to do both things, right? You have to both prevent and also both prevent and monitor. You wanna prevent by building, I think that framework, the Peach framework, is a great resource for preventing, for designing better, more secure systems, but in addition to that, you also have to monitor very well, and I think in this case, the stuff that I don't have a specific tool in mind, but I think in this case, the sort of stuff that would have maybe caught us is both stuff that monitors processes being created. If you have, for example, a log of every single process being created, you might have seen all the stuff that we were running on the container. Another thing that might have caught the eye of someone is network-based monitoring because we did make network connections.  So network-based detection would probably caught what we were doing as well. Unfortunately, I don't have a tool off the top of my head, but it's important to, as you said, both monitor and protect and defend. Thank you. Thank you. All right, thank you very much. If you have any other questions, feel free to just come up or send me a message on Twitter, whatever you feel more comfortable, and thank you very much for coming. Thank you very much for having me. I appreciate it. Thank you.


Hello, this is a video on one sample hypothesis testing. Calculating the test statistic for a mean. Your sample consists of 47 subjects with a mean of 35.5 and a standard deviation of 1.49. Calculate the test statistic. You have the following hypotheses. The null hypothesis H0 is mu is equal to 36.1. The alternative hypothesis H sub 1 is equal to mu is less than 36.1. To calculate the test statistic for any hypothesis test, you need to use the appropriate formula. Since we are dealing with mu, a population mean, and we do not know the population standard deviation, we know the sample standard deviation but not a population standard deviation, our test statistic will be a t statistic. So we used a t distribution. So the formula for the test statistic for a population mean, when the standard deviation of the population is unknown is x bar minus mu divided by the standard deviation divided by the square root of n. So all of these variables are given to me in the question here. My sample consists of 47 subjects. So sample size is 47. The mean of the sample x bar is equal to 35.5. The standard deviation S of my sample is 1.49. And then my population mean, the value that I am dealing with here is mu is equal to 36.1. Plug in these four values into the test statistic formula. So you will have 35.5 minus 36.1 divided by 1.49 divided by the square root of 47. 35.5 minus 36.1 is negative 0.6. In the denominator down here, you have another fraction. You have 1.49 divided by square root of 47. And you wanna keep this answer to as many decimal places as possible. So I'll do 0.2173388. The more decimal places you keep, the more accurate your answer will be. The more the better. Then divide. Your test statistic is going to be negative 2.76. That is your test statistic in this case. Thanks for watching.