They say life insurance is the hardest product to sell in the insurance industry. If you think so, I can make it real easy if you keep watching this video. All right, so I'm going to teach you how to sell life insurance. My name is Cody Askins. I've been selling life insurance for a decade. I started when I was 19 years old. And by using this exact formula that I'm going to share with you today, I earned $117,361.13 in my first eight months. No sales experience. Couldn't spell the word insurance. No product knowledge. But by using what I'm about to show you, it made it easy to earn $100,000 selling life insurance. And it's truly amazing. Okay, so stay with me. All right, so I'm going to go through just to preface this. I'm going to show you, I'm going to go through my benefits presentation. There's five benefits that I'm going to touch on. Okay, I'm also going to go over nine trial closes and three options.  So if that interests you, you definitely want to keep watching. Okay, here we go. So when I'm sitting with the prospect, once I'm done with the warm up and I'm done with the fact finding, which means I've warmed them up, that's step one, check, right? Step two, fact finding. Actually spending time getting to know their situation, asking them fact finding question. That's step two of the appointment process. If you see my videos, then you know what the other steps are. Okay, once I know everything I need to know, and it's time to actually close the deal, I'm moving to step three, which is present and close. And here's what I do in the present and close portion of a life insurance appointment. Okay, because it's time to what? Present and close. So when I jump in, I say, okay, Ms. Betty, I have three options that I'm going to share with you. Okay, and we've actually got Hello, Betty t-shirts that I'll probably throw in at some point too. Okay, but I'm going to walk you through what I do with the prospect. All right, so I'll actually have a blank piece of paper and I will write this down on this blank piece of paper. And I'll say, Ms. Betty, there are five benefits of reasons why that prospects do business with us. Can I share those with you? Right, now that's a trial close. Okay, and like I said, I'm going to go through nine trial closes. All right, so that's number one. Can I share these with you, right? Yes, they've never said no. Okay, so that's the first trial close. You're getting them to say yes. Okay, I'll say, okay, the first benefit, Ms. Betty, is that this policy has a coverage lock. And what I'll do when I'm saying this, when I'm doing this, is I'll write it down, then I will explain it, and then I will ask a question. Okay, so it's a little three-step process inside of each benefit. So Ms. Betty, the first benefit is a coverage lock. What that means is, I'll move into explanation, what that means is that the coverage is locked in. So if it's a whole life, you could say, Ms. Betty, the coverage is locked in your entire life, or if it's a term, the coverage is locked in for the entire term period, which is incredible because there's a lot of options out there where the coverage can change every year, go up every five years, or change when you're 80, et cetera, et cetera. The awesome thing is, is that this policy comes with a coverage lock. It's an amazing benefit that our clients love. Is that benefit important to you? Okay, that's the second trial close after first benefit, and they move into benefit number two. Okay, so write, explain, and ask. I ask, and I move into number two.  I want to be in their bubble. I may move across the living room and sit by them on the couch. I may move over around the table and sit by them. I want to be in their space when I'm doing this. Okay, there's a reason why. All right, so I'll move into benefit number two. Ms. Betty, benefit number two is that this comes with a price lock. And what that means is, the price is locked in the entire time. Okay, there's a lot of options out there, maybe on TV, or through the mail, or with somebody else, where the price will change and go up maybe every year, or every five years, or when you turn 65, or when you turn 70, or when you turn 80. What clients love about us is that it comes with a price lock and the price is locked in. Do you also like that as well? That's a trial close. Obviously, yes, right? That's a third trial close. Then we'll move into benefit number three. All right, Ms. Betty, benefit number three is that this policy comes with, and you could interchange this for any benefit that your policy comes with. I'm going to use double accident, okay, as an example. Ms. Betty, this policy comes with a double accident. In the event that you would have an accident, it would actually pay off double. So let's just say you had $50,000 worth of coverage. If you had an accident, past would do an accident. It would pay your beneficiary, Suzanne, right? You need to already know the name. That's one of the questions in step two of fact finding, okay? That's where if something happened, you do an accident, it would pay your beneficiary, your daughter, Suzanne, $100,000 because it comes with this benefit, okay? Accidents don't happen to everyone. However, it's important that if it were to, it gives your daughter extra money. Would you agree with that? Obvious yes, okay? That is a fourth trial close out of nine, okay? Then we move into our fourth benefit. Ms. Betty, our fourth benefit is that this policy comes with a feature and you could interchange this for any feature that you want. I'm going to use build's cash value. Ms. Betty, it comes with the benefit of building cash value. It's kind of like a savings account within your policy. It accrues money over time. We don't recommend that you take money out of the policy. However, it is building in there and if you wanted to, it is your money and you have access to it, okay? That's pretty nice to know that it comes with that feature, correct? Right? Good. Obvious yes, fifth trial close. We're done with the fourth benefit, right? And then we move into the fifth benefit and it has a part A and a part B. And so what I'll tell Ms. Betty is I'm about to write the fifth benefit down. I'm a little partial. It's my favorite benefit, but I'm going to explain it to you. The fifth benefit, and I'll write it down, is having a local agent. And I'll tell them, there's two reasons why having a local agent is extremely important, right? And everyone always agrees with me, Ms. Betty. The first reason why is that in the event that you need to make minor changes, you would typically have to spend 45 minutes on the phone. You'd have to call somebody. You'd have to call 1-800 number. You'd have to do all these things, jump through all these hoops, even if you just want to change your address or your beneficiary or how you're paying or the phone number on your policy, et cetera. The minor stuff, right? Instead of having to call 1-800 number, spend on hold for 45 minutes. You don't know who you're talking to, where you're talking to them from, and it's a nuisance, right? And nobody likes to do it. Instead of having to do all that, you could literally call my cell phone number and I'll change it for you immediately. That's pretty nice to have, isn't it? Obvious yes, okay? Sixth trial closed and we took care of A, right? Then you move into B. Now the second reason why a local agent is so important, Miss Betty, and probably even more important, this one, is that when that time comes that you're no longer with us and your daughter, your beneficiary, Suzanne, she would typically, what would typically happen, she'd have to call that same 1-800 number, maybe even a different one, which is even more confusing, right? And wait on hold for 45 minutes. Don't know who you're talking to, where you're talking to them from, who knows, right? And she ends up having to get claim paperwork sent out to her from them and also go get death certificates from the funeral home and get those sent in and get everything notarized and make sure you don't miss anything, make sure everything's perfect and try to get that back to them as soon as you can and then hope that you get a check within a matter of weeks or months. When she's already trying to balance and juggle everything that comes with actually going through a funeral and celebrating your life, however she chooses to do that, that's a massive burden. There's a lot to cover, right?  Why would we want to add another burden to her, right? You see where I'm going, Miss Betty? What do you think she would do if she was working with a local agent like me? Right? She would call myself when I'd take care of everything for her. I'd take the burden off of her shoulders and it saves Suzanne time, burden, and stress. Would you agree that that's an extremely important benefit? Obvious, yes. Okay? That brings us to the seventh benefit. All right? Now for the, I'm sorry, seventh trial close. To move into the eighth trial close, what I'll do is, now that I've done all five benefits, I'll say Miss Betty, to get the eighth trial close, because I said there was nine, which of these five, coverage lock, price lock, double accident, builds cash value, and local agent, is most important to you. Can you see what we're doing here? We're getting them in a habit of making a decision, choosing, saying yes, picking for you. You want to train a prospect to make decisions when you ask questions. All right? And if, and if, what I'll do is, typically, I'm going to walk you through this. Miss Betty, which benefit is most important to you? Well, what are they normally going to say? Hang on for a second. What are they normally going to say? Three words. I don't know. When that happens. Well, Miss Betty, if you had to choose, which one would you choose? Works like a charm every time. I promise they'll be choosing then. Well, if I had to choose, probably price lock. Okay, great. Right? I'll circle that one. Excellent. It's extremely important. Right? They made a decision. That was the eighth trial close. Then I move into, or actually show them the options. All right? So I'll have another piece of paper. All right? Or maybe on the back of this one, to where I've already got the options spelled out. Maybe I've got 50,000, maybe I've got 30,000, and maybe I've got 10,000, for example. Okay? You could have any options, but maybe this one's 110, maybe this one's 84, and maybe this one's 61, for example. Okay? Now, there's a reason why they're laid out this way. I'm going to go back to walk you to this point. There's a reason laid out this way. Number one, you want to always have the three options from the largest to smallest. Very important. The psychology is, oh, wow, that one's, when you go from large to smallest, oh, wow, that one's good, and the other's pellet comparison. Okay? Or the other psychology is, if I were to go from smallest to largest, it would feel like, oh, that one seems fine. He's trying to upsell me. Right? So that's why we don't do that. Okay? The other psychology behind it is I show one option that's always over $100, a month, no matter what. Okay? Now, if you know what they need and you can develop three options around what they need, then price doesn't matter. That's why in step two, a fact finding of the appointment process, I don't ask what can you afford. What's the best price? What do you want to pay? It doesn't matter. You sell life insurance based on need, not based on price. Okay? Now, I like 180 and 60 because most life insurance sales people undersell themselves. Now, if you want to show bigger options and show based on need, that's even better. Okay? But I'll set that up. And what I'll say is, all right, for the nine trial close is Ms. Betty, I'm about to show you three options. Okay? We're going to get to the close. We're going to get to all of it. This is freaking gold. If you don't make 100K views in this, then you didn't get it from enough people. Would you agree? Another trial close, right? Okay. Now, what I ask Ms. Betty is, Ms. Betty, I'm about to show you three options. And I already know which one you're going to choose, by the way, Ms. Betty. But I need a favor from you. When I show you these three options, which are fantastic, they come with all five of the benefits, especially the price lock, which I know you loved. When I show you these, I just need you to let me know which one makes the most sense to you. Can you do that for me? Obvious, yes. Okay? Ninth trial close. I turn over the piece of paper that would look like this. And I'll say, okay, Ms. Betty, here's the three options. Okay? First one's 50,000 for 110K. 30,000 for 84. And 10,000 for 61. Which one are you most comfortable with? That's the close.  And if you've warmed up well, if you fact-fined it well, and if you've presented the benefits and the value well, when you get to the close, it is sold and they will be making a decision. Okay? If they say, hypothetically, if they were to say, well, I'm not sure. Well, if you were going to be doing one, which one would you do? You see the hypothetical the if? Well, probably the 30,000 because 80% of the time they choose the one in the middle. Fantastic, Ms. Betty. And now here's how you continue. Excellent. That's exactly the one I thought you were going to choose. Let's see if we can get you approved. What's your full legal name? That's it. Right? Anyone can be trained to do this. Anyone. I also have another video on how I talk about it. If they say I want to think about it, or if I want you to call me back, I also address that too. Right? But I'm not going to address it on this video because this was simply how to present, how to close, how to sell life insurance in the most amazing way ever and how you can earn 100K selling life insurance when you use this. When you make your first 100K, when you use this and it freaking works, come back and let me know in comments below. If you love this and you want to do it without semen pushy, the next video is right there. It's for you. You're going to love it. Click on it and I'll see you there. I'm going to talk about the five easy ways to prospect without being pushy. I truly believe that, yes, I may be aggressive in sales, but I do it in a respectful way that doesn't feel like it.


Who's going to win the finals? This is how I thought it was going to be the Nets, so I ended up being a really bad choice. Now I'm thinking, let's, let's, I don't want the Warriors to win, but maybe the Warriors. Damn, who's the Warriors? Uh, the Bucks, the Warriors. The Warriors, the Warriors. I want them. Warriors, uh, Curry, uh, the Warriors. Well, I was going for the Pills, now I'm going for the Sun, because I saw them play live and I was the court size of the Sun.


From Korea to Germany, from Alaska to Puerto Rico, all over the world, the United States Army is on the alert to defend our country, you, the American people, against aggression. This is the big picture, an official television report to the nation from the United States Army. Now to show you part of the big picture, here is Sergeant Stuart Queen. Today we bring you the story of America's newest weapon in her arsenal of defense, the guided missile. Portions of this story were filmed in secrecy and now have been declassified. In order that you, the American people, might know the progress that is being made in the field of guided missile research and development. The never-closed picked up and are tracking unidentified bombers. Any attack on our nation would first be met by the Air Force fighters for shores, but some of the attacking bombers may still break through, flying above the range of our best anti-aircraft guns. Vital seconds tick away as the aggressor planes are plotted on course. To halt any such attack, the Army has a new secret weapon and you will now see a radio-controlled plane intercepted. On the bridge in the plotting room, artillery control officers set in motion, operation intercept. Battle station. Flash. Missile to failure. This is landing. Intercept. Back number 9. 340,000. Out. Intercept accomplished by guided missiles. Rocket-powered weapons flying at supersonic speeds, destroying unseen targets are no longer science fiction, but are today a military fact developed after years of research by Army ordinance. To defend our cities, guided missile battalions are being organized and equipped and will supplement anti-aircraft defenses in the near future. The history of guided missiles began with the invention of rockets. Man soon learned that rockets could be used in his everyday life, but for many years the potential of this new power went unexploited. But a few visionary scientists, often scoffed at by the public, went ahead with their ideas. By diligence, mistakes, and greater effort, rocket pioneers made progress. Slowly, they were harnessing this tremendous power to the things around them. It was an historical moment when the first rocket plane was launched. The vision and skill of men like Zucker, Sonder, and the American Goddard, produced bigger and better rockets. But for every success, there were two failures. The way had been pointed, and men saw, not too far distant, the day when rockets would capture outer space. But World War II stopped all peaceful pursuit of rocket development. Masterminds in rocket experimentation, the Germans were quick to see the potential of rockets as weapons. Their scientific skill produced the V-1 bomb, and a new era in warfare was born. The V-2 guided missile followed, but only after many mistakes, as these captured German films of early rocket launching show. At war's end, Army ordnance brought back to America about 100 German rockets and some of the scientists who had built them. In our Army proving grounds, the old German rockets were put to work for research. In them, our military strategists saw the shape of weapons to come. Now after eight years of research, today's spectacular guided missiles have joined our arsenal of defense. Behind these amazing weapons are the well-trained rocket missile crewmen, not all college boys with scientific degrees, but soldiers of average backgrounds, men trained to launch the missiles under combat conditions. Rocket crewmen are trained in guided missile schools at Fort Bliss, Texas. From all branches of the Army, there are being drawn for special guided missile training. Recruits soon learn that this new assignment is different from anything they have known before. From now on, they will be living with secrets. They are cleared for top security, for in months to come, they will share some of our nation's most closely guarded information. At an orientation lecture after their first day in school, the men learn why they were chosen to be missile crewmen and what lies before them. You're probably wondering why you're here. Well, there's a very good reason for it. You're not here on a shortcut trip to the moon or learn how to fly a spaceship. You're here to receive intensive instruction in one of the Army's latest and deadliest weapons, the guided missile. Although you've come from all branches of the Army, your service records, which have been very carefully screened, clearly indicate that all of you possess the necessary technical and mechanical ability to become experts in handling guided missiles. During the next 11 weeks, you will receive intensive instruction in the field of guided missiles. At first, the missiles themselves and the control components that go with those missiles may seem to you to be highly complicated. However, with the classroom instruction that you will receive, coupled with the practical work on the actual equipment, you'll have no difficulty in thoroughly mastering your jobs. The field that you're in is a somewhat new field that you will find to be both challenging and highly interesting. The opportunities before you are almost unlimited. I urge you to make the most of them. Thank you, men. Class dismissed. The road to becoming a rocket crewman is a long and technical one and begins with a three-week evaluation course in basic mathematics. Students must also take an elementary course in electronics, and they must struggle with the principles of physics. After basic training, the student rocket men are divided and classified as electronics men or propulsion men. Then they are assigned to the missile which they will learn to operate and fire. The surface-to-air missile, Nike. Sleek, beautiful, deadly. An ingenious anti-aircraft artillery piece. Trainees remember their first good look at a guided missile. Security checks follow them into the hangar, where Nike, a weapon of tomorrow ready for use today, is stored under guard. Ask what they think as they see the missile unveiled for the first time. The men invariably answer, it's like nothing we've ever seen before. Up to now, these men have seen rifles and machine guns and tanks, but this kind of weapon is beyond their imaginations. It travels at a speed far greater than sound, piercing the supersonic barrier. It has its own electronic brain which can steer it straight onto a target, all by the press of a button on the ground. This is a weapon bordering on the unbelievable, Nike, named after the Greek goddess of victory. With it, the army can now destroy aircraft, flying outside the range of anti-aircraft guns, radars find the target and plot its course. Then the electronic brain on the ground computes a point of intercept and guides the missile to its target. But for all the mechanical and scientific genius of guided missiles, they are only as good as the men who will service, operate and fire them. It takes a lot of men, highly skilled and trained, to complete the guided missile team. Launching specialists, guided missile mechanics, propulsion experts. It takes men who understand electronics, men to work the radar, nerve system of guided missiles. Trainees work hard. They must know the workings of jet engines and how to check the complex insides of a missile. Soldiers with engineering backgrounds take a specialist's course in guided missiles, which is more advanced than that taken by the crewman. These are the men who will be guided missile instructors, the men responsible for keeping the missiles in firing order, qualified to troubleshoot and diagnose malfunctions. They are the engineers and brains in support of the launching crewman. When they go on their first bird shoot, that's what crewman call a guided missile launching, the men no longer consider themselves rocket rookies. For practice launchings, the men fire obsolete V1 rockets brought from Germany after the last war. Maybe they aren't the latest thing in guided missiles, but they give the propulsion men who are called plumbers a chance to prepare a rocket for flight. And for every plumber at work on the bird, there is somewhere an electron man checking some wires. Artillery officers, hand-picked engineers in training to be unit commanders of guided missile battalions, undergo their own field training as part of their long course in guided missiles. Week after week, the training continues and hundreds of hours of classroom theory slowly turn to fact as the men become familiar with guided missile operation. The missiles grow more complex. The complicated guidance systems must be checked and rechecked and the special procedures for fueling must be practiced. Protective suits give the soldiers a men from Mars appearance during the fueling of these super rockets. Carefully, the fuels which will hurdle the missile into atmosphere unpenetrated by man are pumped into the rocket. The target for this practice firing is a small radio controlled plane which takes the place of an enemy target. The plane is flown by a crewman on the ground. With target in flight, the missile is raised and then launched. At Army Ordnance's White Sands Proving Ground, deep in the New Mexico desert, crewmen finish off their training using the latest tactical missiles science can produce. After months of preparation, the crewmen now handle and work on the real thing in the research and development stage. These are missiles capable of carrying atomic warheads. Readying one of them for flight is an engineering miracle in itself. There can be no mistakes. One wrong move, one misplaced screw or wire could sabotage a missile costing thousands of dollars. Electronic circuits must be checked. Guidance systems must be in trigger operation. For this to be a successful launching, hundreds of electronic sequences must be run through without a single hitch. At a speed which must still remain a secret, the missile rockets into the ionosphere eclipsed by the sun on its journey into space. These are the forerunners of rocket ships to the moon. And an idea of what space travel of the future will be like is vividly depicted in these films taken from a rocket in flight. The takeoff is smooth and through the motion picture camera, an armchair trip into space begins. Slipping away below can be seen the white sands of New Mexico and the mountain ranges holding in the Texas and New Mexico desert and up the rocket flashes traveling at a speed many times greater than our fastest plane. The high speed camera slows down the action to bring this startling view of the earth and the mountains of the continental divide pass by like whistle stops has reached its summit 76 miles up. This is the highest distance at which the earth has ever been photographed. Tipping and spinning like an inverted top, the rocket starts its descent to earth. One minute pointing at the sun and at the earth the next, the camera sweeps across the lower length of the continent, giving man an unprecedented view of the planet he calls earth. Many guided missiles are pioneering the way into space. But these soldiers are training to handle a weapon and not a trip to the moon. Behind closely guarded doors, Nike missile crewmen assemble the weapon they will later fire from the manufacturer's crate to actual launching and listed men build and check the wonder weapons. A missile is ready to take part in a research and development test firing against an actual plane in flight. From the hangar where it was assembled, the Nike missile is taken to the transporter, which will carry it to the launching area. But first, the missile must be fueled and it stops off at the fueling area. During fueling of the missiles, crewmen wear protective clothing just as they did in their training. This protection permits a safe fueling operation. And right up to the time of firing, elaborate and extensive safety precautions are observed. The missile is now hot. It is fueled and ready for flight. On the last stage of its journey to the launching pad for its research test firing, this missile is escorted the last few miles by a fire truck. Just before the test shoot begins, the missile is joined to its booster. This assists the rocket at takeoff and helps it reach supersonic speeds in a matter of seconds. With the missile now firmly fixed to the launching rail, it has moved into the firing position. Last minute adjustments are made. As the last safety pin is pulled, the firing operation begins. All stations, this is Nike project command. At my signal of time will be x minus six zero minutes. Mark x minus 60 minutes. A red smoke signal is set off on top of the blockhouse. Inside the men stand ready at the command controls. Should a hitch occur, the firing process can be stopped with the press of a button. The status is now ready. The minutes take away and from the blockhouse a warning flare is fired. And all over the range roadblocks are set up to keep everything out of the firing area. Three miles away at the control center, the target tracking radar is fixed onto the plane, which is to be attacked and is sending its position data to the computer. In a split second, the computer works out a point of intercept. The atmosphere at the fire control center is tense. The project officer is ready to throw the switch. All stations, this is Nike project command. At my signal of time will be x minus 20 seconds. Mark x minus 20 seconds, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6. That's the story of the guided missile, a new weapon of defense of the artillery's anti aircraft battalions. And this is Sergeant Stuart Queen inviting you to be with us next week for another story in the big picture. The big picture is a weekly television report to the nation on the activities of the army at home and overseas produced by the signal core pictorial center presented by the US Army in cooperation with this station. You can be an important part of the big picture. You can proudly serve with the best equipped, the best trained, the best fighting team in the world today, the United States Army.


Hello everybody. Thanks for joining. We'll talk about security-minded development today and let's see. This is a new experience for me representing remotely. So, bear with me. So, let's go ahead and start. My name is Shua. I'm Linux Cardinal Fellow at the Linux Foundation and then I have been looking more into security-minded development and then I want to share my thoughts on that today. Let's see.  So, it's kind of in line with what we're talking about anyway. So, let me see. So, what is security- safety-minded development all about? We want our systems available and dependable. Like, for example, we are chatting today and we have a lot of infrastructure helping us do so. We want our laptops working, our phones working. They dependable. When we pick up our phone, we want to be able to make a phone call. Not just that. We want to be able to read news, connect to the Internet, take pictures, upload pictures from wherever we are. So, all of that happens because we have systems that we can rely on, systems we can depend on and they are responsive as well. And we also want our systems to be resilient to remote and local attacks also. So, all of this combined gives us this experience of being able to do what we do in our daily lives. And then also, furthermore, we want our data to be secure as well. We want our data to be accessible wherever we are. We want to be able to access our pictures or data or when we are traveling, for example. All of that we want to be able to also share with trusted entities. At the same time, we want to keep it safe as well. We want to be shareable and safe, safe from corruption, safe, secure from unwanted inclusions. So, that, so, all of that in mind. So, what are the things that will stop us achieving our goals? Because we are worried about software related. This talk talks more about the software related issues that we can, we encounter that prevent us from achieving our goals of keeping our systems safe, available, and all of the things we want to do with our systems. So, let's briefly look at what are the some of the vulnerabilities we encounter. Heap overflows, integer overflows, stack overflows. And then we also have privileged information leak. In term, in the form of cardinal addresses could be leaked. And then also messages, we can leak them in messages, de-message, and then also APIs. Like, for example, we might inadvertently expose them in CISFS interfaces. And then other things that prevent us is vulnerabilities is we, sometimes, as we are writing our code, we might not be doing sufficient error and boundary checking on the data that's coming in, or just the data that we have, user data that's coming in, and we could be not range checking some of the stuff that's coming in. And then, so, out of bounds access. Those are all the things that we could encounter. If we have all of these vulnerabilities, what we are going to be able to be susceptible to somebody exploiting those, intentionally or unintentionally. It's not always intentional even. So, more on vulnerabilities, memory leaks, use after freeze. We might be using variables without initializing them correctly and properly. And then, also, we could be seeing unsafe arguments, data from user space, in form of input arguments to system calls, eye octals, and then also in the form of network packets. The data could be coming in into protocol packet layers in the packets, USB, and then network. So, what these stand in the way of us being able to keep our systems available, dependable, and safe, and then also even our data. So, we want to be able to, we want to make sure that our systems are not vulnerable to unauthorized access, for example, and then leading to us losing, we could be losing data, we could lose access to our systems, and so on. So, what do we do to do some of the ways that we counter these problems is we use fuzzers, we use regression testing, we use some form of static analysis, and we scan for vulnerabilities. We do all of those things, and then we find and fix regressions, and we kind of are in the mode of figuring out what could go wrong, and we identify vulnerabilities. We keep all of these methods give us that ability to, we are kind of in the mode of looking for vulnerabilities, right? We are trying, we try to harden the kernel code paths, and we're using all of these methods, like when we introduce new features, we go and make sure that we haven't regressed anything, we haven't introduced any new vulnerabilities, new bugs, new problems. So, all of this, we do all of this. So far, all of the things we talked about, fuzzing, regression testing, and scanning for vulnerabilities, and continuous testing in integration testing, all of the activities we do, they are all in the fall under the cure type activities. We are reacting to things that potentially happen once we release our software. So, could we do more? Could we do focus a bit more on prevention as well? Could we do, could you, could we understand, based on the data we're collecting, right? Fuzzers give us some idea on what kind of bugs are escaping us, and then the scanning vulnerabilities, that shows us some indication of what kind of things are escaping us. So, could we use that information and say, can we understand the common design aspects and coding mistakes we make? Or what other activities we can do during the development process itself to avoid and minimize introducing new bugs and vulnerabilities, and kind of also make sure that we are taking precautions instead of being proactive as opposed to reactive. So, let's see. I will talk about some of the things that we could be doing during various phases of development itself. So, as we are writing our code, sometimes we introduce debug messages, for example. We might be giving away more than what we intend to during development. So, do we make sure, once we are done with our testing, we make sure our feature is working correctly, do we go scan and say, hey, did I leak anything? We have some helpers that now help us. Person P won't be, we don't actually, the cardinal addresses don't actually get printed. So, we learn that. We learn that saying, okay, we want to make sure, we also want to put those kinds of common helpers in place as well, as we are going and designing our software and we are learning from the mistakes, learning from some of the things that, some of the bugs, actually the fuzzers and such show us what we could avoid in the future, what kind of proactive steps we could take. So, and then checking input arguments, it's the best practice anyway. It's not, it's not, it is part of the, error checking is part of the code paths. So, the problem with error checking sometimes comes into play is that we don't, when we, when we are doing feature testing, we tend to focus on, more often than not, we tend to focus on whether the code is working for a sunny scenario. So, we should also be focusing on error checks, input arguments, boundary checks and so on. And then more importantly, as, especially when the data is coming in from the user space, we want to make sure that we sanitize those input arguments. And especially, like I said before, in addition to paying, say we are focusing 90% on sunny scenarios and 10% on error paths, we want to make sure they are balanced as well. Error paths, paths tend to be sometimes are the, and cleanup paths especially. I'll show, I'll talk through some of these examples on what I found, but when I found, we don't seem to pay as much weight to error and cleanup paths when we are testing our software. And avoiding repeated mistakes, like for example, if you have a helper that can sanitize input arguments, for example, use those and look for the common helpers that you can use and maybe look into adding common helpers as you need to the code path if they are missing. So, I want to focus a little bit on unsafe data. And in the three aspects of it, possible causes and failures and mitigation. Those three things I want to focus on for this, for this talk, unsafe data, what are the possible cases? I kind of alluded to that already, that we have, it could come in in CISFS, for example, iOctyl, system calls and network packets, user space and USB packets and the data that comes in. And then it could be malicious, it's not always malicious, it could be an unentered application bug, for example, that could result in us getting unsafe data. So, what could unsafe data do? It could force kernel to allocate large amounts of memory and it could panic the kernel and it could also, it might not do about two, but it could go, we might see a responsiveness issue or it could drive us to get us away from the deterministic paths and then other kinds of undesirable behaviors. Maybe it could lead to, it could have a memory allocation, for example, that could lead to performance problems. And then a potential exploitation of Spectre variant one we have seen in the past. So, unsafe data, well, if you run out of memory, you won't be able to allocate memory, then you are really in a situation of the system out of memory conditions that could be leading to performance problems and so on. And then you could also potentially lead to service interruptions, data corruptions and loss of execution of control as well. Like your system won't be available. So, you're hitting all of these, it's preventing us from all of our goals of our systems being available, dependable, reliable and resilient to attacks and then our data not being safe. So, all of these just looking at this one example of vulnerability, we could be compromising our systems. So, let's go look more into this. I picked examples to show. So, these are all the examples, some of the code fixes that went in. What could have been done, the illustrates. So, let me see, I'm going to share this screen with you. Let's see if my screen sharing works well enough. All right. If you are seeing USB IP fix a stub, then my sharing worked very well. I hope it did. So, in the previous example we have seen this is a user space data coming in and it comes in as an endpoint. So, in this particular missing error boundary checks on these endpoints resulted in a bug on and a panic. So, if you look at this fix that went in, really this is a simple fix that could have been done before. If you think about the error return, you check the endpoint values and then you go into just handle the data, handle the data that's coming in. So, back to looking at the next error that could happen. I want to go through a few of these to give you an idea on what could happen if we and then we can talk about how to mitigate this. So, I'm going to show you one more. So, this particular one error you'll see from highlighted the diff that not checking the buffer length that should be allocated, buffer allocation. So, if you missed the rain checking on this, you could allocate large amounts of memory. This is also another vulnerability that was found and fixed. So, these are all found. These two particular problems were found by modifying a user space store. This is the data coming in. One could easily inject errors. It's memory. It's found you modified tool to inject errors. So, the next one I'm going to show is null transfer buffer issue. So, I will share my screen again. So, the one here, the transfer buffer could be null. And if this particular variable, if you do not check that, you will run into problems later on at a different point in time. So, the fix to this problem is really say it could be a potential malicious packet coming in and you will, if you do not have the checks for this, you will, this will result in referencing null buffer at some point down the road. So, by adding checks, you are preventing that kind of errors. So, what I'm trying to, what I'm emphasizing here is there are some precautions we can take while we are developing the code, while we are paying attention to the error legs and thinking through what could go wrong as a part of our, part of our development process itself. Pay attention to it during that time. This second one, this one is another example of unsafe input argument use. So, this particular one was found vice is color and let me share my screen again to show you. So, this particular problem, this could result in an interesting issue. If you were to, if you were to not check for this length, length of fat file system, then you would overlap, overlapping root directory with fat entries. So, what happens is you would, you want to, this is an invalid entry. So, you want to make sure that we do not allow mounting file system. So, you would be mounting a file system with an invalid format. So, just this could result in potentially overlapping your root directory and cause your, your date. It could even lead to errors that we, in deterministic behavior and then data corruption and so on. So, both, so you really want to check this error before you mount. It's great that CSIS color was able to find this problem, but we could have potentially avoided it if we were to use static analysis tools perhaps and so on. So, let's see the next. I'm going through a few of these to, I started to examine a few of these to see, I'm kind of focusing on what can we do for prevention. So, this is all in the prevention area of, of looking at these, examining these bugs and what we are finding using CSIS color. Can we use that knowledge back into the development process and see if we can use what we are learning from? So, sanitizing input arguments. This is another problem that was found and fixed. We, I think this, this, this we found and fixed in various subsystems, including this particular one that happened to be in the USB IP driver. Like for example, you're getting these, it's a, it's, it's, sometimes it's not enough to, we want to make sure that you're, you're range checking, but you don't want to, you want to range checking happening. And then also you want to, so that this, the speculation, the, we don't speculate ahead of range checks. So, we want to make sure range checks happen. And then we, this is a helper I was referring to, another helper function that helps us check use of, so that we don't speculate ahead of, ahead of the range checking. So this will help us, this is again, falls into the category of boundary checking. And this one was found using SMATCH. So, SMATCH, so this is one example where we could be using these tools that we already have in the Cardinal that we can use to avoid introducing these kinds of bugs in the first place. So finding them and before we get into, needing to react to these bugs. So next slide. This particular one was found using Cauchy Check. Cauchy Check can, this is, this is a, I'm sharing my screen again, to show you this particular example of what we found using size of struct. Like for example, this could lead to, instead of leaving these kinds of open-ended checks that are prone to type mistakes, we can use struct size. There has been effort to go and fix these problems. Gustavo has been doing, fixing several of these things found proactively using Cauchy Check and running Cauchy Check and finding these problems and then fixing them proactively, so that we are not vulnerable to these things. This is one example of a proactive effort to fix the problems before they happen. So let me see how I'm doing on time. I want to be able to leave some time for questions as well. So this is, this was found using Syscaller and fixed in recent, I think it's 5.8, fixed in 5.8. And then let me share the screen again to talk about that problem. So this, this was fixed, this is an error check example. For example, we could have fixed error check. This alloc per CPU may return error null, which means that you, you might have a variable set to null. So if you do not check for error, then you are looking into a condition where you would trip into it at some point, like Syscaller found. So this problem, at times what happens is, I'm finding as I'm going and looking at these things, at times we optimize the code, meaning we, we optimize in the sense that we'll go and look at error paths and say, hey, we can make these error paths simpler. And we make those simpler and then we use a common routines. And as a result, we are changing the code path slightly. And then we could run into an issue of, because of the changes that we make, we might be introducing problems at times because, so this is again, this, this fixes, if you look at this fixes, this is a optimization type or when we go and add a new feature, we don't, we might have missed an error path that we newly introduced error path that we should be checking for. So this particular is, is a good example. I think that we, if we were to pay more attention to the error legs, we might be able to think through and pay attention, more attention to the error legs, as we are writing code, we might be able to avoid some of these problems. We cannot guarantee we will, we won't go out without problems, right? Software always problem. We will have problems. There is no scenario where we won't have any problems. But it's, it's, that's where the security-minded development, if we may be thinking about what could go wrong and looking for ways to mitigate that proactively, we might be better off. So let's go to the next one. Another one example also, example of error and cleaner paths. Again, that's my going to be the, I'm identifying some of the things and sharing what I found with error paths. Sorry, I'm sharing the screen here. Another one of these. So in this particular one, we, so the K, this is also introduced, it's an error path again. So you have a memory leak when we K object in it and add returns an error in the function call. So this is a case of missing, we are missing a K object put in this case. So we are kind of leaving open of the, not releasing a resource. So this, this is potentially, so I've been thinking about, we have to think about how we can prevent these in some cases, we might be able to, we look for existing ways to scan for these using, we found this with syscaller. That means we, found it after it's been applied to a tree. So could we find this before or could we find this during, during our testing, feature testing, or as we are testing, can we go and look and see, hey, can we, what are the error paths? Again, my example of 90% of sunny scenarios, 10% of what is our balance of sunny scenarios versus error scenarios. I think that would be helpful if we could focus on some of that. So let's go to the next one. So this is a, this is a cardinal panic that was found by syscaller. And let me share my tab again. These are all fixed by the way, they're coming in from the fixed source. So it's all in the release 5.8. I probably went into 5.8. So if you look at this particular one, this is an integral for a situation. You'll see this max logical block is defined, just defined incorrectly.  And then you, so you're starting, you, this has to be within the range of not overflowing logical blocks.  So it's again, falls into the same category of unsafe data and not validating the data properly that we are getting from the user space. So before we use the values that we are getting from the user space, we want to make sure it doesn't send us down a path where we are, we compromise our systems. So now, so, so far we have been seeing all of these cases off, you're seeing all of these cases off error paths, and then not being not checking the boundaries correctly, not checking what could happen if we, if we, if we don't think through these error legs. So some of the takeaways, so I want to encourage in investing time in different defensive designs. I am more and more doing that as I'm writing code, I'm looking at what could go wrong type defensive designs. And if you are, especially if you're starting to use, use common routines, pay more, sometimes we go and change a piece of code and say, hey, I have this common routine, common helper I can use. Sometimes when we do that, we have to think through what are the implications of using this common routine here, and how does this change my error leg path, error paths. So we have to think through that. So that's what I mean by defensive design. When data comes in, we want to make sure is this data safe for me to use, is this user data either coming in from USB packets or network packets or any iaktals, any kind of interfaces, is this data something that could send me send us down the path of panics or memory leaks allocating large buffers of large buffers of memory. And just think about, think through how you can do defensive design. And then static analysis. I am starting to use that when I accept patches and also review patches in some cases. I'm finding in one case, I found a duplicate flag defined, which could be caught. I don't think I could have caught it with just code review because it was a large define. So two sections of a defined struct defines that was defined. And then is a duplicate flag in there that I was able to catch running catch check. So I'm starting to do some of that. And then we have various efforts that go on. Dan Carpenter does a lot of work with S match and sparse errors. And Julia Leval does catch check. And a lot of people are now I'm starting to see fixes coming in for catch check findings. We catch check finds a lot of, if you go and just look for catch check found problems, you will see a large number of them. So I'm starting to more focus on prevention aspect of it. So I am putting effort in to running catch check myself on various parts of the kernel I maintain, as well as other parts of the kernel to get a feel for what we could be doing proactively in avoiding problems like this. So detention detection and testing during development. So do you have a ask yourself, do you have a test for this for a new subsystem or a new feature you might be adding or a fix you anything apart part of the code kernel code you're changing. So is there a test go look for a test if you if there is one, if not try to see how you can write a new test or see if you can enhance a existing text test for it for that matter. And error paths are tricky, because we have to proactively inject errors. Sometimes I force my code paths when I introduce I actually introduce errors in their error injection, we have to look into also error injection, you can force sometimes errors, inject errors and look into how you can write maybe error error injection tests. This is what is a great example of that. That's kind of what it's doing, right? It's injecting errors. First testing. There are some error paths you put probably lightweight code paths you can make sure that you are injecting errors in a lightweight fashion than maybe sysbot. So think through and see what you can do to test your code, error paths especially and also making sure error paths automatically implies that you are testing for unsafe data and then handling that error in your code. So I'll leave you with I'm almost getting close to the end of it. I want to leave you with being mindful of error and cleanup paths especially and then testing with at times initialization run times can be easy to test. Error paths is something that are prone to like for example you might have memory leaks due to you're not releasing resources correctly when you are cleaning up. Say your driver initializing hardware failed or your driver you're loading a module that failed or you're initializing your driver that failed but you have to unravel the go through the cleanup path and release all the memory. Are you doing that correctly? Are you do you have a unbalanced lock acquire lock release kind of logic in your error paths? So do you pay attention to that? Then you can also when you are testing make sure you turn on all of the debug awesome debug options we have in the kernel. We have tons of debug options in the kernel. For example, config debug spin lock and prove locking make sure you test with those enabled for testing purposes to make sure that you are going into the mode of detection. And then I'm not listing all of the options we have tons. For example, if you enable config case on which I do in when I'm testing even stable release kernel sometimes I want to make sure the paths are correct.  So they and this is a good example of connecting the dots connect the dots for effective testing, right? I mean, you know, we have sysbot effort happening syscaller effort and adding a recent work that went in adding cake of hooks for collecting coverage and facilitate coverage guided fuzzing with the syscaller. So there are opportunities here. I want to thank Andrea for doing this work and then collecting it. This is kind of a you are figuring out, okay, I have this scholar. How do I connect my module? So it's let's find these kinds of ways to increase our coverage and cover testing coverage. And then also it improves our chances of finding problems proactively. So we have several resources for regression testing, kernel self tests. We have several of those. There is a lot of work that have since every release, we are adding more and more tests. And then sysbot reproducers, these reproducers, I have been maintaining, I get those from Dimitri and then I upload them into Linux Arts, the next auto generated regression test repo, which I maintain. And it is up to date as far as as of I think we have all the syscaller, sysbot reproducers came in until March of this year, I think. So I keep updating it once in periodically. I go get them from Dimitri and update them. And so use those. Those will be your regression test. There is a run script that Dimitri wrote. He has he and it's seeing more work in that space. LTP, they are using that in LTP testing that they have, they download the Linux Arts kit and then run those. So there is a lot of activity happening in this space. But think about that as you are writing and contribute to these activities as well, which will help. And in all of our developers, kernel developers keep adding tests to kernel self tests. So use them and expand the tests and keep the keep secure defensive, proactive approach to writing code. So with that, I'm done with my talk and I have I have about 10 minutes for questions. And then if I can't answer all the questions, I have a session tomorrow as well in the afternoon. Right, let me see. So I have a few questions. How is, I think that's the that's the first one here. How is kernel.org planning to use static analyzer online documents? Let's see what this question, it's a long question. I think the, bear with me, I'm increasing this window size so that I can read the question correctly. How is kernel.org planning to use static analyzer options? And specifically, don't know that that falls into the category of kernel, you kernel.org category. This, this is a, you see, this is a measure static analyzer method that is outside. I'll have to get back to you. This question came from Joy. I'll get back to you Joy on that. I'm sorry, I'm reading these questions. Let's see. Okay, would you recommend running, for example, syscaller in a nightly suite? Should we run 800 times? Then that's enough until we add more patches. What does throw and do diligence? So, yes and no. I am, what I am, I think saying is that it's testing and also development. What can you do during development? I'm more focusing on being able to, yes, running syscaller will help you in terms of regression testing for sure, and that we are not introducing any new problems. What I am focusing more on this talk is more on how can we prevent problems also. And based on the learning from the fixes we are putting, we are, what we are fixing. Can we learn from the fixes? Some of the things that we are, syscaller is finding and what fixes we are putting in. So can we learn from those experiences? So that's, I think, yes, due diligence here is running syscaller definitely will help finding problems. Let me see. Sparse is great. It can even indirectly find security issues like complaining about global variables. Right. Yes, that's true. So that's, that's really, I think that's, that's my message in this talk saying that let's use what we have. We have sparse, we have a Kotch check, we can expand, we can write more scripts, Kotch check scripts to find more problems. We can, we can use our existing tools as we improve them to proactively look for problems. So how do you see security being increased by compiling kernel with Clang? You know, I do not know. I don't, I myself do not use Clang. It's been on my list of things to do to see. It's, it would be a, if I don't know much about that in terms of the security being increased by compiling kernel, I would like to understand that for sure, more. And I'm also, I'm not necessarily just focusing on security in this. I'm also focusing on overall dependability as well. So security, like I mentioned in the talk at one point, I was saying that the same problem that could happen in the kernel, with unsafe data coming in from the user space that can be malicious, it could be unintended application bug. So I'm kind of focusing more on dependability of the software in stuff, looking at security versus safety, security, related focus versus safety, the reactions, even though the outcome might be the same, the way you, the same set of problems could fall into both categories. So you're looking at it from just the example of unsafe data. It could be malicious or unintended error. So I have one more question here for checking security in test strings. What about using? Yes, scanner tools. If you noticed in my, in my slide, last slide, I don't have any scanner tools because I haven't really compiled a list of them yet. I am, I also am focusing on what we have in the kernel at this moment. That's a good, good question. I haven't done enough research in the, what kind of scanners we have available to do vulnerability scanning. Let me see. Using Clang, somebody commented using Clang is basically giving you a different interpretation of the C standard. So if you compile something with GCC and Clang, and one of them has a compiler warning, you may want to fix it. So both compilers are happy. Yes. Yeah, definitely. Using Clang and GCC will definitely give you two different views of the code you have. And I'm glad that we have enough users, current developers that use Clang now. And then we also have GCC has been used. So it's good that we are focusing on both. It is on my to-do list to do. One day, I'll, based on my bandwidth, I'll probably will start experimenting more with Clang. I haven't been able to. So that is mostly all the questions I have. We are almost out of time. Can I get access to these questions so I can choose to answer them? Probably I'll try to get these questions and then I can address some of them in my AMA session tomorrow. Okay. So I think I might have, there is a comment on Spars as well. Spars is great. It can even indirectly find security issues, like complaining about global variables not having static attached to them. So there is, yeah, I think I read about Clang. I think I covered all the questions. This is about the scanners. There is one question about Truby. I'm not familiar with that. Okay. I think I answered all of the questions that we have, specific to the stock at the moment. Thank you very much everybody for joining. Thanks for all the good questions.


This is a video to show you how to terminate a CAT 6 cable and module. Take the stripping tool and strip off the outer plastic sleeve. Separate out the inner cable cores. Cutting out the central plastic divider. Place the first cable into the side of the module and note the matching colors. Untwist the pair just enough to slot into the termination slots and place securely. Ensure that cable colors match the module. Continue and do the same for the three remaining color pairs. Take care to only untwist the bare minimum needed to slot in. As you can see all cores match. Once in place, terminate all cables with a punch-down tool. Ensure you hear a distinct termination click. The tool should automatically cut off the spare cable. Secure the cable to the module with a cable tie. Finally, cut off any cable tie slack. Further assistance or a free survey, please email or call on the details below and click like and subscribe if you have enjoyed this video.


Welcome. I welcome you all to this lecture in the course Sandhi in Panini and Grammar. We are studying Ach Sandhi or Vavel Sandhi. The Sandhi that takes place of a Vavel. This can be classified into two. The second one we are studying right now namely Dhristhanika Ekadesha. The first one we already studied is Ekasthanika Ekadesha. Ekasthani Ekadesha. One substituent and one substitute. We also studied two instances of Ekasthanika Ekadesha namely Yen Sandhi and Ayavaya Sandhi. Yen Sandhi is stated by Iko Yanachi. Ayavaya Sandhi is stated by Dasutra Echo Ayavaya Vaha. We also studied examples of both these Sandhis. Currently we are studying Dhristhanika Ekadesha where we have Dhristhanika two substituents Ekadesha. One substitute. This is also stated by the Adhikara Sutra Ekapurva Parayoha 6184. This Adhikara Sutra means one substitute takes place in place of two sounds namely Purva and Par previous and latter. This Adhikara can be explained diagrammatically in this fashion. You have A plus B both in the Samhita mode. A comes immediately before B and B comes immediately after A and so they both become the environment mutually and in such a case now in place of A and B this is Purva this is Par. In place of Purva and Par A and B you have one substitute namely C. So the input is A plus B but the output is just C. In case of Ekasthanika Ekadesha the input was A plus B but the output was C plus B. In Ekasthanika Ekadesha only A got substituted by C but in Dhristhanika Ekadesha both A and B Purva and Par they both get substituted by one that is C. This Ekapurva Parayoha Adhikara continues from 6184 up to 6112 there are five instances of Ekapurva Parayoha Dhristhanika Ekadesha. Guna Sandhi stated by the Sutra Adhgunaha 6187. Vruddhi Sandhi stated by the Sutra Vruddhirechi 6188. Pararupa Sandhi Engi Pararupam stated by the Sutra 6194. Savaranadirgha Sandhi this is what we are studying right now. Savaranadirgha Sandhi stated by the Sutra Akasavarnedirgha 6111 and finally Urvarupa Sandhi stated by the Sutra Amipurvaha 6117. Let us now study Savaranadirgha Sandhi. This is stated by the Sutra Akasavarnedirgha 6111. There are three padas in this Sutra Akaha which is five slash one of Ak. Ak is a, i, u, ru and lu. The first two Sutras in the fourteen Sutras Pratyahara Sutras are captured by the Pratyahara Ak. So Akaha means immediately after Ak. That means immediately after any of these sounds. Savarna is seven slash one of Savarna. Savarna means homogeneous sound. So Savarna means immediately before a homogeneous sound. And dirgha is one slash one of dirgha meaning long. So dirgha means long substitute. There are two words continued from the previous Sutras achi, seven slash one of ach. Ach means a vowel. So achi means immediately before any vowel. This continues from Ekoyanachi and Ekapurvaparyoh. One substitute in place of two, previous and latter, earlier and latter, these two substituents. Having put all these things together, the overall meaning of Akasavarnedirgha can be stated in the following manner. Immediately before a homogeneous vowel, Savarna achi and immediately after Ak, Akaha. Ak is a i u ru and lu, these five vowels. In place of both of them, Purvaparyoh, place the long vowel, dirgha, as the one substitute Ekaha. I repeat, immediately before a homogeneous vowel, Savarna achi and immediately after Ak, Ak is a i u ru and lu. In place of both of them, Purvaparyoh, place the long vowel, dirgha, as one substitute. In order to understand the meaning of this Sutra exhaustively, we need to also understand what is a Savarna or a homogeneous sound. So, the term Savarna, that is defined by 119 and 1110, needs to be studied. 119 is Tullyaseprayatnam Savarnam and 1110 is Nadjhalau. Let us study the concept of Savarna. What this means is, one sound is homogeneous with another. One sound is homogeneous with another set of sounds, of course, on the basis of certain criteria. And this term Savarna is defined by two Sutras which we already read, but let us read them again. Tullyaseprayatnam Savarnam 119 and Nadjhalau 1110. Let us study these Sutras. Now, there is an important concept related to Savarna and that is Savarna-Grahana. What it means is that the sound mentioned in the Pratyahara Sutra, that is the initial enunciation of the 14 Sutras at the beginning of the Ashtadhyayi, which is the base for the grammatical operations. So, the sound mentioned in these Pratyahara Sutras, which is homogeneous with another set of sounds represents that set of sounds. This is very important, also as an important function of Savarna. This is stated by the Sutra Anodit Savarnasya Cha Pratyayaha 1169. Now, let us study 119, Tullyaseprayatnam Savarnam. This Sutra has got two words, Tullyaseprayatnam and Savarnam. Tullyaseprayatnam is the signified and Savarnam is the signifier. Savarnam is the saudnya. Tullyaseprayatnam is the saudni. What is Tullyasyam? Tullyasyaprayatnam. Tullyasyaprayatna has got three words, Tullya, Asya and Prayatna. Tullya means similar, Asya means place of articulation and Prayatna means effort of articulation. Also known as, in this case, internal effort of articulation as is defined in Maninian grammatical tradition. Also known as Abhyantara Prayatna. So, Shabda Rupa, word form or the form of the sound is what is intended as the general qualified. So, what this Sutra means is that, the form of sound, whose place of articulation and internal effort of articulation is same, Tullya. As that of the other, such sounds are called homogeneous to each other. Savarna to each other. Savarna of each other. I repeat, the form of sound, whose place of articulation and internal effort of articulation is same as that of the other. Such sounds are called homogeneous to each other, Savarna to each other or Savarna of each other. And also let us look at 1, 1, 10. 1, 1, 10 says na jhalau. Na jhalau has got two paddas, na and ajhalau. Ajhalau has got two components, ach and hull. So, Tullya Shabprayatna, Savarnam continues in this particular Sutra and the meaning of this Sutra is, vowels, ach and consonants, hull, even if have similar place and internal effort of articulation are not to be called homogeneous to each other or Savarna of each other. I repeat, vowels and consonants, even if have similar place of articulation and internal effort of articulation, they are not to be called homogeneous to each other or Savarna of each other. This is how the term Savarna is defined. Let us study this in some detail. The question is which sounds are Savarnas with each other? So, here is a list of sounds which are to be called Savarnas of each other. So, let us begin with a. As far as the traditional sound inventory is concerned, there are 18 types of a, 6 raspa, having some other features as well. That is why this plus sign, raspa plus, udat, anudat, swarita, anunasika, anunasika, 6 varieties of a, short a, 6 varieties of birgha, birgha plus, udat, anudat, swarita, anunasika, anunasika. This is shown as a and 6 varieties of pluta a, plus udat, anudat, swarita, anunasika and anunasika. This is shown as a, 3. These 3 sets have similar sthanu, namely kantha or vellam and similar abhyantara prayatna, namely vivruta. And so, by the definition of tullya se prayatnam savarnam, these sounds are to be termed Savarna or homogeneous of each other. Similar is the case with e, which has got 18 varieties. All these 3 sets have same sthana, namely talu and same abhyantara prayatna, namely vivruta. And so, all these 18 sounds are to be termed Savarna or homogeneous of each other. Amongst them, only short e gets mentioned in the pratyahara sutras. Amongst the 18 a's, only short a gets mentioned in the pratyahara sutras. So, we say that a stands for all its 18 varieties. e stands for all its 18 varieties by the sutra 1169. So, a short is the Savarna of all its varieties, e short is the Savarna of all its 18 varieties. Similar is the case with u. There are 18 varieties of u and all these 3 sets having 18 varieties have similar sthana, osthau and similar abhyantara prayatna, namely vivruta. So, all these 18 varieties are to be termed Savarna of each other. Amongst them, only short u gets mentioned in the pratyahara sutra. Similarly, we have 18 varieties of ru. All these, they have similar sthana, namely murdhan and also abhyantara prayatna, namely vivruta. So, these 18 varieties are to be termed Savarna or homogeneous of each other. Only short ru gets mentioned in the pratyahara sutra and 1169 says that this short ru stands for its homogeneous sounds, namely all the 18 varieties. Then we have 12 varieties of lu. Why? Because there is no dirgha variety of lu. So, all these sets, they have similar sthana, namely danta and similar abhyantara prayatna, namely vivruta. So, these sounds are to be termed Savarna or homogeneous of each other. Only short lu gets mentioned in the pratyahara sutras. Then we have 12 varieties of A and there is no short variety of A, O, I and O. So, there are 12 varieties. Now, these sets have similar sthana, namely kandhatalu and similar abhyantara prayatna, namely vivruta. So, these are to be termed Savarna of each other by the definition provided by the sutra 119, tullya se prayatnam savarnam. Similar is the case with I. I also has got 12 varieties, dirgha and pluta and they have similar sthana, kandhatalu and abhyantara prayatna, vivruta. So, these 12 varieties are to be termed Savarna or homogeneous of each other. Then we have O. There are 12 varieties of O, 6 dirgha and 6 pluta. They all have similar sthana, kandthosh tau and similar abhyantara prayatna, namely vivruta. And so, these 12 varieties are termed Savarna of each other. Only long O gets mentioned in the pratyahara sutra. Then we have O, which has got 12 varieties. All these they have similar sthana, namely kandthosh tau and abhyantara prayatna, namely vivruta. And so, we have these 12 varieties which are to be termed as Savarna or homogeneous of each other. Similarly, after having finished the treatment of the vowels, if we go to the consonants, we observe that there are 2 varieties of here, Anunasika and Ananunasika, which have similar sthana, namely talu and similar abhyantara prayatna, ishatsprashtar as defined and described by the Paninian grammatical tradition. Slight contact or slight touch of the tongue with the place of articulation. So, both these varieties of here are to be termed Savarna of each other. Similarly, 2 varieties of l, they have similar sthana, danta and similar abhyantara prayatna, namely ishatsprashtar. So, they are to be termed Savarna or homogeneous of each other. There are 2 varieties of v as well, they are similar in terms of sthana which is danta and oshtar and abhyantara prayatna, namely ishatsprashtar. So, they are also to be termed as homogeneous of each other. Then we have the mentioned ku, meaning kh, kh, gh, gh and ng. They have similar sthana, namely kanta and similar abhyantara prayatna, namely ishatsprashtar or contact, touch of the tongue with the place of articulation. Now, all these 5 are to be termed as Savarna with each other. The term Savarna with respect to vowels plays a very crucial role in understanding the vowel sandhi or at sandhi. And the term Savarna applying to consonants plays a very crucial role in understanding certain types of hal sandhis or consonant sandhis which we are going to study soon.  Similarly, you have chu, meaning ch, ch, ch, j, j, n. They have similar sthana, namely talu and similar abhyantara prayatna, namely sprashtar and therefore they are to be termed Savarna of each other. Then we have tu, ta, ta, da, da and na. They have similar sthana, namely murdhan and similar abhyantara prayatna, namely sprashtar or contact. So, all these sounds, they are Savarna of each other. Similarly, we have tu, meaning ta, ta, da, da and na. They have similar sthana, danta and similar abhyantara prayatna, namely sprashtar. So, they are to be termed as Savarna or homogeneous of each other. And finally, we have pu, standing for p, ph, b, bha and mur. They have similar sthana, namely ushtar and abhyantara prayatna, namely sprashtar. So, in accordance with the sutra, tu, li, asya, prayatna, Savarna, 1, 1, 9, they are to be termed as Savarna of each other. This is how Panayan grammatical tradition defines Savarna. And we have studied different sounds that are termed Savarna of each other. It is also important in this case to note which sounds are not considered as Savarnas. This is what is stated by the sutra na jhalau. It assumes that there are some vowels and some consonants whose place of articulation and whose internal effort of articulation is going to be the same. So, for example, a and her, even if they share sthana, which is kantha, and abhyantara prayatna, namely vibhruta. So, there is tu li asya prayatnatva. Still they are not to be termed as Savarna. This is what is stated by na jhalau, 1, 1, 10, because a is a vowel and her is a consonant. That is why a and her are not to be termed as Savarnas of each other. Very crucial fact. Similarly, e and she are not to be termed as Savarnas of each other, even if they share sthana, namely talu, and abhyantara prayatna, namely vibhruta. Because e is a vowel and she is a consonant. In accordance with 1, 1, 10, na jhalau, e and she are not termed as Savarna of each other. Similarly, you have ru and she, even if they share the sthana, namely murdhan, and abhyantara prayatna, namely vibhruta. They are not to be termed Savarna, primarily because ru is a vowel and she is a consonant. So na jhalau applies over here and ru and she are not termed as Savarnas of each other as a result. And finally, we have lu and sir, they are also not to be termed as Savarnas, even if they share sthana, that is danta, and abhyantara prayatna, namely vibhruta. Because lu is a vowel and sir is a consonant. And na jhalau negates the Savarna-saudhna to both a vowel and a consonant with respect to each other. Even if tulya se prayatna-savarnam gives the Savarna-saudhna to them both, na jhalau negates it. So, having put both these sutras together, we can understand what is a Savarna. Now, what is the use of the term Savarna? We have already stated that once the sounds are termed Savarna with reference to each other, one sound can be mentioned in an enunciation and can be said to represent the remaining Savarna sounds. This is what panini does in mentioning the sound in the pratyahara sutras. So, he does not mention all sounds over there, he mentions only one of each set. So, u of the 18 varieties, e of the 18, u of the 18 and so on and so forth. And then he creates a rule 1169 which says that these sounds mentioned in the 14 pratyahara sutras and kuchu, tutu and poo, they stand for, they represent their Savarna sounds. So, when you utter just one sound, it stands for all the 18 varieties in terms of avaval and if you mention just kuchu, it stands for all its five sounds, class sounds. This is how panini attains brevity and also the scientific base for the operations which are called the grammatical operations which are stated in his own grammar. Now, the grammatical operations that should be stated with reference to a particular set of sounds which are Savarna, panini uses only one sound and uses 1169 to state what is needed. He uses the word for example, asya, which has got the sixth case in it, 6 one of a as the substitute event in 7 4 32 asya chvau. Now, even though the word asya is used by 1169, this asya means that the substitution stated by 7 4 32 is applicable to all 18 varieties of a, which are Savarna of a. Now, because of 7 4 32, a in Shukla, this a at the end is substituted by e, Shukla becomes Shukli as an output. Now, just as this short a becomes e, you will also have long a, which is a Savarna, which is stated to be a Savarna of short a to be substituted by long e. So, mala become mali and Shukla becomes Shukli. This is an important function of the term Savarna. Similarly, in 6 1 1 0 1 akasavarni dirhaha, the term Savarna is used essentially to state the Pavel Sandhi, which is of Dvithanika Ekadesha type. To summarize, the features of sounds noted by panini serve the purpose of brevity in the system of grammar. The grammarian can mention a big set of sounds briefly by the mention of one of them and uses the term Savarna, which is based on these features. Rules can be based on these features to account for the linguistic usage. And now, after having understood the term Savarna, we shall apply it in the sutra akasavarni dirhaha. And we have already studied the meaning of akasavarni dirhaha, but now we shall study the examples. First the prototypical examples and then the specific ones in order to understand akasavarni dirhaha in more details. This we shall do in the next lecture. Thank you for your patience.