It is blatant gender discrimination but that isn't how most people see it since they don't look at individuals as individuals but as a combination of demographic group memberships.
It is odd, since it means that someone else makes kin selection for you and assumes that they can now make generalizations or assume that "your kind" all share one mind and one bank account.
Some clever people realized that they could exploit this incorrect viewpoint for personal political gain so they decided to use it like a wedge. They are just political opportunists and the only way around them is the unpopular position of promoting true equality through individual merit assessment.
It's about avoiding the god-awful raw pointer math found in this function. It's about properly bounding values. It's about enforcing the sorts of checks that come naturally to programmers with more experience and less bravado.
This is the definition of "style" which I would like to see more of because I completely agree with that statement. The problem is that I have worked in environments where "style" was literally formatting and it created a culture where nobody could see the forest through the trees and it meant actual quality was pretty terrible (bugs, leaks, etc).
"Style" is a word I keep at a distance since too many developers think it is all about being some definition of "pretty" even though the thing doesn't actually work.
In my experience, focusing on "coding style" makes code quality drop since it creates a culture where "review" is simply making sure you dotted the i's and crossed the t's without actually reading the sentence.
If there is one common belief held by all developers it is that their style is "correct" while everyone else is "wrong". The only difference is now the define wrong: "ugly", "inconsistent", "unclear", "confusing", "hard to maintain", "brittle", etc. If you want to see what they actually mean, ask them to quantify the problem and they will either get to the point or get very aggressive.
At the end of the day, understanding the logical idea behind the code is the most important thing followed by the correct translation of the idea into a sequential language.
While I don't like the OpenSSL style, personally, I don't see it as being related to this problem.
This has little to do with any C-specific. If you were re-using a buffer in some managed runtime, you would still see the same problem.
The problem is related to a missing check on a user-provided value. It is a pretty common kind of bug, really, since it is isn't often obvious which level of the stack was supposed to check it (hence why assertions are helpful - this would have been a crash, rather than a security hole).
The unfortunate thing is that this kind of bug detection isn't easily automated (since it is a logical oversight, not something actually incorrect). The only reason why this one got so much attention is because so many people rely on it for, ironically, security.
Logical oversight is not specific to one language or even kind of language so we will be fighting this kind of bug until the end of time (just like how we still deal with it in the real world - this isn't even computer-specific).
Yes, the ability to add/remove storage devices is done on the live file system.
I haven't played with it myself but I know that there was talk of using this for OS installation (beyond the more obvious live disk replacement possibility): -boot from live DVD -start installation is just "add new device to pool" (returns immediately), followed by "remove DVD device from pool" -the "remove" doesn't return until it has finished migrating (and possibly balancing, if you added several devices as the target) -once "remove" finishes, it ejects the DVD and tells you that installation has completed
It is neat since it means that your installation is "complete" at the moment you tell it to "start". You can start using the system immediately without waiting for the installation to actually write anything and no reboot is required.
Obvious example: -your data model has a function to get "n" entries from the data store -someone passes in "five" (or "purple", array(5), whatever) -an empty array is returned since the thing you passed in could not be evaluated as a numerical value (or you get a runtime exception of some sort, if you are lucky)
The problem here is that the caller is incorrect and the compiler would have told them that, had you specified that you required an int type.
So, instead of a 1-minute fix for a compilation error, it is potentially hours of hunting down why the program is providing incorrect results (since the actual problem is probably reported by a user due to a confusing result much further down the line).
I wish it were easier to explain that to less experienced developers (I remember being young and shared the common delusion that types were bad).
These days, it is intensely frustrating to work on a team with inexperienced developers who want to use all the "trendy" languages and frameworks only to get bogged down in constant re-writes or debugging once they realize that nobody can actually tell which parts of the project, if any, are "correct" (or even executed, in some cases).
When you point out that many of these problems are trivially decidable at compile time, they just dismiss you as being out of touch since "we don't compile anything before executing it, gramps."
Instead of listening to your argument, they just dismiss you for being old (you know, early 30s) and not understanding the "new" technology.
It surprising but nice to see someone stepping outside of the "just do what we have done before" box but I suppose there is precedent for SUSE (given the mention of ReiserFS).
Personally, I have been using BTRFS on a few of my systems for a little over a year and it is quite nice. Later versions have some really intriguing snapshot delta capabilities but my main win, with a slightly older version, is the big benefit of reduced disk I/O via transparent compression.
The way that it manages storage pools looks good, as well, although I haven't tried playing with it yet (the systems using it have lopsided disk geometries so it wouldn't be appropriate).
On one level, it depends on their memory topology (how many components are fighting over that particular memory bus - this _should_ be pretty good in a game console).
In general, rendering a large scene takes immense memory bandwidth as the data required to describe the scene (GL commands, texture data, other data for shaders, etc) and the representation of the output (framebuffer, other pixel buffers, etc) are very large.
Then again, my main background in this area is working with compositors (where bandwidth was the limiting factor - in both texture upload and frame composite), so this data profile might push all the limits into direct computation.
In any case, if you are limited purely by computation, it is just a numbers game to see what (if any) trade-off would be required to get the second framebuffer for a given game.
What is "processing required for the VR"? Beyond the question of whether or not they need to render a second frame for the other eye (or if they are just going to show the one scene to both eyes), what else is required?
The big question seems to be whether or not the device will be light enough and whether or not they can build it economically.
The most peculiar thing which comes to my mind is why they want 1080 at such a proximity that the eye is unlikely to see such high resolution.
I am not sure what more processing capability would be required, though.
Presumably (and this might be nonsense since I have never used the system), they already determine what sound goes into each channel based on the location and orientation of the view of the player (this is old-hat OpenAL stuff). Determining the orientation is done via the analog input of the controller so really they just need to convert the gyroscope data of the headset into the orientation language used by their input system. Other than that, it should just be a matter of running the video and audio to the headset, as opposed to the TV.
The hard part with this is typically just in building the hardware light enough that it doesn't cause neck strain in the user.
If they are trying to build stereoscopic 1080p, then you have the difficulty of rendering the scene twice (well, 2x over the normal number of render passes) and then reading out from 2 framebuffers. That is mostly a question of memory bandwidth in the GPU, though, and how their display controllers arbitrate the bus.
Where is this buffer overflow occurring? It would need to be happening in memory which is both writable and executable, which doesn't exist on SELinux.
This is largely the problem that SELinux (or non-executable memory, in general) was designed to resolve.
How can it spray itself over the writable area and mark itself executable if it isn't already running?
You would need the existing (trusted) code of the application to spray the malicious code into a writable buffer and mark it executable before this problem could occur.
Let's keep this on topic: no matter what this library accomplishes (and whether that is needed or not), why does it need to map any region of memory as both writable and executable?
Unless they are targeting some ancient (read: probably not still supported by the kernel or loader and therefore moot) ABI which uses text-segment relocations, I really don't get what they could possibly be doing to require this.
1) Map the memory as writable to populate it and then remap it as executable to run it. This way, it can only be one thing at a time which means that the malicious code can't enable itself.
2) Map the memory at 2 virtual addresses, with different permissions. One virtual address is for writing and the other is for execution. This means that knowing the program counter or stack pointer isn't enough to write malicious code.
This is a big factor to keep in mind and I strongly agree.
What do you want from life? If you want money and perks, then stay where it is cushy. If you want to push yourself and do interesting and challenging things, then take the plunge.
Personally, I find that most software development jobs pay far more than you need to survive but most just treat you like a cog in a machine and have few opportunities to do interesting things. A good pay check is nice but it is merely existing whereas an exciting job is truly living.
While I generally agree with what you said, there are a few things to note.
Existing lifeforms don't really change the concentration of atmospheric CO2 in any substantial way as they are part of the carbon cycle. The slow conversion of living matter into fossil fuels eventually reduces it as it is effectively a kind of natural sequestration. Burning fossil fuels reverses this cycle very quickly so the issue isn't with production or consumption of CO2 but whether it is in the atmosphere or suspended elsewhere.
The issue with power sources is that all of them, other than nuclear, are fundamentally solar power. The only difference is in whether you capture the energy directly (like a solar cell or solar power plant) or indirectly capture it in some stored medium (like oil or wind). Unless you use nuclear, all surface-based energy production is limited by the amount of sun reaching the surface.
Therefore, the true finite resource is surface area. Nuclear gives us an interesting way around that limitation.
Slashdot Mirror
It is blatant gender discrimination but that isn't how most people see it since they don't look at individuals as individuals but as a combination of demographic group memberships.
It is odd, since it means that someone else makes kin selection for you and assumes that they can now make generalizations or assume that "your kind" all share one mind and one bank account.
Some clever people realized that they could exploit this incorrect viewpoint for personal political gain so they decided to use it like a wedge. They are just political opportunists and the only way around them is the unpopular position of promoting true equality through individual merit assessment.
It's about avoiding the god-awful raw pointer math found in this function. It's about properly bounding values. It's about enforcing the sorts of checks that come naturally to programmers with more experience and less bravado.
This is the definition of "style" which I would like to see more of because I completely agree with that statement. The problem is that I have worked in environments where "style" was literally formatting and it created a culture where nobody could see the forest through the trees and it meant actual quality was pretty terrible (bugs, leaks, etc).
"Style" is a word I keep at a distance since too many developers think it is all about being some definition of "pretty" even though the thing doesn't actually work.
In my experience, focusing on "coding style" makes code quality drop since it creates a culture where "review" is simply making sure you dotted the i's and crossed the t's without actually reading the sentence.
If there is one common belief held by all developers it is that their style is "correct" while everyone else is "wrong". The only difference is now the define wrong: "ugly", "inconsistent", "unclear", "confusing", "hard to maintain", "brittle", etc. If you want to see what they actually mean, ask them to quantify the problem and they will either get to the point or get very aggressive.
At the end of the day, understanding the logical idea behind the code is the most important thing followed by the correct translation of the idea into a sequential language.
While I don't like the OpenSSL style, personally, I don't see it as being related to this problem.
This has little to do with any C-specific. If you were re-using a buffer in some managed runtime, you would still see the same problem.
The problem is related to a missing check on a user-provided value. It is a pretty common kind of bug, really, since it is isn't often obvious which level of the stack was supposed to check it (hence why assertions are helpful - this would have been a crash, rather than a security hole).
The unfortunate thing is that this kind of bug detection isn't easily automated (since it is a logical oversight, not something actually incorrect). The only reason why this one got so much attention is because so many people rely on it for, ironically, security.
Logical oversight is not specific to one language or even kind of language so we will be fighting this kind of bug until the end of time (just like how we still deal with it in the real world - this isn't even computer-specific).
Yes, the ability to add/remove storage devices is done on the live file system.
I haven't played with it myself but I know that there was talk of using this for OS installation (beyond the more obvious live disk replacement possibility):
-boot from live DVD
-start installation is just "add new device to pool" (returns immediately), followed by "remove DVD device from pool"
-the "remove" doesn't return until it has finished migrating (and possibly balancing, if you added several devices as the target)
-once "remove" finishes, it ejects the DVD and tells you that installation has completed
It is neat since it means that your installation is "complete" at the moment you tell it to "start". You can start using the system immediately without waiting for the installation to actually write anything and no reboot is required.
Obvious example:
-your data model has a function to get "n" entries from the data store
-someone passes in "five" (or "purple", array(5), whatever)
-an empty array is returned since the thing you passed in could not be evaluated as a numerical value (or you get a runtime exception of some sort, if you are lucky)
The problem here is that the caller is incorrect and the compiler would have told them that, had you specified that you required an int type.
So, instead of a 1-minute fix for a compilation error, it is potentially hours of hunting down why the program is providing incorrect results (since the actual problem is probably reported by a user due to a confusing result much further down the line).
I wish it were easier to explain that to less experienced developers (I remember being young and shared the common delusion that types were bad).
These days, it is intensely frustrating to work on a team with inexperienced developers who want to use all the "trendy" languages and frameworks only to get bogged down in constant re-writes or debugging once they realize that nobody can actually tell which parts of the project, if any, are "correct" (or even executed, in some cases).
When you point out that many of these problems are trivially decidable at compile time, they just dismiss you as being out of touch since "we don't compile anything before executing it, gramps."
Instead of listening to your argument, they just dismiss you for being old (you know, early 30s) and not understanding the "new" technology.
It surprising but nice to see someone stepping outside of the "just do what we have done before" box but I suppose there is precedent for SUSE (given the mention of ReiserFS).
Personally, I have been using BTRFS on a few of my systems for a little over a year and it is quite nice. Later versions have some really intriguing snapshot delta capabilities but my main win, with a slightly older version, is the big benefit of reduced disk I/O via transparent compression.
The way that it manages storage pools looks good, as well, although I haven't tried playing with it yet (the systems using it have lopsided disk geometries so it wouldn't be appropriate).
On one level, it depends on their memory topology (how many components are fighting over that particular memory bus - this _should_ be pretty good in a game console).
In general, rendering a large scene takes immense memory bandwidth as the data required to describe the scene (GL commands, texture data, other data for shaders, etc) and the representation of the output (framebuffer, other pixel buffers, etc) are very large.
Then again, my main background in this area is working with compositors (where bandwidth was the limiting factor - in both texture upload and frame composite), so this data profile might push all the limits into direct computation.
In any case, if you are limited purely by computation, it is just a numbers game to see what (if any) trade-off would be required to get the second framebuffer for a given game.
What is "processing required for the VR"? Beyond the question of whether or not they need to render a second frame for the other eye (or if they are just going to show the one scene to both eyes), what else is required?
The big question seems to be whether or not the device will be light enough and whether or not they can build it economically.
The most peculiar thing which comes to my mind is why they want 1080 at such a proximity that the eye is unlikely to see such high resolution.
I am not sure what more processing capability would be required, though.
Presumably (and this might be nonsense since I have never used the system), they already determine what sound goes into each channel based on the location and orientation of the view of the player (this is old-hat OpenAL stuff). Determining the orientation is done via the analog input of the controller so really they just need to convert the gyroscope data of the headset into the orientation language used by their input system. Other than that, it should just be a matter of running the video and audio to the headset, as opposed to the TV.
The hard part with this is typically just in building the hardware light enough that it doesn't cause neck strain in the user.
If they are trying to build stereoscopic 1080p, then you have the difficulty of rendering the scene twice (well, 2x over the normal number of render passes) and then reading out from 2 framebuffers. That is mostly a question of memory bandwidth in the GPU, though, and how their display controllers arbitrate the bus.
Where is this buffer overflow occurring? It would need to be happening in memory which is both writable and executable, which doesn't exist on SELinux.
This is largely the problem that SELinux (or non-executable memory, in general) was designed to resolve.
But why would the audio decoder be implementing its own JIT?
It should already be a native decoder.
How can it spray itself over the writable area and mark itself executable if it isn't already running?
You would need the existing (trusted) code of the application to spray the malicious code into a writable buffer and mark it executable before this problem could occur.
Agreed.
Let's keep this on topic: no matter what this library accomplishes (and whether that is needed or not), why does it need to map any region of memory as both writable and executable?
Unless they are targeting some ancient (read: probably not still supported by the kernel or loader and therefore moot) ABI which uses text-segment relocations, I really don't get what they could possibly be doing to require this.
There are 2 ways of doing this:
1) Map the memory as writable to populate it and then remap it as executable to run it. This way, it can only be one thing at a time which means that the malicious code can't enable itself.
2) Map the memory at 2 virtual addresses, with different permissions. One virtual address is for writing and the other is for execution. This means that knowing the program counter or stack pointer isn't enough to write malicious code.
This is a big factor to keep in mind and I strongly agree.
What do you want from life? If you want money and perks, then stay where it is cushy. If you want to push yourself and do interesting and challenging things, then take the plunge.
Personally, I find that most software development jobs pay far more than you need to survive but most just treat you like a cog in a machine and have few opportunities to do interesting things. A good pay check is nice but it is merely existing whereas an exciting job is truly living.
While I generally agree with what you said, there are a few things to note. Existing lifeforms don't really change the concentration of atmospheric CO2 in any substantial way as they are part of the carbon cycle. The slow conversion of living matter into fossil fuels eventually reduces it as it is effectively a kind of natural sequestration. Burning fossil fuels reverses this cycle very quickly so the issue isn't with production or consumption of CO2 but whether it is in the atmosphere or suspended elsewhere. The issue with power sources is that all of them, other than nuclear, are fundamentally solar power. The only difference is in whether you capture the energy directly (like a solar cell or solar power plant) or indirectly capture it in some stored medium (like oil or wind). Unless you use nuclear, all surface-based energy production is limited by the amount of sun reaching the surface. Therefore, the true finite resource is surface area. Nuclear gives us an interesting way around that limitation.