Recent Features
| |||||||||||||
On breaking thingsOn breaking thingsPosted Nov 25, 2010 2:41 UTC (Thu) by nybble41 (subscriber, #55106)In reply to: On breaking things by rwmj Parent article: On breaking things
"Why not implement a kind of ASLR in the kernel instead?"
I expect that is exactly the sort of thing the removal of non-root kallsyms access was for in the first place. The file reports the address of every kernel symbol, after all, which would render ASLR largely ineffective to anything capable of reading it.
On another note, there is more to these cases than simply the way the breakage is being handled. The glibc change only broke programs which used the API contrary to its explicit interface requirement--every C programmer should know that you never use memcpy() when the buffers may overlap, as it's documented clearly in the C99 standard (http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf page 337), POSIX (http://www.opengroup.org/onlinepubs/000095399/functions/m...) and SUSv2 (http://opengroup.org/onlinepubs/007908799/xsh/memcpy.html). The kernel's /proc/kallsyms interface, on the other hand, was never documented as anything other than readable by everyone by default.
Also, Linus' comment to the contrary notwithstanding, it's not like there have never been user-visible API changes in the Linux kernel; for example, the ipchains interface no longer exists, and more recently a non-zero default was set for the /proc/sys/vm/mmap_min_addr parameter, which did in fact break some existing user-level software.
(Log in to post comments)
On breaking things Posted Nov 25, 2010 7:33 UTC (Thu) by error27 (subscriber, #8346) [Link] "The glibc change only broke programs which used the API contrary to its explicit interface requirement--every C programmer should know that you never use memcpy()"The memcpy() change exposed a similar bug in glibc. So the Flash people maybe aren't idiots after when compared to the glibc people.
Why use such misleading names for functions? Posted Nov 25, 2010 9:40 UTC (Thu) by rvfh (subscriber, #31018) [Link]
I think having memcpy() and memmove() is a mistake.
* memcpy() should do the right thing, which is copy memory, safely. * memmove() should not even exist, especially not which such a misleading name.
If we want an optimised memcpy(), I think we should rather create a new memcpy_nooverlap() (feel free to find a better name) function which clearly states its nature.
Last but not least, if memcpy() had always _really_ been unsafe, we would not have the problem today,as Adobe would have spotted and corrected the bug during development.
Why use such misleading names for functions? Posted Nov 25, 2010 10:18 UTC (Thu) by mpr22 (subscriber, #60784) [Link] Any naive implementation of ISO C memcpy() is almost certain to have been unsafe in one direction. Either it starts at the end and works backward, making it work reliably for "dest > src, src + len > dest", or it starts at the beginning and works forward, making it work reliably for "dest < src, dest + len > src". (Of course, some bunch of demented jerks implementing a Deathmaster 9000 probably made it start at the middle and oscillate outwards.) As for your proposed grand rename: You're quite right. Feel free to try and persuade the ISO C standard committee of your correctness.
Why use such misleading names for functions? Posted Nov 25, 2010 10:52 UTC (Thu) by xav (guest, #18536) [Link]
> Last but not least, if memcpy() had always _really_ been unsafe, we would not have the problem today,as Adobe would have spotted and corrected the bug during development.
Just one Valgrind run found the problem. So the big lesson here is that Adobe doesn't even run Valgrind or equivalent (e.g. Purify) on their code. They wouldn't have corrected the bug during development, even if memcpy() had done a printf() to warn them.
No wonder their software is full of security holes.
Why use such misleading names for functions? Posted Nov 25, 2010 18:42 UTC (Thu) by RobSeace (subscriber, #4435) [Link]
> memcpy_nooverlap() (feel free to find a better name)
We've already got one: memmove()...
(And, no, it's NOT really a "misleading" name... As I said in the old thread,
Why use such misleading names for functions? Posted Nov 25, 2010 18:45 UTC (Thu) by RobSeace (subscriber, #4435) [Link]
D'oh! Of course, I misread, and of course memmove() is the name for memcpy_overlap(),
and your hypothetical memcpy_nooverlap() is just memcpy()... But, it has literally ALWAYS been this way, and any C programmer worth half a damn knows this is how memcpy() and memmove() works... It's widely documented in various standards, and misusing memcpy() in place of memmove() will cause you lots of trouble on various other libcs... Just because glibc has been forgiving of the blatent misuse prior to now is no reason to continue to tolerate it...
Why use such misleading names for functions? Posted Nov 25, 2010 21:36 UTC (Thu) by rvfh (subscriber, #31018) [Link]
> And, no, it's NOT really a "misleading" name...
> (...) > the data truly was MOVED from source to destination (...)
You're correct, now that you say that, I understand why the name!
|
|||||||||||||