OpenBSD didn't outright state that they're going to port OpenSSL to other OSes when they get some money. They did outright state that they're not going to make LibreSSL portable until they get some money. But thanks for showing the fallacy of equivocation.
You just don't get it. You're assuming that a function is perfect, that its code is provably correct. Well, we were originally talking about integrating new, not-broken, correct code into a code body which is incorrect, so that assumption is immediately useless here. Further, if your code is correct and perfect, why would you come back to modify it?
We're coming in to clean up bugs. Now we're taking code and integrating it from one changing code base into another changing code base. The new code may work properly, while the old has corner cases that break synergistically: some body of code may work properly only in the presence of a defect in some other body of code. Microsoft Windows' source code was published a decade or so ago, and it was rife with this--hacks on top of hacks.
Do you honestly think that this can be done by just "checking the function for correctness"? You've integrated some correct code from another codebase which now makes this part of your code correct. Unfortunately some other part of your code now fails and, in the most extreme cases, we've created a new exploitable condition!
So now you have to go back and assess impact. By changing this function, you change a lot of other code. That code has the same logic, but different data coming to it--it's the same cog shoved into a different machine. You can do analysis to see if your new function does anything different than the old function, if the conditions its output precipitates on can now produce different output. If you can't prove that it doesn't produce different output in some situations, then you must now assume that your program changes may have wide impact. This includes if your output may be between 1 and 255, and it is, but it may return 47 instead of 42.
You can reduce the probabilities, but you cannot eliminate the risk. OpenSSL merging LibreSSL code without doing impact analysis and making sure the new code doesn't open new vulnerabilities will incur risk. Hell, LibreSSL will face the risk of creating new vulnerabilities as it goes, so you may eliminate 100 problems and cause 1 and that's okay because you are 99 problems better. The risk OpenSSL faces is greater, because they may import defective code from LibreSSL, or they may import code that works but which is no longer broken in such a way as required by other (still broken) code present in OpenSSL but no longer in LibreSSL.
This kind of thing can only be evaluated on a case by case basis.
In the same way that 6,880 pound kerb weight gasoline V8 pickup trucks with 400HP engines getting worse MPG than 3,220 pound kerb weight V6 passenger vehicles with 220HP can only be evaluated on a case-by-case basis.
I'm sorry but I'm going by scientific basis here, by known principles that have been put into practice, re-examined, and attacked repeatedly by method (agile project management is one such method to attempt to make repeating work less of a problem; it does reduce the problem and reduce risk compared to waterfall for projects which have high risk, but it still doesn't make parity). It simply takes less effort to consolidate multiple tasks into single tasks, for example the task of understanding a code base (as you write it) and ensuring cross-platform portability requires two passes: if you implement portability later, you have to re-examine the code base, find non-portable code, then re-envision how you want to write this code so that it meets requirements both old and new. That same work is done the first time you write it, just with different constraints and more mass output; doing it this way the first time eliminates the difference.
I guess you like to drive to the super market and spend 2 hours shopping for detergent, eggs, bread, yogurt, flour, pasta, sauces, cheese, and produce; and then drive home and go out for another 15 minutes to the corner store to get milk. Me, I'll take the 30 second diversion to grab the milk while I'm grabbing the yogurt at the super market.
You do understand that POSIX and standard C libraries are essentially universal, and that OS-specific facilities are less-universal, right? POSIX compatibility gets me all BSD, AIX, System V, HPUX, Solaris, and OSX platforms; but I usually validate anything non-trivial against what's sane for Windows, if Windows is an eventual target. For something like a system allocator, Windows may not be a target: you can't really replace the system allocator anyway, whereas your allocator could get adopted by various libc implementations. For something like a MIDI sequencer, the choice of wxWidgets and portable middle-layer libraries or the cautious use of gtk+ facilities portable across all systems is usually a consideration.
From Day 0, I consider anything I do in my code against what my target platforms will be, and what facilities they are likely to not share. For example: All Unix systems are likely to share malloc() and mmap(). They're unlikely to share inotify or kevent facilities specific to Linux, which one should implement with caution. Likewise, relying on specialized system behavior is a big problem: a lot of people relied on the size of ints and longs, whereas I've always used uint32_t or int64_t or whatnot when the size had some real importance (i.e. in OpenSSL, that TLS heartbeat is a 16-bit value; you'd better not use 'unsigned short int' to refer to it, but rather 'uint16_t' from C99).
I learned C after I learned assembly. It seems unnatural to not consider the full impact of your programming code.
Oh I see. You're trying to ask for evidence that the sky is blue. Got it.
(It is considerably well-known that doing things to achieve the final goal in the first pass is vastly more efficient than doing things haphazardly with disregard to part of an end goal, then going back and adding the remaining requirements and redoing the work to fit with them. This is the basis for some archaic and probably outdated behavior commonly known as "planning".)
Ah, ok. SO like Segmexec in PaX where the address space is dual-mapped and split 50/50, or W^X where part of the memory is NX.
Mapped and unmapped memory is not relevant for the protection mechanism, UNLESS you want per-page protection (which is kinda stupid anyway, code should reside in its own descriptor).
Code resides in segments in a binary. A library has data and code segments, mapped separately. They're mapped per-page for memory management: if you experience memory pressure, small pages (4K) can be swapped out. Code pages get invalidated and re-read from the original source on disk if needed.
LDT in 32-bit flat protected mode is an interface I never saw. Odd. I only knew about the single segment (code, data) layout using CS and DS and SS.
What strikes me is the producer question. "Are we trying to make a good title, or are we going to bait customers with exclusive content so we get millions of people to buy our game before the reviews pour onto Amazon that it's garbage not worth playing?"
I target all platforms and avoid using any OS-specific facilities outside of #ifdef blocks, unless I'm writing something specifically for an OS that requires a particular facility (I.e. to enhance the OS, say like udev). Often I leave this to the people who wrote whatever Python modules I'm using these days.
Did... did you just argue that work doesn't take any units of labor? That there's not a shred of evidence that you need to actually do something to produce output?
You just argued that the world is magic and things rise out of the ether.
I actually find that quite hard to believe. The LDT was introduced with the 80286, in 1981. If you check both manuals I mentioned, you'll find indication that you cannot store a TSS in the LDT and some other special descriptor types.
As per Wikipedia:
There was no 'Executable' flag in the page table entry (page descriptor) in the 80386 and later x86 processors, until, to make this capability available to operating systems using the flat memory model, AMD added a "no-execute" or NX bit to the page table entry in its AMD64 architecture, providing a mechanism that can control execution per page rather than per whole segment.
What happens is your program starts its VMA with 16MB of non-mapped memory. Then you have the executable.text segment. Directly above that is the non-executable brk() segment (heap). Directly above that are anonymous mappings, including executable shared library.text segments. Finally, you have the stack.
So memory looks approximately like: nnnnXXXXWWWWXXWXWXnnnnnnnWWWWW for non-mapped, eXecutable, and Writable memory. All mapped is readable to simplify this model.
On x86, PROT_READ is also PROT_EXEC; there aren't 2 bits. While you can use a segmentation setup, it must be contiguous: setting the highest executable page to the top of the main executable makes the heap non-executable, but also makes all library code non-executable. Setting the highest executable page to just below the stack makes the stack non-executable, but leaves the heap and anonymous data mappings executable. There is no bit to say, "This part is executable, and this part isn't, and this next part is, but this next part isn't, this part is, and this last part isn't."
Hence the tricks with setting up ring-0 memory protection on data pages and then forcing a DTLB load if they're read/written, to act as a kernel-controlled NX bit.
You're missing a large point here: function 'int getBoundaryLength(myObject *p)' returns back a piece of information about boundary length. A lot of things use boundary length, and boundary length is stored in a variable 'L = getBoundaryLength(p)' which gets passed around and assigned to things in objects (structures, classes) and subsequently used by other functions such as 'int copyBuffer(char *d, char *s)'.
Modifying how getBoundaryLength() produces its return value has an impact on all of this code. Buffers allocated on that length passed to other functions may be too short; copy operations may be too long. These are things you must verify. So a one-line modification to a function can have huge, sweeping impact across your program.
You can pretend you know more about programming because you think you've invented a way for modifications to one function to have no impact on any other part of the code; but if you ever achieve that goal, gcc has a "dead code eliminator" which removes your entire function, unless it's exported and thus gcc can't verify that nothing else calls it to useful effect.
They're doing a huge amount of work. They're going to write portale code because they are good programmers but not going to to the porting---just like openssh. They write good solid portable code, other people port it, everyone wins.
Most peoples' definition of "portable code" is that it's, you know, portable. It runs on multiple platforms. Write once, run across all substantially-similar systems. For example: Unix utilities running on the POSIX platform are portable because the exact same unmodified source code can be compiled on any POSIX platform against the standard POSIX system headers and linked with the standard libraries and run. Much portable code also has OS specific performance enhancements: it may take advantage of an OS facility that is non-portable if available. Non-portable code is written in such a way that it must be modified to compile on other operating systems using standard, portable interfaces--a non-portable OS facility is used in all cases, and if not available then you cannot compile the code.
Your fallacy: Equivocation, the informal logical fallacy of calling two different things by the same name. In this case, "portability" (the ability to simply carry one thing from one place to another--in programming, the ability to compile unmodified code on various platforms which supply a standardized API) and "porting" (the act of making a thing portable--in programming, the act of rewriting non-portable software to be more portable by making it compile on additional platforms).
It's funny hoy you cite "eonomics" as your argument for why people should give you free stuff.
Yes. It's called wealth production. You see, if you use 1 unit of labor and produce 1 unit of output, you have created 0 wealth. If you use 2 units of labor and produce 1 unit of output, you destroy 1 unit of wealth. If you use 1 unit of labor and produce 2 units of output, you create wealth.
As I've explained, it takes some units of labor (effort, work) to fork a code base, greatly improve it in a way which makes it non-portable to the platforms the original code base was portable to, and then apply additional labor to modify the result to again make it portable to the same original target platforms. It takes some fewer units of labor to simply retain portability as you make the improvements. The end result of both of these strategies is the same; however, the second strategy requires fewer units of labor input--it destroys less wealth in the process of creating the same wealth output, thus it is economically more efficient.
Think about if you paid $10,000 for a car, then paid $1000 for new tires and $3000 to add a V6 engine to replace the I4. Now consider if instead you paid $12,000 for the higher model which comes with the upgraded tires and the V6 engine. In both cases you get the same car; however, in one case you get it for $14,000 and in the other you get it for $12,000. In the first case, additional labor is used to install, ship, and then remove the original equipment, which is then replaced with new equipment which must be installed and shipped. The first install-ship-remove cycle (and any re-shipping to get those parts to another place where they are useful) is avoided by doing it right the first time, which is where the $2000 savings in this example comes from (we assume in this model that the automaker uses a static margin model, where everything is produced and then has a certain marginal profit slapped onto it).
Why would you waste effort making additional work?
who says they're merging back? If they are then your whining is for nothing since it will be merged back. If not then your point is moot.
The libav people go to the ffmpeg repos, get code, and merge it into ffmpeg. Same with vice versa. Do you think only OpenBSD LibreSSL developers could merge code back to OpenSSL? Probably someone else is going to pull the code from LibreSSL and merge it; otherwise wouldn't OpenBSD LibreSSL developers just be OpenSSL developers?
Apparently you don't understand how programming works as a group process either, or how community dynamics in open source software work, or something. Somewhere you've failed to figure out how code gets from one place to another.
one of 3 things. It can also compute something based on the data passed to it and not modify the data passed. That's functional style, and is generally considered good practive.
And then you don't store that data anywhere, so that function doesn't impact any of the other code anywhere, because it doesn't impact any value that's passed on through the program, right?
For a 24kWh battery to go 72 miles, we're talking 1/3 kW. As I drive 30 miles per day 20 days per month, we're talking 200kWh... at my rate of about 12 cents per kWh for required solar load... $24/mo.
Tesla goes 250-300 miles, dunno where 84 miles comes from. It's funny, because the summary basically says that the Leaf won't be as good as the Model S base model.
Basically you're whining about how they're not (metaphorically) flying 5000 miles to fix up a house in your community
I'm arguing that they're (metaphorically) a part of a community, and that they're doing substantial work, but they're doing the work in such a way that the community which they are a part of will need to do substantial additional work to benefit from it. If they were to do the work slightly differently, they would not do substantially more work, and yet the whole community would face great benefit.
Things like Frama-C produce reports on impact analysis--you changed one line in one function and it affected 15% of your entire 2 million line code base.
That sounds like poor design. The OBSD people are world class experts at producing secure, audited OS level C code.
Ah, I see you don't understand how programming works.
Let's say you have a function. And you call that function. It does one of two things: either it modifies an object passed to it, or it modifies global state (global variables, etc.)
When you modify an object, every function which does something with the part of the object which has been modified is affected. If you can show paths whereby changing this code changes the behavior of this other code, which has an impact on this other code, then you have spread impact. For example: if your modified function computes a boundary condition, modifying a line of code which controls how the boundary condition is computed has an impact on every function which uses that boundary condition.
So when you modify, say, a certain data packet handler that produces a certain object, then every function that handles that object is impacted. You modify one line, and 50 functions are impacted. The data that they see could be different, as it's computed in a different way--a more efficient way that's identical, perhaps (unit tests can show this); or a different way which fixes a bug, changing the data set in some conditions, which impacts what data those other functions will get in practice.
That means merging code between divergent code bases has far-reaching implications.
That or install OpenBSD. And I can assure you it would be less work for you to port it than the strip down and audit in the first place.
There is a 100% chance that the work required to fix OpenSSL as-is and keep it portable between OSes is substantially less than the work required to first fix OpenSSL with reckless abandon and make it non-portable, then go back through and pick it apart and work out how to make it portable again.
That means this is a waste of development effort. It should be done correctly the first time, not done wrongly the first time by a bunch of whiny babies throwing a tantrum.
Basically yes. They're giving awesome stuff away for free. If you don't like it you can simply pretend it doesn't exist and you've lost nothing.
Except that OpenBSD's code base won't be made to work on anything not-OpenBSD, and has been stated to break unless someone pays OpenBSD to not break it. So there will either be continuous chance of breakage unless people pay continuously, or there will be a fork of the fork--which will turn into people porting it back into OpenSSL.
The continuous chance of breakage isn't visible now: they said they'd make it OS-agnostic if people pay; they didn't say they would put continuous effort thereafter into keeping it that way, but they didn't say they wouldn't. They've hinted, thus, that they want cash rather than developer contributions; and that OS portability is not a goal of the project, but rather a thing done under a sort of social agreement which can be lubricated with something called "currency". These terms are worrying, as they hint that LibreSSL development may continue recklessly after being re-based as platform agnostic, and thus may again break by happenstance, and perhaps will not unbreak as this is not a goal of the OpenBSD developers writing LibreSSL, but it could be if you provide more currency.
Tell you what, how about you come over to my house at a time of my choosing (I'm a busy man) and at your own expense (I don't see why I should have to pay you for travel if I'm not going to pay you for the work) and dig my garden for me for free and exactly how I like (it has to be just-so or it doesn't count).
Actually, in my community, I had a burned down house that was there for 14 years torn down. I've been recommended to put a fence around it so people don't walk through, but that would be ugly. Instead I've bought the lot, and planted fruit trees and lavender bushes, added a bee hive. So rather than a fenced-off ugly lot with a private park, I have applied similar (nearly identical) effort and gained a huge improvement for the community. Of course, trash does blow through occasionally and I have to rake it up out of the yard; that's almost exactly the same amount of work as anyway, what with twigs and leaves and lawn clippings from my normal tasks.
I could have, at nearly the same cost, placed a border fence instead, and then sold the house off to someone else. Then, if they were so inclined as to de-uglify the community, they could invest the added cost and effort to tear down and dispose of the fence, and then plan out and plant border plants (in my case, lavender) to make it nicer. When combining the expense and effort I put in with this added effort, we get significantly higher cost and effort than if I just go with this plan outright.
Similarly to the "doing it wrong the first time" pattern, my kitchen was built with a wide opening. I came in, cut down a wall, built across a half-height wall, moved a counter, and now my kitchen has 30% more floor space, 150% more cabinet space, 150% more appliance space. To do this initially would have taken an extra 90 minutes and $378; for me to do it as-is took 14 days of working time and an additional $1200, not including removal costs of excess materials from demolition.
So you see, this sort of "do it and do it over again" working behavior makes the community poorer. Rather than investing a few extra hours of time in multi-thousand-hour projects, we save 10-15 hours across years and create an additional several hundred hours of review and merging into diverging code bases, along with the increased risk in bugs as the code bases diverge and get features mutually migrated across, requiring additional labor for further review.
But we do get to tell people we're not doing a giant ego wank, and instead are doing what's best for the community.
Well, the OpenBSD people disagree with you. You also forgot the auditing of the code that they're goig to be doing once it's fixed. Much easier on a clean codebase.
That's part of the initial work. Once the code is re-ported and re-imported into the (diverging) OpenSSL base, it will require an additional audit. Things like Frama-C produce reports on impact analysis--you changed one line in one function and it affected 15% of your entire 2 million line code base.
Decades of research indicate that doing something not-quite-right the first time and then going back and redoing it requires more labor than doing it right the first time. We have an end state that we argue is good; and an intermediate state that moves away from that, with an alternate plan which moves directly toward the end state. The argument is that this other strategy reaches a given end state with less total work.
So they're buiding something they need for themselves personally, but are generous to make it available to everyone should anyone else need it. And they'll even let you freely modify it if it doesn't fit your needs! Not only that but if your mods are of no benefit to them but cleanly written and useful to others, they'll even go out of their way to include them in their project. What nice people. I think they should be applauded for their philanthropy.
They do sound like awfully nice people to me.
They're making a political move. To argue directly against your argument, I would have to argue for the closing of the OpenBSD project entirely. I have instead provided a counter-argument that they could, you know, contribute to the community at large instead of to their own ego.
This is a think-of-the-children move. "Look how bad these OpenSSL people are! We're going to do a bunch of work to make things better! But it won't be better for YOU! It's just really being done to mock OpenSSL and show you that we're awesome, because we have things YOU don't have! Oh, but you could do a bunch of extra work yourself to take OUR things back and improve YOUR things. We won't do that though, because we're selfish tantrum-babies! But, OUR thing is free, so you know. We're really awesome! And fuck you all who don't use our thing, we're not here to help you infidels! We should fly a plane into your house!"
Slashdot Mirror
OpenBSD didn't outright state that they're going to port OpenSSL to other OSes when they get some money. They did outright state that they're not going to make LibreSSL portable until they get some money. But thanks for showing the fallacy of equivocation.
You just don't get it. You're assuming that a function is perfect, that its code is provably correct. Well, we were originally talking about integrating new, not-broken, correct code into a code body which is incorrect, so that assumption is immediately useless here. Further, if your code is correct and perfect, why would you come back to modify it?
We're coming in to clean up bugs. Now we're taking code and integrating it from one changing code base into another changing code base. The new code may work properly, while the old has corner cases that break synergistically: some body of code may work properly only in the presence of a defect in some other body of code. Microsoft Windows' source code was published a decade or so ago, and it was rife with this--hacks on top of hacks.
Do you honestly think that this can be done by just "checking the function for correctness"? You've integrated some correct code from another codebase which now makes this part of your code correct. Unfortunately some other part of your code now fails and, in the most extreme cases, we've created a new exploitable condition!
So now you have to go back and assess impact. By changing this function, you change a lot of other code. That code has the same logic, but different data coming to it--it's the same cog shoved into a different machine. You can do analysis to see if your new function does anything different than the old function, if the conditions its output precipitates on can now produce different output. If you can't prove that it doesn't produce different output in some situations, then you must now assume that your program changes may have wide impact. This includes if your output may be between 1 and 255, and it is, but it may return 47 instead of 42.
You can reduce the probabilities, but you cannot eliminate the risk. OpenSSL merging LibreSSL code without doing impact analysis and making sure the new code doesn't open new vulnerabilities will incur risk. Hell, LibreSSL will face the risk of creating new vulnerabilities as it goes, so you may eliminate 100 problems and cause 1 and that's okay because you are 99 problems better. The risk OpenSSL faces is greater, because they may import defective code from LibreSSL, or they may import code that works but which is no longer broken in such a way as required by other (still broken) code present in OpenSSL but no longer in LibreSSL.
This kind of thing can only be evaluated on a case by case basis.
In the same way that 6,880 pound kerb weight gasoline V8 pickup trucks with 400HP engines getting worse MPG than 3,220 pound kerb weight V6 passenger vehicles with 220HP can only be evaluated on a case-by-case basis.
I'm sorry but I'm going by scientific basis here, by known principles that have been put into practice, re-examined, and attacked repeatedly by method (agile project management is one such method to attempt to make repeating work less of a problem; it does reduce the problem and reduce risk compared to waterfall for projects which have high risk, but it still doesn't make parity). It simply takes less effort to consolidate multiple tasks into single tasks, for example the task of understanding a code base (as you write it) and ensuring cross-platform portability requires two passes: if you implement portability later, you have to re-examine the code base, find non-portable code, then re-envision how you want to write this code so that it meets requirements both old and new. That same work is done the first time you write it, just with different constraints and more mass output; doing it this way the first time eliminates the difference.
I guess you like to drive to the super market and spend 2 hours shopping for detergent, eggs, bread, yogurt, flour, pasta, sauces, cheese, and produce; and then drive home and go out for another 15 minutes to the corner store to get milk. Me, I'll take the 30 second diversion to grab the milk while I'm grabbing the yogurt at the super market.
Hint: Python doesn't have #ifdef blocks.
You do understand that POSIX and standard C libraries are essentially universal, and that OS-specific facilities are less-universal, right? POSIX compatibility gets me all BSD, AIX, System V, HPUX, Solaris, and OSX platforms; but I usually validate anything non-trivial against what's sane for Windows, if Windows is an eventual target. For something like a system allocator, Windows may not be a target: you can't really replace the system allocator anyway, whereas your allocator could get adopted by various libc implementations. For something like a MIDI sequencer, the choice of wxWidgets and portable middle-layer libraries or the cautious use of gtk+ facilities portable across all systems is usually a consideration.
From Day 0, I consider anything I do in my code against what my target platforms will be, and what facilities they are likely to not share. For example: All Unix systems are likely to share malloc() and mmap(). They're unlikely to share inotify or kevent facilities specific to Linux, which one should implement with caution. Likewise, relying on specialized system behavior is a big problem: a lot of people relied on the size of ints and longs, whereas I've always used uint32_t or int64_t or whatnot when the size had some real importance (i.e. in OpenSSL, that TLS heartbeat is a 16-bit value; you'd better not use 'unsigned short int' to refer to it, but rather 'uint16_t' from C99).
I learned C after I learned assembly. It seems unnatural to not consider the full impact of your programming code.
Oh I see. You're trying to ask for evidence that the sky is blue. Got it.
(It is considerably well-known that doing things to achieve the final goal in the first pass is vastly more efficient than doing things haphazardly with disregard to part of an end goal, then going back and adding the remaining requirements and redoing the work to fit with them. This is the basis for some archaic and probably outdated behavior commonly known as "planning".)
Ah, ok. SO like Segmexec in PaX where the address space is dual-mapped and split 50/50, or W^X where part of the memory is NX.
Mapped and unmapped memory is not relevant for the protection mechanism, UNLESS you want per-page protection (which is kinda stupid anyway, code should reside in its own descriptor).
Code resides in segments in a binary. A library has data and code segments, mapped separately. They're mapped per-page for memory management: if you experience memory pressure, small pages (4K) can be swapped out. Code pages get invalidated and re-read from the original source on disk if needed.
LDT in 32-bit flat protected mode is an interface I never saw. Odd. I only knew about the single segment (code, data) layout using CS and DS and SS.
These parents are idiots. I found their kids on Facebook, as well as the candy van stalkers that have been trying to meet up with them.
What strikes me is the producer question. "Are we trying to make a good title, or are we going to bait customers with exclusive content so we get millions of people to buy our game before the reviews pour onto Amazon that it's garbage not worth playing?"
I target all platforms and avoid using any OS-specific facilities outside of #ifdef blocks, unless I'm writing something specifically for an OS that requires a particular facility (I.e. to enhance the OS, say like udev). Often I leave this to the people who wrote whatever Python modules I'm using these days.
Did... did you just argue that work doesn't take any units of labor? That there's not a shred of evidence that you need to actually do something to produce output?
You just argued that the world is magic and things rise out of the ether.
I actually find that quite hard to believe. The LDT was introduced with the 80286, in 1981. If you check both manuals I mentioned, you'll find indication that you cannot store a TSS in the LDT and some other special descriptor types.
As per Wikipedia:
There was no 'Executable' flag in the page table entry (page descriptor) in the 80386 and later x86 processors, until, to make this capability available to operating systems using the flat memory model, AMD added a "no-execute" or NX bit to the page table entry in its AMD64 architecture, providing a mechanism that can control execution per page rather than per whole segment.
What happens is your program starts its VMA with 16MB of non-mapped memory. Then you have the executable .text segment. Directly above that is the non-executable brk() segment (heap). Directly above that are anonymous mappings, including executable shared library .text segments. Finally, you have the stack.
So memory looks approximately like: nnnnXXXXWWWWXXWXWXnnnnnnnWWWWW for non-mapped, eXecutable, and Writable memory. All mapped is readable to simplify this model.
On x86, PROT_READ is also PROT_EXEC; there aren't 2 bits. While you can use a segmentation setup, it must be contiguous: setting the highest executable page to the top of the main executable makes the heap non-executable, but also makes all library code non-executable. Setting the highest executable page to just below the stack makes the stack non-executable, but leaves the heap and anonymous data mappings executable. There is no bit to say, "This part is executable, and this part isn't, and this next part is, but this next part isn't, this part is, and this last part isn't."
Hence the tricks with setting up ring-0 memory protection on data pages and then forcing a DTLB load if they're read/written, to act as a kernel-controlled NX bit.
You're missing a large point here: function 'int getBoundaryLength(myObject *p)' returns back a piece of information about boundary length. A lot of things use boundary length, and boundary length is stored in a variable 'L = getBoundaryLength(p)' which gets passed around and assigned to things in objects (structures, classes) and subsequently used by other functions such as 'int copyBuffer(char *d, char *s)'.
Modifying how getBoundaryLength() produces its return value has an impact on all of this code. Buffers allocated on that length passed to other functions may be too short; copy operations may be too long. These are things you must verify. So a one-line modification to a function can have huge, sweeping impact across your program.
You can pretend you know more about programming because you think you've invented a way for modifications to one function to have no impact on any other part of the code; but if you ever achieve that goal, gcc has a "dead code eliminator" which removes your entire function, unless it's exported and thus gcc can't verify that nothing else calls it to useful effect.
They're doing a huge amount of work. They're going to write portale code because they are good programmers but not going to to the porting---just like openssh. They write good solid portable code, other people port it, everyone wins.
Most peoples' definition of "portable code" is that it's, you know, portable. It runs on multiple platforms. Write once, run across all substantially-similar systems. For example: Unix utilities running on the POSIX platform are portable because the exact same unmodified source code can be compiled on any POSIX platform against the standard POSIX system headers and linked with the standard libraries and run. Much portable code also has OS specific performance enhancements: it may take advantage of an OS facility that is non-portable if available. Non-portable code is written in such a way that it must be modified to compile on other operating systems using standard, portable interfaces--a non-portable OS facility is used in all cases, and if not available then you cannot compile the code.
Your fallacy: Equivocation, the informal logical fallacy of calling two different things by the same name. In this case, "portability" (the ability to simply carry one thing from one place to another--in programming, the ability to compile unmodified code on various platforms which supply a standardized API) and "porting" (the act of making a thing portable--in programming, the act of rewriting non-portable software to be more portable by making it compile on additional platforms).
It's funny hoy you cite "eonomics" as your argument for why people should give you free stuff.
Yes. It's called wealth production. You see, if you use 1 unit of labor and produce 1 unit of output, you have created 0 wealth. If you use 2 units of labor and produce 1 unit of output, you destroy 1 unit of wealth. If you use 1 unit of labor and produce 2 units of output, you create wealth.
As I've explained, it takes some units of labor (effort, work) to fork a code base, greatly improve it in a way which makes it non-portable to the platforms the original code base was portable to, and then apply additional labor to modify the result to again make it portable to the same original target platforms. It takes some fewer units of labor to simply retain portability as you make the improvements. The end result of both of these strategies is the same; however, the second strategy requires fewer units of labor input--it destroys less wealth in the process of creating the same wealth output, thus it is economically more efficient.
Think about if you paid $10,000 for a car, then paid $1000 for new tires and $3000 to add a V6 engine to replace the I4. Now consider if instead you paid $12,000 for the higher model which comes with the upgraded tires and the V6 engine. In both cases you get the same car; however, in one case you get it for $14,000 and in the other you get it for $12,000. In the first case, additional labor is used to install, ship, and then remove the original equipment, which is then replaced with new equipment which must be installed and shipped. The first install-ship-remove cycle (and any re-shipping to get those parts to another place where they are useful) is avoided by doing it right the first time, which is where the $2000 savings in this example comes from (we assume in this model that the automaker uses a static margin model, where everything is produced and then has a certain marginal profit slapped onto it).
Why would you waste effort making additional work?
You assert that LibreSSL is OS agnostic even if it works only on one OS. Well, Internet Explorer only works on one OS, so it's OS agnostic too.
who says they're merging back? If they are then your whining is for nothing since it will be merged back. If not then your point is moot.
The libav people go to the ffmpeg repos, get code, and merge it into ffmpeg. Same with vice versa. Do you think only OpenBSD LibreSSL developers could merge code back to OpenSSL? Probably someone else is going to pull the code from LibreSSL and merge it; otherwise wouldn't OpenBSD LibreSSL developers just be OpenSSL developers?
Apparently you don't understand how programming works as a group process either, or how community dynamics in open source software work, or something. Somewhere you've failed to figure out how code gets from one place to another.
one of 3 things. It can also compute something based on the data passed to it and not modify the data passed. That's functional style, and is generally considered good practive.
And then you don't store that data anywhere, so that function doesn't impact any of the other code anywhere, because it doesn't impact any value that's passed on through the program, right?
where do you get free electricity?
For a 24kWh battery to go 72 miles, we're talking 1/3 kW. As I drive 30 miles per day 20 days per month, we're talking 200kWh ... at my rate of about 12 cents per kWh for required solar load... $24/mo.
Probably 1000.
Tesla goes 250-300 miles, dunno where 84 miles comes from. It's funny, because the summary basically says that the Leaf won't be as good as the Model S base model.
Like Internet Explorer is OS agnostic, it's just not ported to other OSes.
Anyway it's irrelevant. In 5 weeks no one will even remember LibreSSL was a thing.
Basically you're whining about how they're not (metaphorically) flying 5000 miles to fix up a house in your community
I'm arguing that they're (metaphorically) a part of a community, and that they're doing substantial work, but they're doing the work in such a way that the community which they are a part of will need to do substantial additional work to benefit from it. If they were to do the work slightly differently, they would not do substantially more work, and yet the whole community would face great benefit.
It's basic economics.
Things like Frama-C produce reports on impact analysis--you changed one line in one function and it affected 15% of your entire 2 million line code base.
That sounds like poor design. The OBSD people are world class experts at producing secure, audited OS level C code.
Ah, I see you don't understand how programming works.
Let's say you have a function. And you call that function. It does one of two things: either it modifies an object passed to it, or it modifies global state (global variables, etc.)
When you modify an object, every function which does something with the part of the object which has been modified is affected. If you can show paths whereby changing this code changes the behavior of this other code, which has an impact on this other code, then you have spread impact. For example: if your modified function computes a boundary condition, modifying a line of code which controls how the boundary condition is computed has an impact on every function which uses that boundary condition.
So when you modify, say, a certain data packet handler that produces a certain object, then every function that handles that object is impacted. You modify one line, and 50 functions are impacted. The data that they see could be different, as it's computed in a different way--a more efficient way that's identical, perhaps (unit tests can show this); or a different way which fixes a bug, changing the data set in some conditions, which impacts what data those other functions will get in practice.
That means merging code between divergent code bases has far-reaching implications.
That or install OpenBSD. And I can assure you it would be less work for you to port it than the strip down and audit in the first place.
There is a 100% chance that the work required to fix OpenSSL as-is and keep it portable between OSes is substantially less than the work required to first fix OpenSSL with reckless abandon and make it non-portable, then go back through and pick it apart and work out how to make it portable again.
That means this is a waste of development effort. It should be done correctly the first time, not done wrongly the first time by a bunch of whiny babies throwing a tantrum.
Basically yes. They're giving awesome stuff away for free. If you don't like it you can simply pretend it doesn't exist and you've lost nothing.
Right. The OpenBSD developers are worth nothing.
Except that OpenBSD's code base won't be made to work on anything not-OpenBSD, and has been stated to break unless someone pays OpenBSD to not break it. So there will either be continuous chance of breakage unless people pay continuously, or there will be a fork of the fork--which will turn into people porting it back into OpenSSL.
The continuous chance of breakage isn't visible now: they said they'd make it OS-agnostic if people pay; they didn't say they would put continuous effort thereafter into keeping it that way, but they didn't say they wouldn't. They've hinted, thus, that they want cash rather than developer contributions; and that OS portability is not a goal of the project, but rather a thing done under a sort of social agreement which can be lubricated with something called "currency". These terms are worrying, as they hint that LibreSSL development may continue recklessly after being re-based as platform agnostic, and thus may again break by happenstance, and perhaps will not unbreak as this is not a goal of the OpenBSD developers writing LibreSSL, but it could be if you provide more currency.
So it's wasteful. It may be hostile.
Tell you what, how about you come over to my house at a time of my choosing (I'm a busy man) and at your own expense (I don't see why I should have to pay you for travel if I'm not going to pay you for the work) and dig my garden for me for free and exactly how I like (it has to be just-so or it doesn't count).
Actually, in my community, I had a burned down house that was there for 14 years torn down. I've been recommended to put a fence around it so people don't walk through, but that would be ugly. Instead I've bought the lot, and planted fruit trees and lavender bushes, added a bee hive. So rather than a fenced-off ugly lot with a private park, I have applied similar (nearly identical) effort and gained a huge improvement for the community. Of course, trash does blow through occasionally and I have to rake it up out of the yard; that's almost exactly the same amount of work as anyway, what with twigs and leaves and lawn clippings from my normal tasks.
I could have, at nearly the same cost, placed a border fence instead, and then sold the house off to someone else. Then, if they were so inclined as to de-uglify the community, they could invest the added cost and effort to tear down and dispose of the fence, and then plan out and plant border plants (in my case, lavender) to make it nicer. When combining the expense and effort I put in with this added effort, we get significantly higher cost and effort than if I just go with this plan outright.
Similarly to the "doing it wrong the first time" pattern, my kitchen was built with a wide opening. I came in, cut down a wall, built across a half-height wall, moved a counter, and now my kitchen has 30% more floor space, 150% more cabinet space, 150% more appliance space. To do this initially would have taken an extra 90 minutes and $378; for me to do it as-is took 14 days of working time and an additional $1200, not including removal costs of excess materials from demolition.
So you see, this sort of "do it and do it over again" working behavior makes the community poorer. Rather than investing a few extra hours of time in multi-thousand-hour projects, we save 10-15 hours across years and create an additional several hundred hours of review and merging into diverging code bases, along with the increased risk in bugs as the code bases diverge and get features mutually migrated across, requiring additional labor for further review.
But we do get to tell people we're not doing a giant ego wank, and instead are doing what's best for the community.
Well, the OpenBSD people disagree with you. You also forgot the auditing of the code that they're goig to be doing once it's fixed. Much easier on a clean codebase.
That's part of the initial work. Once the code is re-ported and re-imported into the (diverging) OpenSSL base, it will require an additional audit. Things like Frama-C produce reports on impact analysis--you changed one line in one function and it affected 15% of your entire 2 million line code base.
Decades of research indicate that doing something not-quite-right the first time and then going back and redoing it requires more labor than doing it right the first time. We have an end state that we argue is good; and an intermediate state that moves away from that, with an alternate plan which moves directly toward the end state. The argument is that this other strategy reaches a given end state with less total work.
So they're buiding something they need for themselves personally, but are generous to make it available to everyone should anyone else need it. And they'll even let you freely modify it if it doesn't fit your needs! Not only that but if your mods are of no benefit to them but cleanly written and useful to others, they'll even go out of their way to include them in their project. What nice people. I think they should be applauded for their philanthropy.
They do sound like awfully nice people to me.
They're making a political move. To argue directly against your argument, I would have to argue for the closing of the OpenBSD project entirely. I have instead provided a counter-argument that they could, you know, contribute to the community at large instead of to their own ego.
This is a think-of-the-children move. "Look how bad these OpenSSL people are! We're going to do a bunch of work to make things better! But it won't be better for YOU! It's just really being done to mock OpenSSL and show you that we're awesome, because we have things YOU don't have! Oh, but you could do a bunch of extra work yourself to take OUR things back and improve YOUR things. We won't do that though, because we're selfish tantrum-babies! But, OUR thing is free, so you know. We're really awesome! And fuck you all who don't use our thing, we're not here to help you infidels! We should fly a plane into your house!"