Live from Orlando, Florida. It's theCUBE, covering Pentaho World 2017. Brought to you by Hitachi Ventura. Welcome back to sunny Orlando, everybody. This is theCUBE, the leader in live tech coverage. This is our second day covering Pentaho World 2017. theCUBE was here in 2015 when Pentaho was just had just been recently acquired by Hitachi. We then, let's see, around September timeframe, we saw Hitachi rebrand as Hitachi Data Systems, rebrand as Hitachi Ventura, bringing together three components of its business, the Hitachi Data Systems business, the Hitachi Insights business, and of course, the Pentaho Analytics platform. And we heard yesterday from Brian Householder, the president and COO of Hitachi Ventura, what the strategy was. I thought he was a very crisp, clear presenter. The strategy made a lot of sense, it resonated. Obviously, a lot of execution to be done. And then subsequently, at the last two days, we've heard largely from Pentaho practitioners who are applying this end-to-end analytics platform to really transform their businesses, to really become data-driven, supporting those digital transformations. So, pretty positive story overall. You know, a lot of work to be done. We got to see how this whole edge to outcome plays out. Sounds good. There's got to be some execution there. We got to see the ecosystem grow, for sure. They guys got a great story. This conference should explode. It's really a product of Pentaho. They've been on the market for more than a decade now as the spearhead for the open source analytics revolution in business analytics and in predictive modeling and in data integration, all of it open source. And they've come very far, and they're really a blue chip solution provider. I think this show has been a great validation of their Pentaho's portfolio presence in the market. Now, Hitachi Von Ventara has a gem of a core asset. You know, clearly the storage market, the data center, converged infrastructure, the core Hitachi data systems, product lines are starting to experience the low growth that is such a mature space experiences. And clearly they're placing a strong bet, Hitachi Ventara, that the IoT, the edge analytics market will just boom wide open. Hitachi Insight Group, which was only created last year by their corporate parent, was chartered to explore opportunities in IoT. They've got the Lumata platform. They had Hitachi next to their conference last month focused on IoT. I think that's really the capstone, the Lumata portfolio in this overall story. Now, I think what we're hearing this week is that, great, they've got nice, the components, the building blocks of potential growth, but I don't think they're gonna be able to achieve takeoff growth until such time Hitachi Ventara. They have a stronger, more credible reach out to the developer community, specifically the developers who are building the AI and machine learning for deployment to the edge. That will require to have credibility in that space. Clearly it's gonna have to be the new set of frameworks, such as TensorFlow, NXNet, and Theano, and so forth. They're gonna need some sort of a modeling frame or abstraction for me that sits on top of the Pentaho platform or really across all of their offerings, including Lumata, and enables a developer to using the mainstream application developer to use code, like whether it be Python or R or Java or whatever, to build the deep learning and AI models at the highest level of abstraction, the business level of abstraction, then to automatically compile those models, which are computational graphs, down to formats that are optimized and efficient to run on devices of all sorts, chipsets of all sorts, that are increasingly resource constrained. They're not there yet. I'm not hearing that overall developer story at this show. I think they've got a lot of smart people, including Brian, pushing them in that direction. Hopefully next year's Pentaho world or however they may rebrand this show, I think they'll probably have more of that put together, but Wikibon's waiting to see. Well, and that's something that I pushed on a little bit this week. And in particular, that requires a whole new go to market. You know, where the starting point is developers and then you're nurturing those developers. And certainly Pentaho has experience with community additions, but that was more to get enterprise buyers to kind of try before they buy. As you know well, Jim, the developer community is, they're very fickle, they're persnickety, they're demanding, and they're super smart, and they can be your best advocates, or they'll just ignore you. And it's just kind of the way it is with developers. And if you can appeal to them, you can get a foothold in markets.  Community marketing, it's full bore, is what the app. User groups, developer days, hackathons, the whole nine yards. I'm not seeing a huge emphasis on community marketing in that really evangelistic sense. They need to go there seriously. They need to win the hearts and minds of the next generation developer. The next generation developer who actually won't care about whether it's TensorFlow, backends, or the other ones, what they will care is the high level framework, and really a collaborative framework that the solution provider gives them for their teams to collaborate on building and training and deploying all this stuff. I'm not hearing that from this solution provider, DevOps really, here, this year. Hopefully in the coming years there will be, other vendors are a bit further along than they are. We see a bit further along, IBM is. We see a bit further along, like Cloudera and others are, in putting together really a developer friendly ecosystem of components within a broader, really broader data lake framework. Yeah, and that's not been the historical Pentaho DNA. However, as you know, to reach out, have a community effort to reach out to developers requires resources and commitment, and it's not a one shot deal. But it also requires a platform. And what we're seeing today is the formation of that, the reformation of Hitachi into Hitachi Ventara with a lot of resources that has a vision of a platform, of which Pentaho is a critical component. But it's going to take a lot of effort, a lot of cultivating. You know, I presume they're having those conversations internally, they're not ready to have them externally, which is, I presume, why they're not having them. But that's something that we're going to certainly watch for, you know, in the coming years. What else, you gave a talk this afternoon. Yeah, AI is eating the edge, and it was well received. Because, in fact, when I prepared these by thoughts in my research about a month ago for this, so that I was thinking, am I way too far ahead of where, this is Pentaho, I've been, of course, familiar with them since their inception. I thought, are there other users, other developers, is their community going deep into AI and all the IoT stuff? And the last day or so here at this event, it's like, well, everybody's here is into that, they know this stuff. So, not only was I relieved that I wouldn't have to explain the ABCs of all that, they were ahead of me on a lot of, in terms of the questions I got.  But those kinds of questions, those are actually developer level questions that people are just, you know, here, and then coming to me with. Well, you know, I tell ya, I'm no expert in frameworks, but my advice would be, whatever framework you adopt, you're probably not going to be using that same framework down the road. So you have to be flexible as an organization. A lot of technical, you know, leaders tell me this, is look, technology is going to come and it's going to go. We got to have great people, we got to be able to respond to the market requirements, we have to have processes that allow us to be proactive and responsive. And that your choice of framework should, you should ensure that it doesn't constrict you in those areas. And you know the framework that actually appeals to this crowd, including the people in my room, it's a Wikibon framework, it's also what Brian Hopkins of Forrester presented, the three tier architecture. There's the edge devices, there are the gateways or hubs, there's the cloud. We call them primary, secondary, tertiary issues. Whatever you call them, you put different data, you put different analytics on each of those two, and they really, in many ways, in a modular fashion, then you begin to orchestrate with Kubernetes and so forth. These AI-infused apps and these distributed architectures, like, you know, cell driving vehicles or whatever. That, in the buzz I've been getting here, including in my session, everybody's saying, yeah, that's exactly the way to go. That's a broader, you know, in other words, that thinking in those terms prevents you as a developer from thinking that AI has to be some monolithic freaking stack on one single note. No, it actually has to be massively parallel and distributed, because these are potentially very compute-intensive applications. I think there's a growing realization in the developer community that, when you're talking about developing AI, you're really talking about developing two core workloads. There's the inferencing, which is where the magic happens in terms of predictions and classification, but even more resource-consumptive is the training that has to happen in the cloud, and that's data-intensive. That's exabytes, petabytes-intensive, potentially. That's compute-intensive. Very different workload. That definitely needs to happen in the cloud, and primarily, there's a little bit of federated training that goes out to the edge, but that's really the exception right now. So there's a growing realization in the developer community that, well, we better get a really good platform for training. And actually, they can leverage. We've seen in our research at Wikibon is that many AI developers, many deep-learning developers, actually leverage their spark clusters for training of TensorFlow and so forth because of in-memory, massive parallelism, so forth and so on. I think a lot of, there will be a growing realization in the developer community that the investments they've been making in Hadoop and Spark will just be leveraged for this growing stack for training, if nothing else. Well, and then 8.0, that was sort of the big buzz here, and you and I talked at the Open with Rebecca, our other co-host, about 8.0, a lot of incremental improvements, but you know what, in talking to customers, that's kind of what they want. They want Pentaho to do a good job of incorporating, curating, open-source content, open-source platforms and products, bringing them into their system and making sure that their customers can take advantage of them. That's what they consistently kept asking for. They weren't freaked out about lack of AI and lack of deep-learning and ML and WECAs is fine. Now, maybe it's a blind spot. I don't know. Actually, I've had 24 hours since the announce. I don't know to chew on it. In fact, I have a SiliconANGLE article going up fairly soon with my, essentially my trip report of the basic takeaway. And actually, what I like about 8.0 is that it focuses on streaming, bringing open-source analytics, streaming more completely into the Pentaho data integration platform. In other words, there's stronger interoperability with spark streaming with Kafka and so forth, but also they have the ability with an 8.0 to better match real-time streaming workloads to execution engines in a distributed fabric. In other words, what I think that represents, in terms of, not only in terms of Hitachi, Vantara's portfolio, but in terms of where the industry is going with all things to do with big data applications, whether or not the above AI is streaming is coming into the mainstream, pun intended. And data at rest platforms are starting to become marginalized in a lot of applications. In other words, Hadoop is data at rest par excellence. So are a fair number of other no-SQL platforms. Those are not going away. Those are the core of your data lakes. But most development is being developed not most AI and machine learning is being developed for streaming environments that increasingly are edge-oriented. So Pentaho by Hitachi Vantara for 8.0 is actually have put in the right incremental features for the market that lies ahead. And so in many ways, I think that was actually a well-thought-out set of release for this particular event. Great. Okay, some of the highlights here. We had a lot of different industries. We had gaming. We had experts on autonomous vehicles. We had the NASDAQ guys on that was very interesting segment, the German police interview you did. The chief data officer of community colleges in Indiana. So a lot of diversity, which underscores the platform-ness of Pentaho. It's not some industry-specific system. It is a horizontal capabilities platform. Final thoughts on the show. Some interesting things that you saw, things you learned. Yeah, on the show itself. They did a really good job Hitachi Vantara. Of course it's a new brand, but it's an old company. And it's even an old established set of product teams that have come together in a hurry essentially, though it's really been two years since the acquisition. They did a really good job of presenting a unified go-to-market message. That's a good start. They've done a good job of, the fact that they had these two shows in a rapid sequence, Hitachi Next, which was IoT and Lumata, but it was Hitachi Vantara. And now this one, where it's all data analytics, the fact that here in the peak of the fall announcement or event season, they had these two shows really highlighting their innovations and their roadmaps for those core pieces of their portfolio and they've done a good job of positioning themselves in each case. That shows that the teams are working orchestrating well in terms of at least go-to-market presenting their value prop. I think in terms of the actual, we've had a lot of great customer and partner interviews on this show. And I think you mentioned gaming first. I wasn't actually on the gaming related Cube interview, but gaming is a hot, of course, it's a hot, hot market for AI increasingly. A lot of AI that gets developed now for lots of applications involves simulations of whatever scenario you're building, including like autonomous vehicles. So gaming is many ways, a set of practices that are well-established and mature that are becoming fundamental to development of all AI because you're developing synthetic data based on simulation environments. The fact that Hitachi Vantara has strong presence as a data provider in the gaming market, I think in many ways indicates that they've got, you know, it's a crowded marketplace, they have much larger competitors and deeper pocketed, but I think the fact is they've got all the piece parts needed to be a roaring success in this new era, and they've got strong and loyal, very loyal customers, I'm discovering, not discovering, I've known this all along, but since I've rejoined the analyst space, it's been re-validated that Pentaho, how strong and blue-chip they are. Now that they're a new brand in a new era, they're turning themselves around fairly well. I don't think they'll be obsolete by clearly. I mean, AI right now belongs to AWS and Microsoft and Google and IBM to some degree. We have to recognize that the Hitachi Vantaras of the world right now are still a second tier in that arena. They probably have to hitch their wagon to at least one of those core cloud providers as a core partner going forward to really prevail. Which they can do. Yeah, they can do. All right, Jim, thanks very much for closing with me. Thanks to you all for watching. TheCube puts out a lot of content. You can go to siliconangle.com to see all the news. TheCube.net is where we host all these videos. Wikibon.com is our research site, so check that out as well. We got crowd chats going on, crowdchat.net. It's just unbelievable. Unbelievable. A rush of content. We're all about the data. We're all about sharing, so check those sites out. Thanks very much to the crew here. Great job. And next week, a lot going on. We're in New York City. We got some stuff going on there. I want to thank our sponsor without whom this show, this Cube show would not be possible. Hitachi Ventara slash Pentaho. Thank you to Sunny Orlando. Yep, it's great and wonderful. This has been theCUBE at Pentaho World 2017. We'll see you next time. Thanks for watching.


10 seconds left on target 2. So the events that we participated in today was a Prusik ascend and also a top rope. We also participated in a stress shoot and that one was was pretty fun. So for the training that I did for this competition, I really focused on building my endurance and testing myself every day. My goal was to essentially become better every single day than I was before. I think what I'm most looking forward to in competing in this competition is being able to meet all the competitors coming from all over the country and what they bring to the table and being able to take that back to my state and provide some knowledge transfer for my soldiers. Being here and making all these new battle buddies and friends that get to embrace the suck with me is probably one of the best parts about the whole competition.


Hi, my name is Case Cook. This is a little bit about a specific area of the Kernel Cell Protection Project sort of looking at the C language generally and why it causes us so many problems and what sorts of things we can do to improve that. If you want to follow along any of the links or read some of the very small text I have in here, you can download the slides there or once I get that linked from the Linux Foundation website as well. So this is specifically about the Linux kernel, obviously. And the agenda here is I want to give sort of a quick background on KSPP and talking about C as a language and how it's really just a fancy assembler. And then looking towards to some specific issues that we can try to solve hopefully or at least minimize. So the Kernel Cell Protection Project was started a couple of years ago to sort of focus on bringing kernel protections into the kernel and we've had a lot over the years of protections, the kernel supports for defending user space from user space. There hadn't been as much focus in the upstream kernel on protecting the kernel from user space. And this is a pretty wide project. We've got about 12 organizations with maybe 10 individuals working on a bunch of stuff. This is an upstream project. It's not a fork or anything. So it sort of follows the upstream development models and is slow and steady is the way I like to think about it. So this brings us to one of the main problems we've had is dealing with C gets treated mostly like machine code. It's trying to be an abstracted version of this. The kernel does this because it's trying to be as fast and as small as possible. And there's a lot of things that the kernel does that there is no C API for setting up page tables, switching to 64-bit mode. Those are machine specific issues. They're not about the C language at a higher level. So that's why as close as we can get to machine code without all the pain there. But this comes with some really fun things with the language itself, a lot of undefined behaviors in the C language, which comes sort of from its history and some problems associated with having a weak standard library that have old problems. So some quick examples that I'll get into more detail in a bit are, you know, the idea of an uninitialized variable. From the C language perspective, we just say, ah, we don't know what's happening. It's fine. We'll throw a warning maybe. But on an actual machine code, it obviously does have a value. It's whatever was in memory before. And then in C, we start to forget that it's supposed to be a language, and we think about it as machine code again, and we can just call function pointers without any regard to what the actual type of the function is, because when it boils down to it, you're running the machine code. The machine code says, well, we're just jumping to a location in memory and running. But that's not actually what you were trying to say with the C language. So there isn't as tight a binding between those things. And then you also get, you know, things out of the API like mem copy where you say, well, I have an address, and I'm just going to copy as much as I want to it. But that doesn't really help anyone using that library. And normally you see people who are trying to build up a series of copies, you know, they'll have a size, and they're tracking how much size they've copied, but they're not really paying attention to how much is left in the destination. So why don't we have better APIs in that regard? Of course, this is a tiny fraction of all the other undefined behaviors in C. There was a great blog post recently on this with undefined behavior, anything is possible, and I bought the shirt because you have to have the shirt. But this is a huge topic, and I'm trying to sort of focus in on specific areas where we can try to improve the kernel itself, or at least deal with the problems that have been created. So one of those is variable length arrays. When you define a local variable, it ends up on the stack, and in C, you can just sort of say, well, I want the size of this to be how over large based on an input variable from the function, and this creates problems because the stack is a fixed size and you can have a linear overflow that just runs right past the end of the stack and writes over things next to it, but this is a valid stack frame. So things like the stack protection, the stack canary, the stack cookie is actually not going to stop this because C, when mapping this down into assembly, basically says, oh, this is fine. It's just a huge stack, but of course, we've gone way past it. And then there are cases where even if you had a guard page, which is now possible, you could potentially still just jump past the guard page and create problems as well. And again, as far as the C language was concerned, it was perfectly happy with this. The nice thing is this is easy to find with dash W, turn on the VLA warning, dash WVLA. So from a security perspective, the main thing I'm looking at is that they're bad. But it turns out they are also slow. When we went to remove these, one of the driver authors actually did a micro benchmark of the code because it was, I think, a checksum or something code where you could actually do that and he had all the instrumentation. And he saw that a fixed size stack array actually gave him a 13% speed up. So he's like, great. I can now justify the security improvement with improved speed. But I had to know why. Why is it so, so bad? So if you can read this, having a fixed size array generates this tiny chunk of assembly and having a variable sized array did all of that. I didn't even bother to read all of that, but it seems impossibly bizarre that it's that bad. But apparently it is. So just don't use VLA's. Another case is the switch fall through. So C specifies break to stop a switch case. But there isn't anything to say, please move on to the next one. It is simply the absence of a statement that says move on to the other one. But an absence of a statement could also mean you forgot to put a break. So this weakness in C actually has its own common weakness enumeration item. These are omitted break statement and switch. So is this actually a bug? We don't know. We have to look at every single case. So static analyzers have had this problem for a while. So they flag them and to whitelist cases where you do want to fall through, actually with static analyzers they start adding a comment that said fall through. So the compilers following the static analyzers have added parsing of a comment as a statement to indicate I do want to fall through here. But that's sort of where we are. But adding this to your compiler now you can say I want implicit, worn on implicit fall through and if you don't find the comment statement, it will yell at you. And so we've been going through the kernel adding these, looking at every place where it's missing and trying to decide was this an accident. And we've had a lot of bugs found this way. So another one is back to stack is you're getting rid of the uninitialized variable case. Right now if you try to use with most compilers, you try to use a variable that you declared locally that you didn't initialize first. You get a warning that says trying to use an uninitialized variable. However, this warning gets silenced if you pass a variable into a function by reference and suddenly you have no idea the compiler just forgets. Like well, I assume since you passed it into a function that now it's initialized you did it. But of course there's no reason to believe that it actually got initialized. So there are some plugins in the kernel for doing various versions of this. One for force initializing any structure that has underscore underscore user pointers in it. This was expanded to all things that are passed by reference. And then there are still some leftover cases, especially with structure padding where you still want to initialize them for sure. And in some discussions we actually encountered Linus praising the idea of always initializing all the variables all the time. So that's what we're trying to work towards. There was a patch for GCC to do this. It's not upstream. There's a patch in Clang to do this. It is also not upstream. We're looking at building a function or a plugin to do this as well. But this sort of gets rid of the C problem of, well, what's in the memory? It's like, well, we just declare everything is zero initialized no matter what. You can just depend on that as a feature of the new Linux kernel version of the C language. And that makes things more easy to think about. One interesting side effect that I thought was adorable as part of the moving from C to machine language is you got this error by, once you force initialize your variables, I got a warning out of GCC that said, well, you have unrunnable code. And I went looking and it was because you had initializers before the first case statement in a switch, which never gets executed because nothing will actually ever go there. Because variable declaration, which in assembly is making room for it on the stack. And initialization requires running something to write stuff to that area of the stack. So by forcing the initialization in the area of the switch statement that I didn't even know you could put declarations, it would never run it and it would never be initialized. So I went through and lifted out all of these places where this occurred. There weren't a lot, but this was yet another surprising side effect of C. I just didn't know. Another case is dealing with integer overflows. GCC has support for checking for signed integer overflows. This is one of the many things that gets enabled with config UBSan right now. So the good news is it's very, very fast because it's just checking for an existing hardware flag. And if you want to, and I'm like, I couldn't actually measure the difference. I need to do better micro benchmarks to really figure out how many cycles difference it is, but it's, I think, going to be very, very small. And if you just want the kernel to abort immediately, it grows the kernel image by 0.1%, which is good, but the downside is if you want warnings about this, it grows the kernel image by 6% because there are thousands and thousands of integer calculations being made, as you might imagine. In the meantime, there are, we can do explicit single operation tests where we say, I want to know for sure in this code flow whether or not I overflowed. So we now have a set of arithmetic overflow detection helpers in the kernel. Klang can do unsigned integer overflow detection, specifically signed overflow is considered an undefined behavior for a variety of reasons, but unsigned is considered well-defined, except that it is usually unexpected. There are, however, a lot of cases in the kernel where we do intentionally perform unsigned overflow, so we'd have to go through and mark that and deal with it. But this is one difference in implementations between GCC and Klang if we're doing that. Klang gives you quite a variety of ways to handle it, sort of showed them in this slide here where you can have it abort, you can have it worn but continue, you can have it worn and give up, you can do a bunch of different things. So plumbing that into the kernel would be nice. And then generally bounds checking, this is, this remains a big area of vulnerabilities in the kernel is just having string copy or mem copy wander past the end of an allocation and just keep writing into whatever memory is next. In the kernel we have the hardened user copy which checks the places where we're explicitly copying to and from user space in the copy to from user checking. And this is under 1% performance hit. I tried to extend this to the string family and the mem family functions. And there are about a 2% performance hit each. I still need to look at this a little bit more. So pre-meltdown, this was a totally unacceptable performance hit for security post-meltdown, it's under 5%. So maybe I have a chance to land this stuff too, we'll see. But it would be nice because we keep getting vulnerabilities where the mem copy is just wrong and we could have easily detected it.  Anyway, and this moves on to can we just get better APIs and get rid of old bad APIs that came from the standard C library. And this tends to be also quite a political problem because in trying to bring developers into the Linux kernel community, you don't want to have to teach them an entirely new C API. However, we're already doing that because we said, well, string copy was no good, let's use string end copy. Except that string end copy doesn't always null terminate and if it's too long and if it's too short, it just nullpads the entire allocation that you did specify, so that's not good. So we made string l copy, but that reads the source string beyond the max length also. So how about string s copy, seems okay so far. So maybe we can improve mem copy too, that would be great. So yes, the point was this is slow, but there is hopefully some future world where we're gonna have hardware supported memory allocation tagging in hardware. So the example here is that your allocator, in this case, Kmalloc, you say I want 128 bytes. And the allocator says, okay, this blue area is 128 bytes. I've given it tag five. That tag lives in the high byte of the pointer value that comes back from the allocator, and so you can say, great, I'm gonna write at an offset from that pointer, and the hardware is looking at that and says, okay, you have the right tag for your offset. It's within the range of 128 bytes, we're good. And then later on you say, well, I want an offset slightly beyond that and says, well, the memory region pass that has a different tag, you're gonna fail. Because you're outside of what you were expecting that pointer to actually point to. So stuff like this exists already in Spark with their application data integrity extension in ARM. This is coming and supposedly we might have this on Intel at some point. Which moves on to CFI, control flow integrity. So with decent control over having memory not be writable and executable, attackers have moved on to trying to use the existing code that's in the kernel to take advantage of indirect calls. Where you have saved a function pointer somewhere and you eventually turn around and actually run it. In this case, for the forward edge calling out, you've got a function pointer saved in the heap, you go fetch it and you just call it. And then on return, you return from somewhere to where you came from. And that's effectively an indirect call off what was stored on the stack. But this is all implementation details. In C, you specified I wanted to make this function call and then come back from it. And without CFI, it's just kind of like, well, I can overload. I can change what I'm calling. I can just tell C, don't pay no attention to this. And we'll go ahead and call the call one versus call two which have completely different function prototypes, violating what we'd asked this function to be. But again, when mapped down into machine code, we're like, sure, it's a function pointer, whatever. Just go there and run whatever happens to be there and we don't care. So doing forwardage checking with Clang's CFI. This will actually blow up because it tries to execute and it says, but I was expecting to call this type of function. But I arrived at a different type of function. I'm gonna freak out. Now this isn't perfect. It's based on the function prototype pattern. So right now in the kernel, there's still plenty of functions that return unsigned long and take as one argument and unsigned long. So that's not great. But for a lot of other routines, it does narrow the window of, narrow the attack surface for indirect calls. Of course, this is forward edge. For backward edge and return, there's things like splitting up stacks where you say, okay, we're going to push all of our weird variables, all of our weird locals, buffers, and by reference variables into this unsafe area because we don't know what's gonna happen to them. Bad stuff might happen. But things we can prove are safe to use, register spills and safe accesses and the return address will split into a different stack. This is one approach to solving that because it makes it so that if the attacker doesn't know where the safe stack is, it's harder to deal with. Similar to this, but with less logic is to do a shadow call stack, which is only thing that you put on the other stack is the return address. And it's harder to get at this one because you can keep a dedicated register for this entire stack, sort of how there's the regular stack register for the unsafe and then another separate register effectively for the call stack. And this works in Clang right now. So there's hardware support for dealing with backward edge, CFI. Intel CET deals with one aspect of this, which is you're doing it in software, leaves that second stack writable, which means it's still, if it can be found by an attacker and written to, they've taken over your return path. With CET, this is effectively a read-only area of memory that is writable only during the call and return instructions that do this implicit read and write to that area. And then a different version is the pointer authentication and ARM v8.3a that adds new instructions to effectively add sort of an encrypted tag to what you're writing out to the stack. And then when you pull it back, you can re-verify it. And the difference on that is pretty simple. It's as you enter a function, you sign where you're coming from. And then when you're about to leave, you double-check that what you have is what you wanted. So where are we now? With VLAs, it's been about four releases of the kernel. We went through a little bit over 100 of these, which were each a little bit different. So it's taken quite a bit of time to get rid of these. But we're down to only a handful in crypto remaining. I'm hoping that that will be completely finished by the 4.20 or whatever is next after 4.19. The explicit switch case fall-through. I know that Gustavo had been sending patches slowly over quite a while. And I thought, well, how many has he sent? I saw that he had sent 745 patches and like, well, I wonder how many we have started with. So we have only, sorry, he hadn't sent, he'd sent more than 700. It's like over a thousand. So now we're only down to about 700 of these remaining. But again, each one of these, you have to look at it and decide what did the author mean? Is there a comment here to describe whether or not the fall-through was intentional or not? But once we get through those, that entire class can go away as well. The always initialized automatic variables. We have, a lot of this is available through the plugins. But we don't have complete coverage. It's not quite the way we think we want it in the kernel yet. We'll see, it'll be nice to get more complete support from the compilers on this. So upstreaming those existing patches would be great. On overflow detection, it would be nice to have GCC grow the unsigned overflow protection, but this does work right now. We just need to specifically tear it out of config UBSan and we should have this, it would be nice. Bounce checking, mainly it's crying about performance and waiting for hardware. That's okay. And CFI, this actually works right now in Android. There's a talk later on this. It's pretty impressive. And again, waiting for hardware. So sort of how do we get there, that's where we are, how do we get there? It's like trying to get people involved. We have a lot of cultural challenges in getting things into upstream. There's a lot of conservatism in not wanting to make changes to code and accepting the responsibility of the overhead and sort of sacrificing one's time to make that happen. Obviously the technical piece, there is a lot of complexity here. But we can solve that. And of course, just getting people to help with doing it, reviewing it, testing it. And in cases where you're not running the latest kernel, actually back porting it to your releases. Since traditionally the LTS kernels only have bug fixes, they haven't normally back ported features. And the reason for that, as you could see with a lot of the patches, the hundreds of patches to fix VLA's and stack switch statements and other things, it's actually a huge number of patches. So back porting that is somewhat prohibitive. So that's it. You can reach me at these places. There's the link to the self-protection project and these slides again. I got, I caught us back up on time. Any questions or other things? Casey? Okay. Yes, here's a microphone for you. I've been doing C programming since 1977. And it was always no, the comment was always no break. Where did they come up with this fall through? It was the static analyzers. So why, why that comment? Why not the one that's been in use for, you know, 50 years, four years? I probably because the static analyzer folks hadn't been writing C since 1977. Well, okay, thank you. It was, yeah, it was just a, it was just, I mean, the reading, the, in the feature request for here is the support for parsing a comment as a C statement. There was great anger in the fact that the, that the compilers got painted into a corner because the static analyzers was like, well, this is what we're doing. This is what we're checking. Here are all of the giant numbers of code bases that we've instrumented now. You know, we've actually updated all the, all the code to say to have fall through as a comment. Compiler people were just kind of like, but we could give you a statement. Too late now. It's a comment. Anything else back there? You want to get the microphone? So once upon a time, I saw an effort made to try and enforce things with the string APIs for them to be more secure, say, no more stir copy after you stern copy. And it resulted in some what I would call stern copy anti-patterns, where people were just doing things like calling a sterling on fixedized strings or other things like that. So what's the plan to try and make sure we don't turn these supposedly more secure into APIs into perhaps still insecure APIs? I think it's mostly us designing it right and actually getting people who have strong opinions about this and looking at the past anti-patterns and saying, what do we need to have? Like what is actually a helpful API for the author that provides us the defensive characteristics we want without getting in their way? And like in the past, we've just kept going, doing tiny band-aid fixes like, well, string and copy. We're good. Just ship it. And I think the other problem we've had is doing evolution of APIs in Linux kernel. We've had a long history of saying, here is a new API. I will use it in this one place. And it's everyone else's problem to fix all the old APIs. And I have tried in some of the conversions we've made to look at past APIs and remove them. So first, move all old APIs up to, move an ancient API up to the old API and then move all of the old APIs to the bad API and then move the bad API to the good API in the process of wiping out the availability of all the others. And I think that's part of the cost associated with this is actually getting rid of the old APIs and not allowing them to exist anywhere and get misused in the future. Just a further bit to Laura's comment. When we've found anti-patterns in the past, we've added like Cox and L scripts and Cox and Chex scripts. Do we perhaps need to proactively figure out, we're adding this API, here is a way people might misuse it, add checks for those kind of things in advance before we start seeing them? That would be nice. We have some sets of the Cox and L scripts already in the kernel, but they are effectively disjoint from a regular compile. In some places where the kernels get built for vendors, they will actually do two-stage compiles. They'll say, first, we're gonna do the static checker compile, which includes Cox and L and some other things. And if that, those tend to be so noisy that really it's, if that does not produce a difference in the output from before and after, then continue and do the build for real. But that's actually been something that's bothered me for a while, is we don't include that in the common build, so there's no warning that something bad has happened, which is why I've sort of pushed to just eliminate the API from the kernel, because if it's gone, it won't even build. But we're forced into some cases where we span multiple releases with APIs, we have to continue to support, and then people get distracted by other things. So it's just a matter of doing it as completely as we can. The question was, is there any way we can mark APIs as obsolete? So we did have underscore underscore deprecated, but Linus deprecated it. So, yeah, well, I mean, Linus's argument was effectively the same, which was, if you're removing an API, remove it. Don't make it someone else's problem. Which is agonizing, right? Yeah, I have done this, and yeah. So there isn't a particularly good solution here. I don't know without having some form of developmental mandate where someone can say, I am removing this API. It is your problem to fix, or your code gets left out? I don't know, like there isn't. We could add things to check patch. That's happened in the past. There's sort of a potpourri of various mechanisms that people have tried. So yeah, just killing the API appears to be best, but it is extremely time consuming, yeah. And however, I've kept this as a, hey, we'd like to get rid of an API. This is a bit tedious, but it's actually usually pretty mechanical, and that works as decent, like Colonel Newby types of stuff. So if there was a list of, here, we'd like to get rid of this timer interface, or the string interface, things like that. Keeping that list in one place is another idea, and now I'm over time. Anything else? Oh, there's one more. So there was a mention of hardware support for bounds checking on x86, and I am pretty sure that there are already instructions for that, that there is an instruction called Bound, I think, in x86 assembly. So what's the problem with it? Because I've heard about it, I've read about it, but I'm pretty sure nobody's using it, not even compilers. My understanding is Bound is separate. I came across it a while back, but it doesn't provide the protections we want, because even if we had that, it requires an explicit check. You would say, am I in bounds? And then you do it, but that instruction still needs to understand what the bounds were, and that information may be totally separate from the execution path. So having the support in the MMU, where it's actually working, when it's actually trying to dereference pointers and do other things, attaching that at the hardware level, it will actually get us what we want. Otherwise, we can just do it in software, and maybe we get those instructions getting used. So plumbing access to the allocation is the slow way in software to do it, but in hardware, if we can just associate it with memory region, then we get it fast for free. Anyway, I think that's it. Come ask me questions if you want to in person, or email me. Thanks.


Elderly woman passes away after her son keeps her in hot car for eight hours without a no-cell phone. An elderly woman passes away after she was left alone in a car with a dog while her son went off to work. Both the mom and son were reportedly homeless at the time and going from one motel to the other as they lived in Reno, Nevada. When the son, Edward Sibley, had to go to work one day, he had no place he could safely leave his mother and thought the confines of their car was the only choice he had left. Edward then left his mother in the vehicle and went to work at around 7.30 in the morning on July 14, 2020. That day, the son could not find any spot with shade to park his car under and wound up leaving the vehicle out in the sun in the 96-degree temperature. As she sat in the car, Edward's mother was dressed in a t-shirt and was wearing a diaper as well, according to Newsweek. The son also left the car keys inside and told her to switch on the air conditioner if she felt the need to. Around lunchtime, Edward checked up on his mother and was told that she was doing okay. He also gave her a burrito before going back to work. As the day progressed, the mother's condition took a turn for the worse and by 3.30 pm, two employees found her drooling and unconscious. After spending eight hours in the hot car, the mother was rushed to the hospital and eventually pronounced dead. Details from the police revealed that she suffered extreme heat stroke and her body temperature climbed up to 106 degrees. There was no cell phone and she was unable to walk, unable to drive, and unable to seek shade from the heat and sun, revealed police reports, according to News4. Meanwhile, the dog in the car was taken by an animal control officer but eventually returned back to Edward. Following the incident, Edward found himself charged with elderly abuse before details about the unfortunate circumstances came to light. Michelle Bays, the Wachow County District Attorney Spokeswoman, said, initially, when it came in it was charged as a felony. After additional review and a lot of the circumstances came to light, it was tragic but tragedy doesn't always equate to felony charges. A year after his mother passed away, Edward took a plea deal to a lesser charge on June 3, 2021. He might possibly not serve any jail time for the incident, or the judge might sentence him to a year in jail. Bays said, that hinged on poor choices, very difficult circumstances. There was homelessness involved, there were certainly attempts to care but the bad decision really hinged on the circumstances of that day. There wasn't proof or evidence to prove beyond a reasonable doubt and there really wasn't evidence at all to prove that he had any intent to cause harm. Edwards will reportedly receive his sentence in August this year.


So just this week we already learned that Mike Bloomberg last year late last year mind you donated more than $300,000 to the DNC and Now they're changing the rules in a way that specifically benefits him and allows him to participate in the next democratic debate And now we have another story that demonstrates this conflict of interest between him and the DNC and all Indications tell us that he is 2020's Hillary Clinton because the DNC is Unquestionably in the tank for Mike Bloomberg and if you're wondering why it's because he is really really rich And if there's anything that the DNC needs at this point in time, it's money So what's the new scandal involving Mike Bloomberg that the media will almost certainly ignore? Well as sludge reports as the Democratic National Committee establishes procedures for the Democratic presidential nominating process two members of the DNC rules committee Simultaneously work on the campaign of former New York Mayor Michael Bloomberg Having surrogates on the Democratic National Convention's rules committee and the standing rules and by-laws committee Could be a boon for Bloomberg if nominating rules are reopened for amendment ahead of the July convention Some DNC members who are concerned about the polling support of Senator Bernie Sanders have discussed Reversing rule changes limiting the power of superdelegates that were put in place after the 2016 election According to a report from Politico those discussions have been sharply rebuked by DNC leadership Michael Nutter the former mayor of Philadelphia who is a member of the standing rules and by-laws committee was selected by Bloomberg in December 2019 to serve as his campaign's national political chair Nutter was nominated by former DNC chair Representative Debbie Wasserman Schultz in 2013 and he has served on the rules committee since 2017 You can't make this stuff up Alexandra Ruecker a rules committee member and superdelegate from California was hired as a senior advisor to Bloomberg campaign last month Ruecker who was previously a lobbyist for the communications workers of America is a vice chair of the California Democratic Party Besides Nutter just one other member of the 32 member standing rules and by-laws committee is Affiliated with a presidential campaign according to a sludge review of the roster as of September 18th 2019 Jeff Berman a DNC member from Washington, DC joined Tom stairs campaign as an advisor in January so there are members of the DNC rules and by-laws committee that are Associated with campaigns and it is both campaigns for billionaires I think that Rashida Tlaib had the best response. She tweeted out in law school. They call this a conflict of interest Exactly. I just I mean, I don't know what to say about this You would think that the DNC After 2016 embarrassed themselves being openly corrupt when their last DNC chair had to resign You would think that They'd at least do a better job hiding the corruption like nobody expected the corruption and conflicts of interest to dissipate but I was naive enough to at least expect them to do a better job at Hiding it being less conspicuous But nothing has changed at all nothing They are out in the open Caping four billionaires wearing on their sleeves Who they support it is Michael Bloomberg because they want that cash and it's just it's morally reprehensible, this is comical like if we saw things like this taking place in In Venezuela this type of cronyism and corruption We would use this as justification to invade outright invade We would criticize other democracies for doing things like this We would you know, call out the oligarchs in Russia who do this and that authoritarianism But the same people who would call that out who have been screaming about Russia working the 2016 election for years now This is what they're up to It's comical and honestly as you can kind of tell by my reaction I'm just not a loss. This isn't in any way surprising to me.  What do you expect? What do you expect from them? Let's just recap what happened over the course of the last week We have individuals in the DNC openly discussing the prospect of bringing back a sudden rules change Superdelegates to steal the nomination from Bernie Sanders You have the DNC changing the rules to benefit Mike Bloomberg. You have the Iowa caucus Just I don't even know how to describe that situation Them spiking a poll at the behest of Pete Buttigieg from the Des Moines register they are just Either put that pathetically incompetent or so corrupt that they are cartoonishly evil But I mean look here's the thing and what I want everyone to come away with is the sense of Victory in spite of everything that we saw transpire over the week Because they wouldn't be doing all of this They wouldn't be going out of their way to find some alternative to Joe Biden, you know Assuming he does fail if they weren't Shaking to the core at the movement that we have built over the last four years They're worried and they should be worried Bernie Sanders is going to win New Hampshire and guess what? Come super Tuesday They may be shitting themselves on national television so I mean The fact that they're doing all of this out in the open tells us that they're scrambling quickly And you know either they're not trying to hide it, but I think the issue is that They don't really have time to hide it.  There comes a point in time where You know, they try so hard and our movement is just too powerful for them to suppress And I think that you know, we've we've reached that tipping point. I honestly do so You know, this isn't surprising to anybody the corruption at this point it is uh, it's just expected from the dnc And the only comfort that I take in thinking about the dnc is knowing that when bernie sanders is elected president He's going to clean fucking house and fire every single one of those ghouls And if you're frustrated now, just think about how pleasant that's going to be when we see the headlines All dnc dismissed That's gonna be great Because the institution is rotten to its core and if i'm bernie sanders I might just dismantle the entire dnc and form an entirely new arm Of the democratic party to uh, focus on elections and whatnot because that institution It may just need to go and may be too far gone.


has become even more apparent since the beginning of the COVID pandemic as we've seen a wide range of services and opportunities move online, including online schooling and virtual meetings. And we increasingly become a digital first nation that has to ensure that everyone has the same ability to access and use the internet to participate in society. So for too long, the term digital divide has been used to characterize the differences in quality and speed of internet networks in rural areas compared to those in urban areas. And there's no doubt that government must up in and invest where the marketplace doesn't support the business case for private broadband investment in any community in our nation. And that's just the start. Studies have shown that within all sorts of different communities, broadband services isn't always available or of equal quality. Certain communities somehow always find themselves at the back of the line when it comes to upgrades to their networks. And it's also disappointing that there's a digital divide between races and ethnicities when it comes to broadband access. While 80% of white households have broadband access, that's true of only 70% of black households and 65% of Hispanic households. There was a Deutsche Bank study that found that black and Hispanic Americans are 10 years behind white Americans in terms of broadband access, severely hampering their long-term employment and earning prospects. And it doesn't end there. Lack of access to home broadband also harms scores and schools and dims the employment prospects of students. So we're here to discuss how best to address these inequities. And it's not as simple as ensuring that broadband networks are built to these communities. It's not just build out. That's a critical first step, but affordability is a major barrier to broadband adoption for low-income communities. In fact, some studies have estimated that of the households that do not have broadband, three times as many of them are located in urban areas than in rural areas. So having a network that runs right to your doorstep doesn't mean that these families can pay the monthly cost of the service. So we came together, Democrats and Republicans in December to pass the emergency broadband benefit, which will provide struggling families a discount of $50 off the monthly cost of their home internet service. That's discount for, is 75 a month for tribal lands. And the FCC is set to roll out the benefit next week. So I hope we can all work together to make that program a success. But again, affordability is gonna continue to be a problem for some families even after that program ends because they may have the build out, they may hook up and they may be able to afford the bill, but they don't know how to use the internet. So they have to be trained. So we have to ensure that all Americans have the skills necessary for themselves and their families for the jobs of tomorrow. So these are all tough problems, but they're problems that we can solve ensuring that all Americans can be part of the digital economy will make our nation stronger, more economically competitive, and will help us continue to lead the digital revolution. And I look forward to hearing from the witnesses as Chairman Doyle said about solutions, how we get there and look forward to both sides of the aisle working on legislation to make this happen. So I think I have about a minute and a half left. I can't yield it back, Mr. Chairman. I have to, I want to yield it to Mr. McNeary. Thank you.


You're here because you want help with basic skills. Let's get started with some that are as basic as you can get. Hey there, njbru22.com here with a new vlog channel today. It's the How To Series. We're going to demonstrate some very easy tips, tricks, and repairs, and general basic information. This is stuff that was once known by everyone, but now it's easily accessible on a moment's notice in the cloud. Excellent. You know, why waste brain space with helpful knowledge and information when you can fill that space with video games and binge watching? It's a win-win, just hit the cloud up. So watch and copy what we do, then you can easily forget about it just as fast as that, and you can fill it up with other useless stuff. But today's pilot episode, we're going to go over a couple basic things. How to screw and unscrew screws. Whoa! And you know, along with that, we're going to cover the ancient history of what clockwise is. Man, that's going way back in time there. And we're going to go also take a stab at some more advanced rotating techniques such as replacing ordinary light bulbs. So let's get started. Hey there, njbru22.com here with a little tutorial to show you how to screw and unscrew a screw. Now while my two-year-old can figure this out just by, you know, simple experimentation, you know, with the modern world and everybody getting things online, people tend to forget how to experiment. So we're going to mess with these two little screws here and we're going to teach you how to screw them in and unscrew them. Now it's pretty simple.  Now however, I'm not sure how many people know what clockwise is because everybody has a digital watch or their smartphone to teach them how to tell time. So I think the clock, now here's a little picture of a clock that shows you which direction time moves in and clockwise, you know, goes basically, I can't explain it, goes clockwise. So if this little clock here doesn't help you figure that out, then here's the screw. I'm going to screw it clockwise. See how it goes in? I'm turning it clockwise. It goes in and to unscrew it, you turn it counterclockwise. See now, counter might be hard to understand for a lot of people. So the big word for doing it the opposite way is anti. So we call it anti-clockwise. Anti-clockwise, you turn it the other way and it'll come right out. And you can use, you could spin the little thing and it comes right out, boom, bada bing, counterclockwise. But maybe some people might need help. So what you can do to practice in your spare time is, you know, to screw in, you can make a little diagram for yourself and that's to screw in and then to unscrew, you turn it the opposite way, which is counterclockwise.  So if that might help you there. So that's how you use a basic screwdriver.  And once you get it down, you know, think about it this way. It's like starting your car, pretend starting your car and this way you could get into the habit of knowing what screwing in is. When you start your car, you're screwing it in. Now wait a minute. Don't most cars now, don't even have keys anymore. They have these buttons you press. Everything's a button now or a double tap, but there's no double tapping here. So, you know, that's basically how you do it. Now you can use the same tactic that you just learned screwing a screw in with light bulbs.  Sometimes, sometimes you'll be over a light bulb. So you got to just don't do it too hard because if you think you're unscrewing and you're actually tightening, you could actually break the light bulb. And another thing to be careful of is to never do it on a hot light bulb. Although many light bulbs these days are LED and they don't get hot, don't get fooled because some light bulbs get over 300 degrees, the old fashioned incandescent light bulbs. So make sure that you wait at least a minute or two before you unscrew in a light bulb before you change it, all right? So keep those little things in mind. Apply the same screw in and unscrew tactic to your light bulb and you should be just perfectly fine.


When you are outside on a windy day, you can help a child learn about the wind. You can talk about how we can't see the wind, but we can feel it and see what it does. Then you can ask, what do you see the wind moving? The child can find things like grass moving, a kite flying, or leaves blowing. Doing this helps the child learn about wind. An important part of the weather and how it affects things around them.


Let's say you're watching a hockey game and the puck goes into the net the goal light goes on But the referee waves his arms back and forth. No goal. Why not? Well, let's take a look at some of the most common reasons that a goal would be disallowed Most of them are pretty easy to understand So we'll go through them pretty quickly like this first one Which says that it will be no goal when the puck has been directed batted or thrown into the net by a player Using something other than his stick Closely related to that one is that the goal does not count if the puck goes into the net as a result of a distinct kicking motion Now the puck can deflect off of a player's skate even if that player is deflecting the puck off his skate on purpose However, he cannot kick the puck into the net As you likely know from the high sticking on the puck roll if the puck makes Contact with an attacking player stick while it is above the crossbar and then goes directly into the net It will not count as a goal Next is that a team who has a delayed penalty on them cannot score unless the other team Accidentally shoots the puck into their own net So in most cases plague it would continue even if a puck deflected off a player of the offending team But if that puck deflects off of them and then into the net Even if they never had possession of the puck the goal will still not be allowed No puck can be deflected directly into the net by a referee This is rarely ever an issue because usually the referees will stand either behind the net or Around where the players are rather than in the middle of play A goal will not count when an offensive player interferes with the goalie in the crease Now for a long time in the NHL players were not even allowed to be in the crease when a goal was scored And while they can be in the crease now the offensive players still have to give the goalie some room Still players are allowed to stand in front of the goalies to block their view But they cannot interfere with them if they are in the crease Closely related to that is that the goal will not count if a goalie is pushed into the net after he makes the save The play is not over until the whistle blows So you might see a play where the puck is close to the goal line Even if the goalie seems like he has possession of it He could still fall back into the net and the goal would count if the whistle hasn't blown yet So basically this rule was saying if the goalie is pushed in then that goal will not count Speaking of the referees and blowing the whistle in the event something happens that prevents the referee from blowing his whistle Right away. Maybe somebody bumps into him and it falls out of his mouth or something like that When the referee deems the play over it is over even if he has not yet had time to blow his whistle On occasion a goal will be scored that goes into the net and bounces out so quickly that it won't be obvious Whether the puck went into the net or hit the post Now when this happens play will continue until it stops for some other reason and then the referees will go watch the replay To see whether or not the puck actually went into the net If the situation were to arise that a goal is scored that isn't seen right away and then play continues And then the other team goes down to the other end of the ice and scores Once the referee looks at the replay to determine that the first goal was in fact a goal then the second goal Will not count Finally if the net becomes dislodged even if it's only on one side Before the puck goes into the net the goal will not count This might seem like it might make the situation easy for a defender to just knock the net off to be safe But if a defender or the goalie is caught knocking the net off on purpose it is a penalty So only when it comes off by accident will the goal not be allowed