I am intrigued by the memory safety section. It’s a hot topic these days, right? So here’s an interesting thought experiment.
What if all these areas where we use memory-unsafe technologies were replaced by memory managed technologies like C#, Python, Go, etc. Sure, lots of things would run slower (raw TLS in Python, yay), BUT would there suddenly just be less exploits? Or is this area more of “Law of Conservation of Ugly”?
One of the big reasons that these garbage-collected type languages were not used on critical code was that the timing couldn't be guaranteed. You can't afford a massive L1 garbage collection just at the point you are trying to land a plane or disable a nuclear reactor.
Not sure whether this is still a problem now that computers are way faster but my own experience is that despite the resources available, our apps are slower than ever, even ones that do largely what they did 20 years ago like Word and Visual Studio!
> What if all these areas where we use memory-unsafe technologies were replaced by memory managed technologies like C#, Python, Go, etc. Sure, lots of things would run slower (raw TLS in Python, yay), BUT would there suddenly just be less exploits?
Yes. We'd see at least a 30% reduction in exploits, and in the overwhelming majority of use cases the slowdown wouldn't be relevant. Software in those areas would also get written a lot quicker.
The trouble is that there's no incentive to do this, at any level. Software would probably crash more (because one of the biggest ways memory-safe languages avoid security issues is by turning silent corruption into visible crashes). No-one cares if you deliver the project in 50% less time than it would otherwise take (you're still missing the schedule), but everyone cares if it's 50% slower on a meaningless microbenchmark. And C bros no longer get to slap each other on the back about what l33t h4x0rs they are. (I suspect, cynically, that one of the reasons Rust is the language that's finally getting to replace C, is that it's that rarest of memory-safe languages that puts an equal amounts of (mostly) pointless difficulty on the programmer).
I want the hardware to protect me perhaps with a key or handle or something. Talking to the hardware: Give me a block of memory that I can append to the end of. Another piece of code: Allow me to access that other block for read only.
Each piece of software has some sort of identification. Then the hardware throws an interrupt if a piece of software uses some memory incorrectly.
I was confused by the B17 fact; if you’re at the stage of lowering the gear (flying slowly), pulling the wrong lever and going full flap would do not much? Now if you were taking off and went to raise the gear and lifted the flaps instead, then that's a problem.
On an approach, you are flying dangerously slowly (necessarily). You’re right next to stall speed. You want to go slower slower slower right up to the point you don’t go too slow. You want to reserve that crossing the threshold of too slow until your poised right over the runway with inches between you and it.
When you stall, you start falling at the speed gravity pulls you minus any drag your airframe presents. And if you’re already close to the airfield, you might be only a few hundred feet up, so you’re out of room to put the nose down and throttle up to regain speed necessary to regain lift.
Putting gear down adds a little drag (and a lot of noise), so a minor speed in reduction; going full flaps slows you a lot. You usually pitch the nose down a little more to increase your rate of descent as you go full flaps, so that you keep the speed up to keep the lift up which keeps your plane up. If it’s dark, you’re tired, flying close to stall speed already, go full flap without realizing you just did and don’t keep your eyes glued to the air speed indicator, you’ll stall out and fall from the sky. Trying to recover would catch a lot of disoriented pilots unawares.
Large changes in lift (flaps) must be coordinated with changes in thrust (engines) to keep the aircraft level or slightly descending.
A large reduction in lift (raising flaps) will cause a aircraft to dive. A large increase in lift (lowering flaps) will cause a aircraft to stall -- and fall.
Either of these changes would be recoverable if there were more thrust or more altitude, both of which are intentionally minimized during a landing.
A bit of searching seems to have revealed that the actual problem was inadvertent gear retraction. Pilots were retracting the gear, either while adjusting flaps on final approach or after landing when they tried to raise the flaps again.
I am intrigued by the memory safety section. It’s a hot topic these days, right? So here’s an interesting thought experiment.
What if all these areas where we use memory-unsafe technologies were replaced by memory managed technologies like C#, Python, Go, etc. Sure, lots of things would run slower (raw TLS in Python, yay), BUT would there suddenly just be less exploits? Or is this area more of “Law of Conservation of Ugly”?