LWN: Comments on "Cook: security things in Linux v5.0"

Fixing programmers

Wol — Mon, 25 Mar 2019 15:45:45 +0000

I know it's well past, but I'll add that this convention long predates modern computers.

It was the convention on old green screen terminals. It was the convention on teletypes before that. Heck, it's the convention that first came about two centuries ago with the early typewriters!

Just changing the convection won't fix two centuries of training to do the opposite - since when did hitting "return" change the paper for you?

Cheers,
Wol

Fixing programmers

Cyberax — Wed, 20 Mar 2019 01:18:36 +0000

The Pascal dialect that I used back in 1995 definitely had it. I'm not sure about the Standard Pascal.

Ada has had integer overflow checking since forever (as you would expect).

Fixing programmers

neilbrown — Tue, 19 Mar 2019 23:24:33 +0000

> By that definition, the Therac-25 "correctly" killed three people.

Sorry to correct you, but I think you mean "It is correct that 'The Therac-25 killed three people' ".

And this is the point - when people start using broad terms like "intent" and "correct" without ensuring that all corespondents are using them in the same sense, you can hardly expect a useful conversation to result.

(wouldn't it be great if people would think about what they write, instead of just writing about what they think).

Fixing programmers

pizza — Tue, 19 Mar 2019 22:03:11 +0000

By that definition, the Therac-25 "correctly" killed three people.

Fixing programmers

neilbrown — Tue, 19 Mar 2019 21:44:39 +0000

> Let's say I have this code snippet: a = b + c; Is it correct?

Yes it is.
Your statement "I have this code snippet: a = b + c" is self-evidently correct.

Fixing programmers

mpr22 — Tue, 19 Mar 2019 19:36:59 +0000

I ask in all sincerity: which programming languages of vaguely similar vintage to C do any significantly better a job of accommodating integer overflow than C does?

Fixing programmers

Cyberax — Tue, 19 Mar 2019 19:13:52 +0000

Integer overflow could easily be prevented in hardware (by causing a hardware trap). It doesn't even need any serious amount of silicon, integer overflow traps existed in lots of pre-x86 hardware.

Unfortunately, C made that useless and so it fell by the wayside.

Fixing programmers

mathstuf — Tue, 19 Mar 2019 14:59:15 +0000

Granted, but I feel that the intent that matters is a much higher-level construct in black hat hacking than "should this case statement have a break statement?".

Fixing programmers

NAR — Tue, 19 Mar 2019 14:55:44 +0000

that allows you access to something else that you normally wouldn't be able to access.

You're making the assumption that this particular access was not intended. So intent matters.

Fixing programmers

NAR — Tue, 19 Mar 2019 14:43:07 +0000

"why haven't we changed the way we work so that buffer overflows don't happen? "

According to this study, checks for buffer overflows in C can lead to 0-7% percent performance loss. Checking for integer overflow could lead to 50% slowdown. I guess those who still want to work in C don't want to accept this performance degradation.

Fixing programmers

mathstuf — Tue, 19 Mar 2019 14:43:04 +0000

For zero-day hacking, the intent doesn't matter. All that matters is that you can thread your special arguments through to some internal state that allows you access to something else that you normally wouldn't be able to access. In *fixing* the issue, intent again enters the picture since just closing the hole naïvely can block some use case that is supposed to be intended (or break some subtle backwards compatibility). Static analysis is similar. It's goal is to detect what the actual code does, match it against code smells and flag such code. Intent then comes in when you either suppress the notice or change the code to make the code not wrong.

Fixing programmers

NAR — Tue, 19 Mar 2019 14:31:38 +0000

what the intent was actually doesn't matter and correctness is all that counts.

How can you check correctness when you don't know what that code is supposed to do?

Fixing programmers

mathstuf — Tue, 19 Mar 2019 14:14:25 +0000

There are a few fields where I can see the actual behavior of the code is of utmost importance, damn the intent. Static analysis and zero day hunting to name a few. In these cases, what the intent was actually doesn't matter and correctness is all that counts. However, these fields usually result in changes to the analyzed code when something "interesting" is found, so intent can matter again at that point.

Fixing programmers

anselm — Tue, 19 Mar 2019 12:24:11 +0000

The goal of computer programming is to write code that does what it is supposed to be doing. You can use the code itself to figure out what it does, but you can't use the code itself to figure out whether it does what it is supposed to be doing.

It's very easy to write code that does something. Writing code that does what it it supposed to do is a lot harder, and requires outside context so you can determine when you're done. This is why in Real Life™ we have comments, specifications, unit tests, and so on – all to be able to figure out whether code does what it is supposed to do.

Fixing programmers

HelloWorld — Tue, 19 Mar 2019 10:37:20 +0000

> There's no more reason to assume that two cases with fallthrough are correct or incorrect than two cases seprated by a break;. I've actually written code where I forgot to omit the break in the past :-).
There are actually two reasons:
– the case where you want to use break is vastly more common than the case where you want to fall through
– it's easier to forget adding the break keyword than it is to accidentally add the fall-through attribute

> I've actually written code where I forgot to omit the break in the past :-).
The article mentions 20 cases of missing break statements that were uncovered by this work, while it doesn't mention any cases like the one you describe. It's safe to say that missing break statements are a much more frequent occurrence.

Fixing programmers

NAR — Tue, 19 Mar 2019 10:02:55 +0000

Intent doesn't matter. Correctness does.

Let's say I have this code snippet: a = b + c; Is it correct?

Fixing programmers

sfeam — Mon, 18 Mar 2019 22:39:40 +0000

I believe you have this backwards. What the code does can be determined in the absence of comments. The intent, not so much. That is why comments are valuable for bug-finding. Any place where the documented intent does not match the observed actual behavior is candidate for causing problems.

Fixing programmers

Cyberax — Mon, 18 Mar 2019 22:33:28 +0000

> I need to know what the code does, not what someone believed it should be doing.
So you need to know the intent. Duh. You're just deluding yourself at this point.

Correctness checking is TRIVIAL, it's not even worthy of mentioning. Checking of intent is anything but. And that's exactly why modern computer languages try to make it easier for developers to express their intent through code.

Fixing programmers

rweikusat2 — Mon, 18 Mar 2019 22:29:30 +0000

If you think so, that's your opinion and not mine.

As person who spends a seriously lot of time working with other people's code (and has done so for about 15 years), I can assure you that I don't give $random_small_quantity_of_money for documentation of "programmer intent", especially not in form of otherwise uninformative comments. I need to know what the code does, not what someone believed it should be doing.

Fixing programmers

Cyberax — Mon, 18 Mar 2019 22:11:23 +0000

Actually you got it wrong. Correctness doesn’t matter. The intent does.

Fixing programmers

rweikusat2 — Mon, 18 Mar 2019 21:46:42 +0000

As I've already explained: Intent doesn't matter. Correctness does. YMMV.

Fixing programmers

mathstuf — Mon, 18 Mar 2019 19:53:54 +0000

As a reviewer, I would want a positive indication of intent for either behavior. A lack of either break or a fallthrough comment/attribute is an automatic request for "please clarify". The goal isn't to make code writer's jobs easier, but those who have yet to come and read the code.

Fixing programmers

rweikusat2 — Mon, 18 Mar 2019 19:40:58 +0000

I don't understand what that's supposed to mean in the given context.

I was trying to express two things:

1) Noting that a break is absent isn't sufficient grounds to assume that this must have been an oversight unless there's an a priori conviction that this is a very likely cause for an absent break. Considering the "99% false positives", such a conviction doesn't seem sensible to me.

2) Computers execute code as it was written, not as it was intended to be written. An absent break which was an oversight isn't necessarily an error. And neither is a conscious omission or a present break necessarily correct.

Fixing programmers

farnz — Mon, 18 Mar 2019 19:09:59 +0000

I don't disagree that a lot of the issues are down to maritime law - but that's precisely the sort of thing that needs to be fixed if maritime is to catch up on aviation w.r.t. safety errors. And (to circle back round) both aviation law and maritime law are government regulations on the way their respective industries are run, complete with liability control; however, one has a strong record of ratcheting up safety over time, and the other continues to blame individuals rather than address the many ways in which changes to the law would result in better safety for all.

Hence my belief that regulation, in itself, is not sufficient to improve software - it needs to be good regulation like aviation, where the emphasis is on changing the regulation to prevent repeats, not like maritime law where flag administrators are slow to change regulations in response to known deficiencies.

Fixing programmers

pizza — Mon, 18 Mar 2019 17:20:37 +0000

Unfortunately, many of the answers to your questions are "because maritime law."

BTW, here is the 181-page official investigation report:

http://3kbo302xo3lg2i1rj8450xje-wpengine.netdna-ssl.com/w...

Fixing programmers

farnz — Mon, 18 Mar 2019 16:50:36 +0000

Exactly my point - there are two things that matter and are different in aviation as opposed to maritime regulation:

Overriding the captain when they are making a mistake is expected in aviation, and praised; it is punished in maritime regulation.
The questions being asked of the captain are not "what could we have changed to stop this from happening", but "why did you not do the right things".

It's that blame culture that prevents maritime rules from moving on - we have a scapegoat for the incident, we don't need to consider anything other than Captain Schettino's bad behaviour. In the aviation world, there would be more significant changes expected; why does Captain Schettino claim he was asked to do a sail-past salute? Why can't a more junior officer order preparations to abandon ship? Why couldn't Captain De Falco hand command of the ship over to Mr Bosio when Captain Schettino refused to return onboard? Why is it possible for the alarm system to be off on captain's orders alone?

And I'm not a professional investigator - those are just four things raised by the public record on the disaster that should be understood and should lead to changes to the way ships are run, if it's managed the way aviation is. Human error happens, and the rates at which it happens are well understood, so why do we accept that the disaster was Captain Schettino's fault, and leave it at that, when we should be trying to ensure that the next Captain Schettino cannot make the same set of mistakes?

Fixing programmers

jezuch — Mon, 18 Mar 2019 16:14:21 +0000

I do that too, *and* I do the initial commit using git commit -p as a kind of self-review. Catches plenty of stuff I wanted to do or did temporarily but forgot etc.

Fixing programmers

pizza — Mon, 18 Mar 2019 15:56:52 +0000

> In an aviation equivalent, the setup would allow any bridge officer to override the captain on a risky manoeuvre like this; it simply wouldn't be just the captain's fault as the Concordia was suggested to be.

(FYI, under maritime law, "overriding the captain" is called mutiny, something that tends to go quite badly for all involved..)

Meanwhile, the book wasn't thrown at the captain (and his senior staff) for merely running aground. Instead, it was for grossly mismanaging what happened next. To top it all off, the captain *abandoned his post* well before evacuation was complete.

Fixing programmers

mathstuf — Mon, 18 Mar 2019 13:49:33 +0000

Depends. Sometimes "uninteresting" parts of a patch are done at a late (or early) hour and is just more prone to typos and errors. Reviews are invaluable to every coder, from those learning anew all the way up to Linus. One of the first things I do after opening a merge request is do another look over the code. I've lost count of how many 5-minute-later pushes I've made because of that. Or if I find a bigger issue, I at least leave a comment that something looks weird and might need more thought.

Fixing programmers

farnz — Mon, 18 Mar 2019 13:20:28 +0000

The Costa Concordia is a good example, because it had a near-miss doing a similar manoevure at company request under the same captain a few months earlier, but no formal investigation happened - it was just one of those things - and even now, the effort is to claim that the captain was at fault.

In an aviation equivalent, the setup would allow any bridge officer to override the captain on a risky manoevure like this; it simply wouldn't be just the captain's fault as the Concordia was suggested to be.

Plus, there are plenty of design issues with the cruise ships in general, which are being completely ignored in favour of minor tweaks to the way they operate - despite knowing that the requirement for active stability assist to stay upright is part of what caused the Concordia to crash.

Fixing programmers

pizza — Mon, 18 Mar 2019 12:46:19 +0000

I'm not sure that the Costa Concordia is a good example here, as the company was based in Italy, the ship flew an Italian flag, and the accident happened in Italian waters -- it's rare for two to be true, much less the trifecta! -- and its Captain demonstrated astonishing (not to mention criminal) levels of gross incompetence.

That said, the cruise industry as a whole also made changes (notably requiring safety drills prior to leaving port instead of "within 24 hours" as the governing treaties require) and much stricter rules about non-essential personnel on the bridge -- eg if you're going to sneak your mistress on board without a ticket, at least keep her off the bridge during offshore manoeuvres.

I might postulate that the "maritime industry" is learning the lesson that poor safety practices will severely hurt them in the market -- both in lower passenger booking and drastically higher insurance premiums. (Indeed, insurance company requirements probably do more to effect industry-wide changes than governments ever do..)

Fixing programmers

farnz — Mon, 18 Mar 2019 11:43:33 +0000

That's not sufficient - maritime transport is regulated in the same way as aviation, and yet is as generally disasterous as programming. In particular, maritime accidents can be blamed on human error and the captain or their crew prosecuted in a way that does not happen in aviation - see the Costa Concordia disaster for example, where no lessons are being learnt by the industry because they can push the blame onto the captain.

Fixing programmers

pizza — Mon, 18 Mar 2019 11:18:56 +0000

> In contrast, in software, we had the Morris Worm of 1988 (over 30 years ago), which exploited buffer overflows in C code. 30 years later, we're still seeing new buffer overflow attacks on maintained software written in C; why haven't we changed the way we work so that buffer overflows don't happen?

Because, unlike both Surgery and Aviation, "programming" (C or otherwise) as a profession has little to no formal quality, training or certification requirements, and zero government oversight. Which is just they way the industry likes it.

You want this to change? Make software vendors directly liable (civilly and/or criminally) for software defects -- no more hiding behind "the software is provided with no warranty; not even implied merchantability or fitness for a particular purpose" disclaimers.

Fixing programmers

farnz — Mon, 18 Mar 2019 10:18:56 +0000

The thing that really changed both aviation and surgery is not checklists themselves, but three shifts in attitude that result in changes (including checklists) that improve on today's situation.

Change 1 is the idea that unforced human error is not an explanation - it's just a way of shifting blame onto the operator. All incidents have to be investigated, and at each point where a reasonable change to procedure or device implementation could have prevented an incident, that change should be identified. Once you have a list of changes that could have prevented this incident, then you do a risk/benefit assessment of each change and decide which ones are worth having, and which ones just add complexity for complexity's sake.

Change 2 is that there's no such thing as a lucky near miss - instead, there are near misses that . Whenever someone has a "lucky near miss", record what happened, and classify it with other lucky near misses. Someone looks for patterns of lucky near misses, and anything that recurs is treated as an incident and investigated with a view to stopping it happening again.

Finally, change 3 is the idea that seniority should not imply deference. The world's greatest experts all make mistakes, and when a junior calls you out on a possible error, you either fix it and graciously acknowledge their input (if they've called you on a real error like operating on the wrong limb), or you treat it as a teachable moment if they've misunderstood something (e.g. if they're asking you why you put the nose down and cut the throttle when trying to descend).

None of this is a panacea - mistakes still get made - but it means that you don't repeatedly make the same class of error, nor do you depend on "experience" and "expertise" to remove classes of mistake, because the changes you make (be it checklists, talking to the patient before operating, gauges rotated so that "perfect" is straight up, sign in/out sheets for everything that's used in an operation, making it normal for juniors to critique seniors) all change the working environment such that fewer mistakes are made.

In contrast, in software, we had the Morris Worm of 1988 (over 30 years ago), which exploited buffer overflows in C code. 30 years later, we're still seeing new buffer overflow attacks on maintained software written in C; why haven't we changed the way we work so that buffer overflows don't happen?

The art of checklists

rickmoen — Mon, 18 Mar 2019 00:58:01 +0000

Cyberax wrote:

Aviation? The same issue. Solved by checklists that HAVE to be followed.

Sadly, there have been some painful (and fatal) lessons in effective use of checklists in the airline industry, as also in other industries where they're critical (marine transportation. weapons systems, spaceflight, medical care, etc.) Making a long story short, checklist design and implementation has had subtle aspects that are difficult to get right, and just saying they HAVE to be followed isn't nearly enough.

What happens when airlines get it wrong is what happened to my father, Pan Am Captain Arthur Moen, and his crew. (Upon finally reading the NTSB report, I was obliged to change my saying 'A checklist will have your life' to 'A well-debugged checklist will save your life'.)

Rick Moen
rick@linuxmafia.com

Fixing programmers

rweikusat2 — Sun, 17 Mar 2019 20:29:41 +0000

> A fallthrough comment is not trying to tell you whether or not the code will fall through. Obviously it will, there's no break! The
> comment is telling you that someone thought about it and INTENDED the fallthrough to happen.

It's usually safe to assume that code came to be in a certain form because someone was convinced it would be the right way to solve a particular problem. But that's not particularly interesting. Interestsing is "is it the right way".

Fixing programmers

madscientist — Sun, 17 Mar 2019 12:30:35 +0000

GCC provides options that allow the preprocessor to leave comments in its output files.

However, using attributes is probably a better way to go in general.

Fixing programmers

HelloWorld — Sun, 17 Mar 2019 10:49:54 +0000

gcc also supports using an attribute instead of a comment, that will not be removed by the preprocessor.

Fixing programmers

farnz — Sun, 17 Mar 2019 09:11:47 +0000

It was formalised in IBM's CUA guidelines in 1987, which was adopted by Motif. I can't find references for where IBM took that behaviour from, but the fact it was adopted as part of CUA suggests it was in use before 1987.

Fixing programmers

ABCD — Sun, 17 Mar 2019 00:28:17 +0000

Among possibly other languages, Java allows this:

labela:
for (int i = 1; i <= 10; i++) {
    labelb:
    for (int j = 10; j >= 1; j--) {
        do_something(i, j);
        if (x) continue labela;
    }
}