this site requires javascript to view.. it's a fucking plain text message.. anyway:
14:40 D. J. Bernstein As a boring platform for the portable parts of boring crypto software, I'd like to see a free C compiler that clearly defines, and permanently commits to, carefully designed semantics for everything that's labeled "undefined" or "unspecified" or "implementation-defined" in the C "standard". This compiler will provide a comprehensible foundation for people writing C code, for people auditing C code, and for people formally verifying C code.
For comparison, gcc and clang both feel entitled to arbitrarily change the behavior of "undefined" programs. Pretty much every real-world C program is "undefined" according to the C "standard", and new compiler "optimizations" often produce new security holes in the resulting object code, as illustrated by
and many other examples. Crypto code isn't magically immune to this--- one can easily see how today's crypto code audits will be compromised by tomorrow's compiler optimizations, even if the code is slightly too complicated for today's compilers to screw up. A boring C compiler will eliminate these nasty surprises; it will prioritize predictability.
I should note that this plan, throwing away gcc and clang in favor of a boring C compiler, isn't the only possible response to these types of security holes. Here are several other responses that I've seen:
* Attack the messenger. "This code that you've written is undefined, so you're not allowed to comment on compiler behavior!" The most recent time I saw this, another language lawyer then jumped in to argue that the code in question _wasn't_ undefined---as if this side discussion had any relevance to the real issue.
* Say that the C "standard" allows gcc and clang to do whatever they want to all of these "undefined" programs. Yes, we know that it's a stupid "standard"; that isn't the question. What do we do about the resulting security problems?
* Blame the security holes on the C programmers who wrote "undefined" programs. This _might_ be reasonable if there were a plausible plan to reduce the fraction of "undefined" programs from ~100% to ~0%, but there isn't. Even if there were, how would this massive code revision be better than keeping the code and switching to a boring C compiler?
* Claim that earthquakes in the behavior of "undefined" programs will teach C programmers to stop writing such programs. "That'll show 'em!" But the reality is that this hasn't worked and won't work.
* Claim that all we need is for some particular "undefined"-catching tool to be widely used. In fact, these tools are full of false positives and false negatives; at best they catch a few limited types of "undefined" behavior, not changing the big picture.
* Claim that a boring C compiler can't possibly support the desired system _performance_. Even if this were true (which I very much doubt), why would it be more important than system _correctness_?
Overall I think that these people simply don't understand what most C programmers want. A boring C compiler will very quickly gain users---not merely for security but also for predictability in general; people will appreciate, e.g., having variables automatically initialized to 0. Of course, the compiler has to support the usual C ABI, so that programs compiled with this compiler can be linked to libraries compiled with other compilers (including other languages), and vice versa, allowing an incremental upgrade process.
I'm told that the Plan 9 compiler tries to be somewhat predictable---
---but it still leaves many things unspecified, and I'm under the impression that it has its own ABI. There's a "Fail-Safe C" compiler that sounds like it defines much more, including safe semantics for buffer overflows---
that add more useful semantics to some parts of C _without_ changing the ABI, but the same compilers will happily screw up other parts of C. There's a "Friendly C" proposal that targets other parts of C more relevant to core crypto---
---but the big picture is still tons of misguided flexibility for the compiler writer.
---Dan
Name:
Anonymous2015-12-21 20:39
Too long but here are some things I noticed: ``"standard"'' ``"undefined"'' ``"optimizations"'' (LOL he can't even write. It is actually optimisations)
I have a solution, maybe, just maybe follow what the standard says for once and stop behaving like a stupid fuck who its okay because it just work on my machine. Asshat
A actual solution would be to use an implementation that tries to show up the errors as much as possible. And by implementation I do not mean only the compiler but also the standard library and the underlying architecture as well. Instead of covering your diarrhea in the sand, try to find the cause of it.
Throw the fucking thing out, and use literally anything else. There's no magic to C that any other low-level language can't accomplish, or even subsets of higher level languages.
Name:
fuck off lexie2015-12-22 1:11
>>2 the nice colorful pictures are easy to read for you lexie
>>6 What can we do to phase out and deprecate C? Most of us still use software that depends on it.
Name:
Anonymous2015-12-22 11:13
>>6 This is what Rust people say, and before you know it they've got you brainwashed with their SJW ideology, sucking dicks, infected with HIV, and rewriting the Linux kernel in Rust.
Name:
Anonymous2015-12-22 13:17
>>1 Ah, I see, D. J. Berenstain is an Ideas Man. In fact I think he might have transcended being an Ideas Man and became an Impetus Man, a being of pure wankery.
I mean, an Ideas Man would at least do something like take John Regehr's proposal and outline some Ideas on how to further eliminate undefined behavior (for example, you can range check all pointer arithmetics using fat pointers), of course leaving the boring stuff like ironing out the details (like how do you track pointer-ness through serialization via memcpy for example) and actual implementation to lesser men.
Not mr. Berenstein though, he wouldn't stoop even to that, he merely conveyed his Strong Opinion that the Job must be Done, mentioned the previous attempts at Getting the Job Done, and rode away into the sunset, his mission of improving human condition complete.
Name:
Anonymous2015-12-22 15:27
>>11 I am smarter than dan berngstaing. I have over 4 years experience in javascript which runs in the wbrowser. My profilolio includels: )did the CSS).
I have not publish as many academica papers as him but im still smarter because the things i have produced (my personal blog) are a lot of more imporcance than this stupid dude that thinks hes hot shit after writing an email app. I can write email app too using nodejs.
Why does anyone listen to this "djb" idiot. What a lame 90s-hacker pretentious 'handle'. doesn't he know it's 2016 already? He should get on github and use his real name and a nice photo like I do. I get employment through github dude.
Bceause I'm so smart (compared to him) I made a lo of cool things like new apps. What has he made? Some weird thing that mixes binary numbers about and it s named after an italian dancing move? tell me how exactly is that going to help young african girls get involved in computers...?
I'm smarter than dan beinhtstargi because I got $4000 on a kickstarter ato makea game making gamer: a browser bades games maker tool where you can select from 3 games to make by drag an drog. This empowers people. what hdoes his shit do? some math crap.
everyone lets ignore this 'djb' guy and hope he goes away.
The three currently known posters on /prog/: me, The Sussman, and dang bangstain
Name:
Anonymous2015-12-22 16:25
14 words
Name:
Anonymous2015-12-22 16:49
>>9 Source-to-source compilation of C into the preferred target language would be great, as well as the ability to link to C binaries. The latter is already necessary because most OSes only expose a C interface.
Name:
Anonymous2015-12-22 18:02
>>12 You sound really buttdevastated. Sorry for pooperpunishing you to such an anally anguishing extent!
I think it's the first time I've seen someone tried to whiteknight a male CS researcher though, and how! Wow.
I'm smarter than dan beinhtstargi because I got $4000 on a kickstarter ato makea game making gamer: a browser bades games maker tool where you can select from 3 games to make by drag an drog. This empowers people. what hdoes his shit do? some math crap.
Scratch that, you sound drunk as fuck. On an unrelated note, reminds of a story when two male nerds (acquaintances of acquaintances) were drinking with a female nerd, and at some point started hinting about menage a trois, to which she suggested that they might go and fuck each other if they are so horny, which to her great surprise they did.
Alcohol is known to sexually liberate people, bringing to surface deeply suppressed feelings like your homosexual fantasies about DJB. So no, now I'm not surprised at all.
Claim that all we need is for some particular "undefined"-catching tool to be widely used. In fact, these tools are full of false positives and false negatives; at best they catch a few limited types of "undefined" behavior, not changing the big picture.
These tools ought to be a standard component of every C compiler. One of the biggest issues with C is that you can't generally expect the compiler to warn you about very common errors (the more popular compilers certainly try to do this, but they aren't always an option, and even gcc and clang will silently accept really horrible things even with most of the usual warnings turned on).
Of course, you can't provide useful warnings for everything - that's an unavoidable fact of the way the language is designed - but not warning by default when the compiler knows the programmer has surely screwed up and that it is generating total crap is just not acceptable today.
>>18 It's halting-problem-impossible to catch undefined behavior with static analysis. It would need to be very heavy instrumentation for run-time analysis.
Name:
Anonymous2015-12-23 1:38
>>20 To catch all undefined behavior, yes. However it's quite possible to identify a decent amount of it with little or no runtime overhead.
Name:
Anonymous2015-12-23 1:44
Why not have ANDRU analysis and attempt formal proof of the program before compiling?
It's halting-problem-impossible to catch undefined behavior with static analysis
No, it isn't.
Name:
Cudder !cXCudderUE2015-12-23 11:21
tl;dr: most compiler writers are idiots who don't even realise one of the suggestions the standard gives about UB is...
NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
...exactly what most programmers actually want when they use C.
Name:
Anonymous2015-12-23 13:13
>>20 everyone here knows what the halting problem is. you don't need to tell us about this AMAZING cool thing you just learned yesterday in godel escher bach.
yes it's undecidable, that doesn't imply a program can't detect it in a lot of cases. It is also possible to conservatively reject programs that can't be shown to be safe. This results in only accepting a nontrivial subset of safe programs.
Again with the "a lot of cases". Fuck that and fuck you. That doesn't fix the problem of C being shit. Either you eliminate UB or you don't.
Do you people never actually understood halting problem, for all your elitism and counter-elitism? The HP-based counterexample to static analysis problem looks like "try to prove Goldbach's conjecture, if it's true then dereference a NULL pointer, otherwise just return". Well then, if you want provably safe code you go and mark that code as invalid, problem solved.
All that "but muh halting problem" bullshit is a giant ripe red lutefisk that has nothing to do with any of the real problems with constructing a safe subset of C.
Name:
Anonymous2015-12-23 19:05
What the fuck does the halting problem have to do with most UB in C? 99% of it is trivial shit that no other language standard has trouble with. Fucking INT_MAX + 1 is UB ferfucksake.
Dec 21 20:12:23 <alice> https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ Dec 21 20:12:26 <alice> This makes me cringe. Dec 21 20:13:58 <bob> alice: without reading, why? Dec 21 20:14:05 <urine> alice: TL;DR Dec 21 20:16:19 <eve> DJB is a serial reinventer...ignore him Dec 21 20:16:33 <alice> bob: The guy wants a compiler that has predictable "undefined behavior", "implementation-defined behavior" and "unspecified behavior". Dec 21 20:16:42 <pilne> so Dec 21 20:16:43 <mallory> yeah DJB is not the brightest as coders go Dec 21 20:16:50 <bob> alice: lmao. good luck to him I suppose. Dec 21 20:16:53 <pilne> tl:dr he has no ideas what he wants Dec 21 20:16:55 <eve> alice: it's not "the guy", it's DJB...the very definition of NIH WHACKJOB! Dec 21 20:16:57 <mallory> what an idiot Dec 21 20:17:16 <eve> I'm surprisedd he hasn't implemented one Dec 21 20:17:27 <alice> How?! Dec 21 20:17:44 <eve> he's djb. He reimplements *everything* Dec 21 20:17:46 <steve> why ... don't just pick another language? Or atleast use a stricter standard like POSIX. Dec 21 20:17:49 <mallory> I'm a lot smarter than djb Dec 21 20:18:14 <alice> The request for predictable unspecified behavior is legitimate, but implementated-defined is ALREADY defined, it's the whole purpose, so is the purpose of undefined behavior which shouldn't be used in a program and serves for portability purposes only. Dec 21 20:18:42 <dan> < eve> DJB is a serial reinventer...ignore him <- this is such a transparently wrong argument that i believe a convincing argument exists that it is low-level trolling Dec 21 20:19:12 <steve> whats wrong with wanting a stricter standard? ISO C is full of undefined this and undefined that. Dec 21 20:19:20 <urine> +1 Dec 21 20:20:25 <eve> dan: he reinveted sendmail and bind (to name just the two most egregious...); he *tried* to reinvent DNS (and failed because nobody uses dnscurve). He's a talented guy there's no doubt, but he *is* a serial reinventer
Name:
Anonymous2015-12-23 19:53
I do not want to be lumped with the "don't reinvent the wheel, use robust Java solutions", but isn't consistent implementation-defined behavior a stupid idea?
Name:
Anonymous2015-12-23 19:56
>>40 it doesn't sound stupid to me. Any reason why you say that?
I think the biggest force in effect here is that lesser programmers are having their ego threatened.
I'm talking about the kind of guys who are proud of themselves for memorizing the various C standards, knowing all the exact UB talking points you can pull out to force someone to admit you know C better than them.
They're scared and biting back because they know their 'talent' is being nullified.
Name:
Anonymous2015-12-23 20:21
>>42 I see a different thing: destroying the portability of C because they don't want to write x86 assembly.
Name:
Anonymous2015-12-23 20:52
>>43 Nobody but cudder should be forced to write x86 assembly in 2015.
Name:
Anonymous2015-12-23 21:00
>>36 You don't even understand the fucking conversation.
If you standardized what your compiler/environment does with UB, you have fixed it. If you move to a language that isn't as godawful and godforsaken as C, you have fixed it.
Trying to trap & report UB is fucking stupid, and the halting problem is part of and/or proof of that idiotic response to this thread.
Name:
Anonymous2015-12-23 22:59
Simply read UB as ``Not allowed''
Name:
Anonymous2015-12-24 0:27
Hey Doc, it hurts when I slam my head into the wall.
Name:
Anonymous2015-12-24 0:43
>>43 That's perfectly reasonable. Only an autistic turbonerd like Cudder would want to memorize and mentally manage the 500 stage pipeline on x86. Close off the difficult areas and let the optimizer go to work on it.
Name:
Anonymous2015-12-24 2:51
>>12 I'm a CEO of four large companies, and a professor at Harvard and a spaceman. I just got back from my last mission to space, and am also a racecar driver so I will have to go racing soon, but maybe I'll have some time before then. If some females don't call me up to do sex with them, because I'm also a big sex-haver and do it like many times a day. I graduated excelsior cum laude from Space University 25 years ago, and apparently they didn't teach me to read directions at Space University because I did not notice that the OP wants me to reply to the maillist and not post in this thread. So that's why I'm sharing all of this with you guys. I've developed software for the first computer ever, worked at IBM as a bad ass computer inventor, designed the x86 processor, and also developed software for spaceships, and also have lots of sex with females, and hopefully you will see me as qualified to do some serious PHP development here (C is obsolete and only sex non-havers use it).
If you standardized what your compiler/environment does with UB, you have fixed it.
Trying to trap & report UB is fucking stupid, and the halting problem is part of and/or proof of that idiotic response to this thread.
Let me see if I understand. So when your compiler tells you that you're using a not definitely initialized variable, you have fixed the UB problem. But when your code analyzer tells you that you're using a not definitely initialized variable, you are being fucking stupid and halting problem proves you wrong?
I'm beginning to suspect that you fuckers have no clue what UB actually is, I mean, which cases are marked as UB in C, so you're talking out of your asses about solutions to some entirely imaginary problematic cases.
Name:
Anonymous2015-12-24 14:14
How applicable is the Halting problem on non-Turing machines anyway? Oh, you thought your shitputer was Turing complete? Well what would happen if it runs out of memory? Nah, it's just a finite state machine with lots of states. A static analyzer doesn't have to check an infinite problem space like the Halting problem falls victim to.
Oh, you thought your shitputer was Turing complete?
Obviously as soon as you add the ability to interface with unlimited external storage (via internet for example) all you need is enough states to implement an UTM.
Name:
Anonymous2015-12-24 15:57
>>52 Thw tape is infinite, so the states in a TM is irrelevant. But expand your memory to the entire universe and it's still finite. The DFSM state count will grow with O(22n) where n is the tape size of the shitputer, but it is still finite.