Losing the magic [LWN.net]

Losing the magic

Posted Dec 6, 2022 14:38 UTC (Tue) by pizza (subscriber, #46)
In reply to: Losing the magic by andi8086
Parent article: Losing the magic

Bare-metal embedded (not to mention the actual hardware) requires a _lot_ more discipline than most other software categories.

On average, you'll find embedded and hw folks a lot more vigorous when it comes to testing/validation, as fixing bugs after things have shipped can be prohibitively expensive.

to post comments

Losing the magic

Posted Dec 6, 2022 15:24 UTC (Tue) by khim (subscriber, #9252) [Link] (3 responses)

> Bare-metal embedded (not to mention the actual hardware) requires a _lot_ more discipline than most other software categories.

It requires entirely different discipline, that's the issue.

> On average, you'll find embedded and hw folks a lot more vigorous when it comes to testing/validation, as fixing bugs after things have shipped can be prohibitively expensive.

Yes, but more often than not they do bazillion tests and conclude that it's enough to be confident that thing actually works as it should.

Often they are even right: hardware is hardware, it often limits input to your program severely (which makes things like buffer overflow impossible simply because laws of physics protect you). And hardware is rarely behaves 100% like specs say it would behave thus without testing math models wouldn't save you.

Software is thoroughly different: adversary may control inputs so well and do things which are so far beyond anything you may even imagine that all these defenses built by folks with hardware experience and their tests are sidesteped without much trouble.

You need math, logic and rigorous rules to make things work. It's really interesting how attitude of linux kernel developers have slowly shifted from hardware mindset to software mindset when fuzzing guys found more and more crazy ways to break what they have thought was well-designed and tested piece of code.

Now they are even trying to use Rust as a mitigation tool. It would be interesting to see whether it would actually work or not: linux kernel sits between hardware and software worlds which means that pure math, logic and rigorous rules are not enough to make it robust.

Losing the magic

Posted Dec 6, 2022 17:18 UTC (Tue) by pizza (subscriber, #46) [Link] (2 responses)

In other words, you're saying we need more rigorous/detailed specifications for software.

...And you're the one going on about folks asking for O_PONIES?

Losing the magic

Posted Dec 6, 2022 17:58 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

And if I've understood the "higher maths" correctly - I'm more a chemist/medical guy by education - the O_PONY I'm asking for is that signed multiplication be a group. Any group, I don't care, so long as when it doesn't overflow the result is what naive arithmetic would expect.

Because, on the principle of least surprise, it's a very unpleasant surprise to discover that multiplying two numbers could legally result in the computer squirting coffee up your nose ... :-)

Is there really anything wrong in asking for the result of computer operations to MAKE SENSE? (No, double-free and things like that - bugs through and through - clearly can't make sense. That's just common sense :-)

Cheers,
Wol

Losing the magic

Posted Dec 6, 2022 18:20 UTC (Tue) by khim (subscriber, #9252) [Link]

> And if I've understood the "higher maths" correctly - I'm more a chemist/medical guy by education - the O_PONY I'm asking for is that signed multiplication be a group. Any group, I don't care, so long as when it doesn't overflow the result is what naive arithmetic would expect.

Doesn't look that way to me. Compiler developers already acquiesced to these demands and provided flag which makes clang and gcc to make signed integers behave that way.

Now you arguing about different thing: “right to be ignorant”. You don't want to use flag, you don't want to use provided functions, you don't want to accept anything but complete surrender from guys who have never promised you that your approach would work in the first place (because it's not guaranteed to work even in C90 and gcc 2.95 from last century already assumes you write correct code and don't overflow signed integers).

> That's just common sense :-)

And that's precisely the problem. You ask for common sense but neither computers nor compilers have it.

They couldn't employ common sense during the optimisation because it's not possible to formally describe what “common sense” means!

Thus they use the best next substitute: list of logical rules collected in the C standard.

> Is there really anything wrong in asking for the result of computer operations to MAKE SENSE? (No, double-free and things like that - bugs through and through - clearly can't make sense.

That's how specification is changed and how new switches are added. People employ their common sense and discuss things and arrive at some set of rules.

Similarly to how law is produced: people start with common sense, but common sense is different for different people thus we end up with certain set of rules which some people like, some people don't like, but all have to follow.

Only with C standard situation is both simpler and more complicated: subject matter is much more limited, but agent which does the interpretation doesn't have even vestigial amounts of common sense (law assumes that where there are contradictions or ambiguities judge would use common sense, C language specification writers have no such luxury) thus you have to make specification as rigid and strict as possible.