Hi,
I'm not sure if anyone will see this as it's an old thread.

I was just watching a video regarding how hacckers break into a system.
It was above my head, but I picked up a couple of things! In this thread the are mentions of many languages, and C++ seems to be popular at the moment.
The thing I picked up on, is that C is such a powerful language that accidental not perfect CODE can be the cause of an exploit, due to an overload attack, if the CODE doesn't have protection. Some operating systems, switch this protection off if the are APPs that are old, and the CODE can't be re-written, as there's too much in an operating system.
The suggested language for better CODE is RUST.
As mentioned this is all above my head, but there it is, if I've got it right?
C.

Rust simply moves the exploits. The only perfect language is one that can't do what your need because it lives in a sandbox and someone has to written using a language that might be exploited for software bugs. At the OS level, Rust has exactly the same exploits as C because you need to turn off the Rust code restrictions by using 'UNSAFE' to handle nondeterministic hardware events that no language or compiler can find perfect solutions for.

No general-purpose programming language can be "perfectly safe".

https://www.cvedetails.com/vulnerability-list/vendor_id-19029/Rust-lang.html

It's the usual battle. Exploits are found and fixed for Rust or another low-level systems language.
There are even bugs at the CPU level hardware stage to be exploited that require fixes at the CPU level.
https://www.pcworld.com/article/407763/intel-x86-cpu-kernel-bug-faq-how-it-affects-pc-mac.html

Massive security vulnerabilities in modern CPUs are forcing a redesign of the kernel software at the heart of all major operating systems. Since the issues—dubbed Meltdown and Spectre—exist in the CPU hardware itself, Windows, Linux, Android, macOS, iOS, Chromebooks, and other operating systems all need to protect against the first exploits that have begun circulating. And worse, plugging the hole can negatively affect your PC’s performance.

 

Rust simply moves the exploits. The only perfect language is one that can't do what your need because it lives in a sandbox and someone has to written using a language that might be exploited for software bugs. At the OS level, Rust has exactly the same exploits as C because you need to turn off the Rust code restrictions by using 'UNSAFE' to handle nondeterministic hardware events that no language or compiler can find perfect solutions for.

No general-purpose programming language can be "perfectly safe".

https://www.cvedetails.com/vulnerability-list/vendor_id-19029/Rust-lang.html

It's the usual battle. Exploits are found and fixed for Rust or another low-level systems language.
There are even bugs at the CPU level hardware stage to be exploited that require fixes at the CPU level.
https://www.pcworld.com/article/407763/intel-x86-cpu-kernel-bug-faq-how-it-affects-pc-mac.html

The White House just warned against using these popular programming languages.

 

The White House just warned against using these popular programming languages.

Judging from the lack of quality security awareness in code from typical programmers I don't blame them for wanting training wheels for those guys.

The US Government already tried to spec languages, Ada ... That really worked out.

Rust? It doesn't really enforce memory safety either and it's horror for a beginner to learn. I wanted to like Rust but I have problems to solve.

But – as experts have noted in debates over Rust and C/C++ – the NSA warns that simply using a memory safe language doesn't by default preclude introducing memory bugs to software. Additionally, languages often allow libraries that aren't written in memory safe languages.

"Even with a memory safe language, memory management is not entirely memory safe. Most memory safe languages recognize that software sometimes needs to perform an unsafe memory management function to accomplish certain tasks. As a result, classes or functions are available that are recognized as non-memory safe and allow the programmer to perform a potentially unsafe memory management task," the NSA said.

https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
Those restrictions are for the app programmer guys.

For small embedded applications C can be as safe as any language.
https://www.embedded.com/memory-safety-in-c/

Memory safety in C can be summed up in a few words: there isn’t any! C is the most popular programming language used to write applications for embedded systems, particularly microcontroller-based systems. The problem that you are most likely facing at work today is that you are building IoT devices that require security and memory safety using C.

That might not seem like a big deal at first but considering that most security vulnerabilities are caused by memory safety issues, using C might suddenly be a big problem. Between 2006 and 2018, Microsoft found that approximately 70% of patched software vulnerabilities resulted from memory safety problems[1]. Therefore, if you are writing embedded software for a connected device, you need to understand the potential for memory safety bugs and how to avoid them.

 

Judging from the lack of quality security awareness in code from typical programmers I don't blame them for wanting training wheels for those guys.

This is just one of the many shining examples of the Cash Register Syndrome at play.

The problem is that too many people are incapable of writing secure code with the tools available. So along come newer tools to the rescue that (at least attempt to) remove that burden from them and do it for them.

The intended consequence, usually achieved in the short-term, is more secure code.

The unintended consequence is that teaching people how to write secure code, or even making sure that they are aware what secure code even entails, is seen as expendable in favor of making sure that they can use the latest tools to do their thinking for them. In the long-term, we end up with far fewer people that understand the issues well enough to even properly use the tools they have been given to do their thinking for them.

It's a pattern that repeats itself over and over. The more capable tools are great, and should be used in the real world. But by forgetting that scientists and engineers should learn and understand the fundamentals behind the tools they use, we dumb down the pool to a degree that more than offsets the transient gains that the tools bring to the table.

 

The Toronto Public Library system has been down since the Oct 28, 2023 cyber attack.
https://www.cbc.ca/news/canada/toronto/toronto-public-library-cyberattack-1.7120921

The whole City of Hamilton computer system has been compromised since Feb 24, 2024.
https://www.hamilton.ca/cyberincident

I want to know who are the "expert IT managers" who are responsible for recommending, installing, and maintaining such IT systems.

 

The Toronto Public Library system has been down since the Oct 28, 2023 cyber attack.
https://www.cbc.ca/news/canada/toronto/toronto-public-library-cyberattack-1.7120921

The whole City of Hamilton computer system has been compromised since Feb 24, 2024.
https://www.hamilton.ca/cyberincident

I want to know who are the "expert IT managers" who are responsible for recommending, installing, and maintaining such IT systems.

I don't blame "expert IT managers" for most of these types of incidents. Most of these types are attacks are 'social' engineered. The actual systems, software and hardware are secure but the users that often compromise such systems are not experts in security.

Good example:
https://www.sangfor.com/blog/cybersecurity/casino-hack-las-vegas-mgm-cyber-attack

Last month, the Las Vegas Strip was making headlines for a lot more than just excessive spending and entertainment. Two of the world’s largest hotel and casino companies fell victim to devastating ransomware attacks. Both MGM Resorts International and Caesars Entertainment reported that their computer systems were disrupted in early September after a social engineering attack. While MGM refused to pay the ransom demanded, Caesars Entertainment met the hackers’ demands. We take a closer look at the latest updates on both these casino hacks – starting with the MGM Cyber Attack.
...

• Social engineering attacks are popular for carrying out cyber-attacks. This means that your workforce can be your biggest liability when it comes to keeping your system secure. Employees need to be careful with login credentials and use proper cyber hygiene practices to actively prevent social engineering attacks from being successful.

 

I see this kind of horror regularly in the MCU world in "professional" code written by "experts" who "understand" their craft:

RCC->PLLCFGR &= ~(((1 << (14 - 6 + 1)) - 1) << 6);

Much of the library code from firms like ST is littered with this kind of stuff. New, novice programmers who are learning from these kinds of examples actually propagate what they learn, internalize it and eventually regard it as "the way to do it". Striving to avoid such silliness isn't "dumbing down".

How one can ever expect a learner with this kind of stuff as their example's of industry competence, to ever concern themselves with "secure code" is far from clear to me, anyone learning this is learning "how to write C" and that, right there, is the problem. I've run teams of C programmers working on mission critical financial industry systems where a crash costs a lot of money. Sloppy cryptic code was not something I tolerated.

 

I see this kind of horror regularly in the MCU world in "professional" code written by "experts" who "understand" their craft:

RCC->PLLCFGR &= ~(((1 << (14 - 6 + 1)) - 1) << 6);

Much of the library code from firms like ST is littered with this kind of stuff. New, novice programmers who are learning from these kinds of examples actually propagate what they learn, internalize it and eventually regard it as "the way to do it". Striving to avoid such silliness isn't "dumbing down".

How one can ever expect a learner with this kind of stuff as their example's of industry competence, to ever concern themselves with "secure code" is far from clear to me, anyone learning this is learning "how to write C" and that, right there, is the problem. I've run teams of C programmers working on mission critical financial industry systems where a crash costs a lot of money. Sloppy cryptic code was not something I tolerated.

Something we can both agree with. It's not C the language, it's C programmers.

 

If someone on my programming team wrote code like that, they would be shown the exit door.

 

Something we can both agree with. It's not C the language, it's C programmers.

Hi,
(Still out of my depth) but I noted that Elon chose 'C' over C++ to write some of the CODE for his rockets. You will know why, but all I can do is note it, and puzzle!
C

 

Hi,
(Still out of my depth) but I noted that Elon chose 'C' over C++ to write some of the CODE for his rockets. You will know why, but all I can do is note it, and puzzle!
C

Yes, also note his cars drive into walls, catch fire, kill drivers and regularly refuse to start - I wonder why...

 

Hi,
(Still out of my depth) but I noted that Elon chose 'C' over C++ to write some of the CODE for his rockets. You will know why, but all I can do is note it, and puzzle!
C

Rocket control is pretty much as hard embedded real-time as you can get, so C is a natural fit.
https://forum.nasaspaceflight.com/index.php?topic=41935.95;wap2
C is a language without religion (or 'class warfare' ). You want to do something stupid, it doesn't judge, it just blows up in your face. Do something brilliant, it works like a charm. His rockets speak for themselves.

SpaceX uses this to generate customized C flight code.
https://ee.stanford.edu/news/2021/jan/stephen-boyd-cvxgen-guides-spacex-falcon
Stephen Boyd’s CVXGEN software helps guide SpaceX Falcon
CVXGEN generates customized flight code that enables very high-speed onboard convex optimization

 

I see this kind of horror regularly in the MCU world in "professional" code written by "experts" who "understand" their craft:

RCC->PLLCFGR &= ~(((1 << (14 - 6 + 1)) - 1) << 6);

Much of the library code from firms like ST is littered with this kind of stuff. New, novice programmers who are learning from these kinds of examples actually propagate what they learn, internalize it and eventually regard it as "the way to do it". Striving to avoid such silliness isn't "dumbing down".

How one can ever expect a learner with this kind of stuff as their example's of industry competence, to ever concern themselves with "secure code" is far from clear to me, anyone learning this is learning "how to write C" and that, right there, is the problem. I've run teams of C programmers working on mission critical financial industry systems where a crash costs a lot of money. Sloppy cryptic code was not something I tolerated.

Apples and oranges to the nth degree -- two completely different situations.

Writing maintainable code and writing secure code are two very different aspects of programming -- you can do one without the other, though secure code that is also well-written code is far more likely to be more secure in actuality.

Writing code that compiles (or preprocesses) to your example may well be justifiable in performance critical code running on resource-starved platforms. But code such code does not need "magic numbers" to achieve that goal. At the very least, reasonable constant-like macro definitions should be used to indicate what each term means. Not only would that make the code much more readable, but it would also make it much more maintainable since those values probably differ from one MCU to another.

I can't help but wonder what the reasoning was behind the decision to use C for mission-critical financial industry software. It would seem like there are much more appropriate languages around -- in particular, languages that were developed with performing base-10 arithmetic exactly as an intrinsic capability as a goal.

If someone insists on using hammers to install screws, the solution isn't to ban hammers, but to teach the people abusing hammers that other tools exist that are more appropriate to the task.

 

Hi,
(Still out of my depth) but I noted that Elon chose 'C' over C++ to write some of the CODE for his rockets. You will know why, but all I can do is note it, and puzzle!
C

C is still the dominant choice for performance-critical real-time embedded code. In order to meet performance requirements within the resource limitations, the developer needs extreme control over the hardware, and C dominates that world. But it is also a world dominated by developers that DO know what they hell they are doing and how to write good code (which is NOT to say that they can't make mistakes, and that there isn't room for tools to help check the code for a variety of vulnerabilities).

Most of these systems cannot tolerate using object-oriented code because of the performance penalty that is paid, particularly in a real-time environment where timing guarantees have to be made and met.

 

I can't help but wonder what the reasoning was behind the decision to use C for mission-critical financial industry software. It would seem like there are much more appropriate languages around -- in particular, languages that were developed with performing base-10 arithmetic exactly as an intrinsic capability as a goal.

If someone insists on using hammers to install screws, the solution isn't to ban hammers, but to teach the people abusing hammers that other tools exist that are more appropriate to the task.

Yes, it was a dismal choice, but if this is what young eager up and coming leaders "learned" at university, that there's your answer. C was sexy once, those cute braces were appealing and many were besotted. C is what it is, I've used it for decades, written compilers with it. It's a machine independent assembler who's popularity owes more to fashion than engineering; no string data types? functions that return 'void' (aka they actually don't return anything) ? no 'bit' data type (while insisting it's a systems language) ? everything must be forward declared (not even COBOL forced that upon us) I rest my case, C is a toy language and real engineers need to stop admiring the emperor's new clothes.

 

Apples and oranges to the nth degree -- two completely different situations.

Writing maintainable code and writing secure code are two very different aspects of programming -- you can do one without the other, though secure code that is also well-written code is far more likely to be more secure in actuality.

Writing code that compiles (or preprocesses) to your example may well be justifiable in performance critical code running on resource-starved platforms. But code such code does not need "magic numbers" to achieve that goal. At the very least, reasonable constant-like macro definitions should be used to indicate what each term means. Not only would that make the code much more readable, but it would also make it much more maintainable since those values probably differ from one MCU to another.

I can't help but wonder what the reasoning was behind the decision to use C for mission-critical financial industry software. It would seem like there are much more appropriate languages around -- in particular, languages that were developed with performing base-10 arithmetic exactly as an intrinsic capability as a goal.

If someone insists on using hammers to install screws, the solution isn't to ban hammers, but to teach the people abusing hammers that other tools exist that are more appropriate to the task.

I think a lot of people in the financial industry software were heavily in math, physics and programming and used C for those types of problems. So yes, they are using the hammers they know well.
https://lsa.umich.edu/content/dam/p...hysics to Finance - What Does a Quant Say.pdf

 

Yes, it was a dismal choice, but if this is what young eager up and coming leaders "learned" at university, that there's your answer. C was sexy once, those cute braces were appealing and many were besotted. C is what it is, I've used it for decades, written compilers with it. It's a machine independent assembler who's popularity owes more to fashion than engineering; no string data types? functions that return 'void' (aka they actually don't return anything) ? no 'bit' data type (while insisting it's a systems language) ? everything must be forward declared (not even COBOL forced that upon us) I rest my case, C is a toy language and real engineers need to stop admiring the emperor's new clothes.

That is NOT what they are being taught at university. What you are almost certainly seeing there is the result of dealing with legacy code (and legacy programmers) at that company coupled with the extreme cost and risk of bringing existing codebases up to current recommended style guidelines. In the MCU tradespace, this is aggravated by the fact that performance often IS a legitimate factor that trumps readability and maintainability, with the consequence that people in that space often make little or no effort to write the code in as readable and maintainable way as possible within the performance constraints. None of this has anything to do with a particular language -- you can write perfectly incomprehensible code in any language.

Remember, in the early days when a lot of these codebases were getting started, it was actually considered a good thing if you could write code that performed better, no matter how indecipherable it was. This naturally morphed into programmers leveraging this for job security by intentionally writing indecipherable code that only they could maintain because they could get away with it provided they could demonstrate that it performed better than anyone else's. The fact that they could have gotten the same performance will code that was at least far more readable was immaterial. It wasn't until enough software got far enough into its lifecycle that the actual cost of unmaintainable code reared its ugly head strongly enough for companies to start making it a priority -- at least in new codebases.

As for there being no bit data type, that actually makes sense in a systems language intended for high performance -- virtually no CPUs support bit-level operations. The constructs in C are closely aligned with the assembly code that is generated. The big gripe I always had was that it didn't have a rotate operator, which is something that almost every processor has an instruction for.

 

I think a lot of people in the financial industry software were heavily in math, physics and programming and used C for those types of problems. So yes, they are using the hammers they know well.
https://lsa.umich.edu/content/dam/physics-assets/physics-documents/From Physics to Finance - What Does a Quant Say.pdf

When I was an undergrad working as a co-op student at NIST (then NBS), the scientists largely only knew BASIC (often HPBASIC because of the prevalence at that time of HPIB (later IEEE-488) data acquisition systems). So we had to write everything in BASIC so that the scientists had a chance of understanding it. This actually was not unreasonable given that students came and went from one semester to the next and the project scientists were the ones that had to help the next batch of students make modifications to the code that some prior batch of students wrote. The scientists weren't interested in learning a new language -- and to be fair, they didn't have the time for it and had to focus there attention elsewhere.

At that time, I didn't even know C existed. My languages were BASIC, FORTRAN, and Pascal. I would have preferred Pascal and was a bit surprised that the scientists didn't do everything in FORTRAN.

 

When I was an undergrad working as a co-op student at NIST (then NBS), the scientists largely only knew BASIC (often HPBASIC because of the prevalence at that time of HPIB (later IEEE-488) data acquisition systems). So we had to write everything in BASIC so that the scientists had a chance of understanding it. This actually was not unreasonable given that students came and went from one semester to the next and the project scientists were the ones that had to help the next batch of students make modifications to the code that some prior batch of students wrote. The scientists weren't interested in learning a new language -- and to be fair, they didn't have the time for it and had to focus there attention elsewhere.

At that time, I didn't even know C existed. My languages were BASIC, FORTRAN, and Pascal. I would have preferred Pascal and was a bit surprised that the scientists didn't do everything in FORTRAN.

"Velocity and sea surface temperature in the oceans, computed with the NEMO Fortran code (Nucleus for European Modeling of the Ocean)" - 2020.

 

"Velocity and sea surface temperature in the oceans, computed with the NEMO Fortran code (Nucleus for European Modeling of the Ocean)" - 2020.

View attachment 317928

Hi K,
Very artistic and interesting!
C.