Yes, that's what the pharma companies want. The terms are a bit more far reaching (i.e. you must also respect US patents, including software patents). If the drugs are patented, then no producing them locally. If they actually wanted to make a difference, then they'd fund building factories in countries that don't respect these patents and mass produce them for local consumption. They'd help bootstrap the local industry and they'd end up delivering the drugs much more cheaply.
Please go and read what the vulnerability does. It allows unprivileged code that is able to invoke a setuid binary, to append data to a root-readable file. If you have a browser exploit that allows arbitrary code execution in the context of the browser, then you have this ability unless the browser is running in a sandbox. Safari and Chrome run most of the code in such a sandbox, Firefox does not. A vulnerability in Firefox can be combined with this vulnerability to do anything that root can do.
Modifying the sudoers file was only one example use for this. It allows you to write to any file that is normally only writeable to root. Modifying sudoers is a fairly simple and visible change, but modifying one of the system startup scripts that launchd runs as root would work just as well. I think it only lets you append to a file, but it would also be possible to temporarily modify sudoers, then set your worm's setuid bit and change the owner to root, then revert the sudoers change. The only user-visible thing would be the setuid bit on a suspicious binary hidden somewhere in the system (how many people check for this?). Of course, once you are root then you can do things like modify firmware and boot settings and hide inside the kernel...
NO, Code execution in a browser CANNOT escalate privileges.... none of those applications have sufficient rights to change the/etc/sudoer file
Way to miss the point. If they had the rights to write to/etc/sudoers then they wouldn't need a privilege escalation vulnerability. The entire point of this exploit is that it allows someone with an unprivileged account to gain root access. That said, both Chrome and Safari run the WebKit renderers in sandboxes that don't have the ability to run any setuid binaries (which this needs), so the grandparent is only partially correct: only Firefox would be vulnerable, out of the ones that he listed.
DC is harder to turn off safely. A high current contactor will arc under both AC and DC - but an AC arc tends to be self extinguishing
There's also the issue of touching the live wire. If you touch a DC main, your hand will spasm and you're likely to end up gripping it. If you touch AC, then you feel a buzzing at the frequency, but it's a lot easier to pull away.
Huh? The clock line is not a power line. You're not using 2GHz AC to drive your CPU, you're using DC to power the transistors and a 2GHz clock signal (which you could probably describe as AC, though it stretches the term a bit) for switching.
He doesn't do laundry - but the charity he donates clothes is forced to do it. He's basically pushed the environmental impact, energy and cost of laundry onto some other 3rd party
That's fairly minor in comparison with the energy cost of having a new set of clothes shipped all of the way from China every time whatever he's wearing gets dirty. Does he really think that producing new clothes and shipping them half way around the world has a lower energy cost than running a washer-dryer for a couple of hours?
Even in a modern mechanised war, where you have a relatively small percentage of the population fighting, success depends on a strong economy. Russia's ability to turn on massive production of tanks in the second world war was the most obvious example of this, but even before that in the Napoleonic wars the British ability to mass-produce rifles was a key factor. Without a healthy population, you can't easily maintain the civilian infrastructure that you need to drive the war machine. The drones won't fly without working power, the operators won't make it to work without working transportation infrastructure and food distribution.
This is also true of the Bill and Melinda Gates Foundation. They donate a huge amount of 'free' medicine around the world to poor countries. There's only one very small catch: if you accept the donation (which it's basically impossible to refuse when it is likely to save millions of lives in your country) you have to sign a one-sided IP protection treaty with the USA. Not pushed by the B&MGF, you understand, it's a requirement of the pharmaceutical companies providing the drugs. The fact that it happens to significantly benefit the investments of the major donors of the foundation is purely coincidental, as is the long-term harm that it does to developing economies.
Sort of. There wasn't for old apps, but Qt could target both. Except not with quite the same code. For most developers 'you can rewrite your app, and then use almost the same code on the old platform where it runs already' is not a great migration path.
They do write apps, but you can't sustain an ecosystem with only first-party apps. If anything, it becomes self-defeating, because no one wants to be the small developer in an ecosystem where a big developer that controls the distribution channel can easily reproduce their idea.
Windows Phone is pretty nice. It's main drawback is the lack of apps (which is hard to fix, as no one wants to develop for a platform with few users and no one wants to buy a phone with no software). It's main problem selling is that people associate it with Windows on the desktop, which is a usability disaster that somehow manages to get worse each version, in spite of having passed the point where people thought it couldn't get any worse some time ago.
Don't forget:
7. DOS (vs CP/M)
8. Doublespace (vs Stacker)
9. Windows (vs GEM)
10. XBox (vs Nintendo / Sega / Sony)
It's actually hard to think of a successful Microsoft product that hasn't followed this pattern.
Around 2005, Nokia had a shiny new kernel (Symbian EKA2), designed from scratch to scale to future mobile systems with a good security model, clean abstractions, and power management built in at all layers. It was still hampered, however, by userspace APIs that were designed for a far more memory-constrained environment. Their solution to this involved multiple phases. Their first part was to try to replace the kernel with Linux. This did not go well. They then had no idea how to design a new set of userland APIs, so they set up multiple teams internally competing. These teams were very good at sabotaging each other, but not so good at bringing a usable product to market.
Elop came in when Nokia had failed to produce anything to compete with the iPhone or even with a moderately decent Android handset. He managed to persuade Microsoft to buy Nokia for what now turns out to be a significant multiple of their real value. Of all the companies that benefitted from this, Microsoft was pretty low down the list.
Furthermore Google is basically giving Android away
Half true. If you want to ship Android, it's free: go to AOSP, download, tweak to your device, ship. If, on the other hand, you want the Google Play store, then you have to pay Google, agree to ship other Google apps in the default firmware install, and agree not to ship competing apps in a few categories in the default install.
Microsoft lacks the design culture and brand to compete with Apple on the high end
A lot of that is marketing. It's far more a brand problem than a design culture. In terms of usability, I'd place Windows Phone a little bit ahead of iOS at the moment (which surprised me a lot, because Windows is a UI clusterfuck on the desktop, OS X is worse than it was but still in a completely different league to Windows 8.1 - I've not tried Windows 10 yet). Possibly MS moved all of their competent HCI people to the mobile team, or possibly management doesn't care as much about mobile so doesn't insist on multiple layers of design by committee. No one who's used Windows on the desktop would go out of their way to buy a Microsoft product though.
Symbian EKA2 was a great kernel design for mobile (and still does security and power management better than Linux), but a lot of the Symbian userspace APIs were designed at a time where 1MB of RAM was a lot, 4MB was huge. When 64MB was entry level, they were really showing their age: saving 1MB at the cost of a big increase in developer effort wasn't worth it. Nokia needed to provide a modern API and a clean migration path. They provided neither and they set up groups within the company competing to provide both and actively sabotaging each other. Maemo/Meego is an example of this: Switching from GTK to Qt shortly after launching the product doesn't instil developer confidence.
Windows Phone actually made sense for Nokia: they needed a software stack that let them differentiate themselves (and no one else seemed to be using WP) and they had managed to set up their corporate structure in such a way that it was impossible for them to develop it themselves. Some of their apps were really nice (their maps app, which was just bought by a consortium of German car makers was a lot better than the Apple or Google offerings, for example).
longjmp from a signal handler to normal code is undefined behaviour anyway - there are lots of things that can break it (signal stacks are one). God created ucontext (unfortunately, while drunk) for a reason.
For some insight into this, check out the classic book "Graphics Programming Black Book" which is available online in many places for free (such as ) Chapter 17 (on the well known "game of life") is good on this, but the entire book is a good read.
Please don't. The advice in that book (or, that chapter, at least) is great, if you're targeting a 486 with VGA graphics and a compiler from around 1995. Some of the advice is still good, but it's interleaved with advice that will result in much slower code (though the advice to always profile first may save you there!) and so it would be very hard to read that book without already understanding optimisation and come away more informed.
The worst bug I had to fix recently was in some hand-written assembly where the immediate in a store and a load overflowed and the assembler silently truncated it. I read the code multiple times and it was only when I traced the execution and looked at the disassembly that it became clear that the assembly and disassembly didn't show the same thing. This caused crashes, but it was in context switch code, so it only happened in processes that happened to use those particular registers and often quite a long way after returning to the process.
That's not debugging a compiler bug, that's step one in producing a reduced test case, which is step one in debugging a compiler bug. It's also starting from the easiest kind of compiler bug to fix (ones where it causes a crash at all, and within that category, ones where the crash and the miscompilation are in the same place).
The order of parameter evaluation is one that bites a lot of people because most compilers do it the expected way. When you're walking an AST to emit some intermediate representation, you're going to traverse the parameter nodes either left-to-right or right-to-left and most compiler IRs don't make it easy to express the idea that these can happen in any order depending on what later optimisations want. If they have side effects that generate dependencies between them (as these do) then they're likely to remain in the order of the AST walker. Most compilers will walk left-to-right (because a surprising amount of code breaks if they don't), but a few will do it the other way.
To understand why this is in the spec, you have to understand the calling conventions. Pascal used a stack-based IR (p-code) and had a left-to-right order for parameter evaluation, which meant that the first parameter was evaluated and then pushed onto the stack, so the last parameter would be at the top of the stack. The natural thing when compiling Pascal (as opposed to interpreting the p-code) was to use the same calling convention, with parameters pushed onto the call stack left to right. Unfortunately, C can't do this and support variadic functions (not: some implementations wanted to do this, which is why the C spec says that variadic and non-variadic functions are allowed to use completely different calling conventions), because if the last variadic argument is the top of the stack then there's no way to find the non-variadic arguments unless you also do something like push the number / size of variadic arguments onto the stack.
This meant that C implementations tended to push parameters onto the stack right to left. This is less of an issue now that modern architectures have enough registers for most function arguments, but is still an issue on i386. Because of the order of the calling convention, it's more efficient on some architectures to evaluate arguments right to left. Some compilers that are heavily performance-focussed (GPU and DSP ones in particular, where they don't have a large body of legacy code that they need to support) will do this, because it reduces register pressure (evaluate the rightmost argument using some temporaries, push it to the stack, move onto the next, reusing all of those temporary registers).
It's called copy elision and it is part of the C++ spec. The spec specifically says that compilers may (but are not required to) implement it, meaning that the compiler is completely free to do different things within the abstract machine at different optimisation levels. It's definitely a bug, but unfortunately it's a bug in the C++ standard. Any sane spec would either require the compiler to implement it or prohibit it - either would be fine (with C++11, prohibiting it would make sense as returning an r-value reference and doing move construction ought to give the same benefit).
Most compiler bugs are not that difficult to debug
Another compiler guy here: Some compiler bugs are not that difficult to debug if you have a reduced test case that triggers the issue. Most are caused by subtle interactions of assumptions in different optimisations and so go away with very small changes to the code and are horrible to debug (and involve starring at the before and after parts for each step in the pipeline to find out exactly where the incorrect code was introduced, which is often not where the bug is, so then backtracking to find what produced the code that contained the invalid assumption that was then exploited later).
My day job involves a research OS, a research compiler, and research hardware. When something breaks and we can narrow it down to just two possibilities out of an OS bug, a compiler bug or a hardware bug, it's a good day...
Slashdot Mirror
Yes, that's what the pharma companies want. The terms are a bit more far reaching (i.e. you must also respect US patents, including software patents). If the drugs are patented, then no producing them locally. If they actually wanted to make a difference, then they'd fund building factories in countries that don't respect these patents and mass produce them for local consumption. They'd help bootstrap the local industry and they'd end up delivering the drugs much more cheaply.
Please go and read what the vulnerability does. It allows unprivileged code that is able to invoke a setuid binary, to append data to a root-readable file. If you have a browser exploit that allows arbitrary code execution in the context of the browser, then you have this ability unless the browser is running in a sandbox. Safari and Chrome run most of the code in such a sandbox, Firefox does not. A vulnerability in Firefox can be combined with this vulnerability to do anything that root can do.
Sorry - I'm not disagreeing with you, just pointing out that it still applies even in conflicts where it isn't the first-order effect.
Modifying the sudoers file was only one example use for this. It allows you to write to any file that is normally only writeable to root. Modifying sudoers is a fairly simple and visible change, but modifying one of the system startup scripts that launchd runs as root would work just as well. I think it only lets you append to a file, but it would also be possible to temporarily modify sudoers, then set your worm's setuid bit and change the owner to root, then revert the sudoers change. The only user-visible thing would be the setuid bit on a suspicious binary hidden somewhere in the system (how many people check for this?). Of course, once you are root then you can do things like modify firmware and boot settings and hide inside the kernel...
NO, Code execution in a browser CANNOT escalate privileges.... none of those applications have sufficient rights to change the /etc/sudoer file
Way to miss the point. If they had the rights to write to /etc/sudoers then they wouldn't need a privilege escalation vulnerability. The entire point of this exploit is that it allows someone with an unprivileged account to gain root access. That said, both Chrome and Safari run the WebKit renderers in sandboxes that don't have the ability to run any setuid binaries (which this needs), so the grandparent is only partially correct: only Firefox would be vulnerable, out of the ones that he listed.
DC is harder to turn off safely. A high current contactor will arc under both AC and DC - but an AC arc tends to be self extinguishing
There's also the issue of touching the live wire. If you touch a DC main, your hand will spasm and you're likely to end up gripping it. If you touch AC, then you feel a buzzing at the frequency, but it's a lot easier to pull away.
Huh? The clock line is not a power line. You're not using 2GHz AC to drive your CPU, you're using DC to power the transistors and a 2GHz clock signal (which you could probably describe as AC, though it stretches the term a bit) for switching.
He doesn't do laundry - but the charity he donates clothes is forced to do it. He's basically pushed the environmental impact, energy and cost of laundry onto some other 3rd party
That's fairly minor in comparison with the energy cost of having a new set of clothes shipped all of the way from China every time whatever he's wearing gets dirty. Does he really think that producing new clothes and shipping them half way around the world has a lower energy cost than running a washer-dryer for a couple of hours?
Even in a modern mechanised war, where you have a relatively small percentage of the population fighting, success depends on a strong economy. Russia's ability to turn on massive production of tanks in the second world war was the most obvious example of this, but even before that in the Napoleonic wars the British ability to mass-produce rifles was a key factor. Without a healthy population, you can't easily maintain the civilian infrastructure that you need to drive the war machine. The drones won't fly without working power, the operators won't make it to work without working transportation infrastructure and food distribution.
This is also true of the Bill and Melinda Gates Foundation. They donate a huge amount of 'free' medicine around the world to poor countries. There's only one very small catch: if you accept the donation (which it's basically impossible to refuse when it is likely to save millions of lives in your country) you have to sign a one-sided IP protection treaty with the USA. Not pushed by the B&MGF, you understand, it's a requirement of the pharmaceutical companies providing the drugs. The fact that it happens to significantly benefit the investments of the major donors of the foundation is purely coincidental, as is the long-term harm that it does to developing economies.
Sort of. There wasn't for old apps, but Qt could target both. Except not with quite the same code. For most developers 'you can rewrite your app, and then use almost the same code on the old platform where it runs already' is not a great migration path.
They do write apps, but you can't sustain an ecosystem with only first-party apps. If anything, it becomes self-defeating, because no one wants to be the small developer in an ecosystem where a big developer that controls the distribution channel can easily reproduce their idea.
Windows Phone is pretty nice. It's main drawback is the lack of apps (which is hard to fix, as no one wants to develop for a platform with few users and no one wants to buy a phone with no software). It's main problem selling is that people associate it with Windows on the desktop, which is a usability disaster that somehow manages to get worse each version, in spite of having passed the point where people thought it couldn't get any worse some time ago.
Don't forget:
7. DOS (vs CP/M)
8. Doublespace (vs Stacker)
9. Windows (vs GEM)
10. XBox (vs Nintendo / Sega / Sony)
It's actually hard to think of a successful Microsoft product that hasn't followed this pattern.
Elop came in when Nokia had failed to produce anything to compete with the iPhone or even with a moderately decent Android handset. He managed to persuade Microsoft to buy Nokia for what now turns out to be a significant multiple of their real value. Of all the companies that benefitted from this, Microsoft was pretty low down the list.
Furthermore Google is basically giving Android away
Half true. If you want to ship Android, it's free: go to AOSP, download, tweak to your device, ship. If, on the other hand, you want the Google Play store, then you have to pay Google, agree to ship other Google apps in the default firmware install, and agree not to ship competing apps in a few categories in the default install.
Microsoft lacks the design culture and brand to compete with Apple on the high end
A lot of that is marketing. It's far more a brand problem than a design culture. In terms of usability, I'd place Windows Phone a little bit ahead of iOS at the moment (which surprised me a lot, because Windows is a UI clusterfuck on the desktop, OS X is worse than it was but still in a completely different league to Windows 8.1 - I've not tried Windows 10 yet). Possibly MS moved all of their competent HCI people to the mobile team, or possibly management doesn't care as much about mobile so doesn't insist on multiple layers of design by committee. No one who's used Windows on the desktop would go out of their way to buy a Microsoft product though.
Symbian EKA2 was a great kernel design for mobile (and still does security and power management better than Linux), but a lot of the Symbian userspace APIs were designed at a time where 1MB of RAM was a lot, 4MB was huge. When 64MB was entry level, they were really showing their age: saving 1MB at the cost of a big increase in developer effort wasn't worth it. Nokia needed to provide a modern API and a clean migration path. They provided neither and they set up groups within the company competing to provide both and actively sabotaging each other. Maemo/Meego is an example of this: Switching from GTK to Qt shortly after launching the product doesn't instil developer confidence.
Windows Phone actually made sense for Nokia: they needed a software stack that let them differentiate themselves (and no one else seemed to be using WP) and they had managed to set up their corporate structure in such a way that it was impossible for them to develop it themselves. Some of their apps were really nice (their maps app, which was just bought by a consortium of German car makers was a lot better than the Apple or Google offerings, for example).
longjmp from a signal handler to normal code is undefined behaviour anyway - there are lots of things that can break it (signal stacks are one). God created ucontext (unfortunately, while drunk) for a reason.
For some insight into this, check out the classic book "Graphics Programming Black Book" which is available online in many places for free (such as ) Chapter 17 (on the well known "game of life") is good on this, but the entire book is a good read.
Please don't. The advice in that book (or, that chapter, at least) is great, if you're targeting a 486 with VGA graphics and a compiler from around 1995. Some of the advice is still good, but it's interleaved with advice that will result in much slower code (though the advice to always profile first may save you there!) and so it would be very hard to read that book without already understanding optimisation and come away more informed.
The worst bug I had to fix recently was in some hand-written assembly where the immediate in a store and a load overflowed and the assembler silently truncated it. I read the code multiple times and it was only when I traced the execution and looked at the disassembly that it became clear that the assembly and disassembly didn't show the same thing. This caused crashes, but it was in context switch code, so it only happened in processes that happened to use those particular registers and often quite a long way after returning to the process.
That's not debugging a compiler bug, that's step one in producing a reduced test case, which is step one in debugging a compiler bug. It's also starting from the easiest kind of compiler bug to fix (ones where it causes a crash at all, and within that category, ones where the crash and the miscompilation are in the same place).
The order of parameter evaluation is one that bites a lot of people because most compilers do it the expected way. When you're walking an AST to emit some intermediate representation, you're going to traverse the parameter nodes either left-to-right or right-to-left and most compiler IRs don't make it easy to express the idea that these can happen in any order depending on what later optimisations want. If they have side effects that generate dependencies between them (as these do) then they're likely to remain in the order of the AST walker. Most compilers will walk left-to-right (because a surprising amount of code breaks if they don't), but a few will do it the other way.
To understand why this is in the spec, you have to understand the calling conventions. Pascal used a stack-based IR (p-code) and had a left-to-right order for parameter evaluation, which meant that the first parameter was evaluated and then pushed onto the stack, so the last parameter would be at the top of the stack. The natural thing when compiling Pascal (as opposed to interpreting the p-code) was to use the same calling convention, with parameters pushed onto the call stack left to right. Unfortunately, C can't do this and support variadic functions (not: some implementations wanted to do this, which is why the C spec says that variadic and non-variadic functions are allowed to use completely different calling conventions), because if the last variadic argument is the top of the stack then there's no way to find the non-variadic arguments unless you also do something like push the number / size of variadic arguments onto the stack.
This meant that C implementations tended to push parameters onto the stack right to left. This is less of an issue now that modern architectures have enough registers for most function arguments, but is still an issue on i386. Because of the order of the calling convention, it's more efficient on some architectures to evaluate arguments right to left. Some compilers that are heavily performance-focussed (GPU and DSP ones in particular, where they don't have a large body of legacy code that they need to support) will do this, because it reduces register pressure (evaluate the rightmost argument using some temporaries, push it to the stack, move onto the next, reusing all of those temporary registers).
It's called copy elision and it is part of the C++ spec. The spec specifically says that compilers may (but are not required to) implement it, meaning that the compiler is completely free to do different things within the abstract machine at different optimisation levels. It's definitely a bug, but unfortunately it's a bug in the C++ standard. Any sane spec would either require the compiler to implement it or prohibit it - either would be fine (with C++11, prohibiting it would make sense as returning an r-value reference and doing move construction ought to give the same benefit).
Most compiler bugs are not that difficult to debug
Another compiler guy here: Some compiler bugs are not that difficult to debug if you have a reduced test case that triggers the issue. Most are caused by subtle interactions of assumptions in different optimisations and so go away with very small changes to the code and are horrible to debug (and involve starring at the before and after parts for each step in the pipeline to find out exactly where the incorrect code was introduced, which is often not where the bug is, so then backtracking to find what produced the code that contained the invalid assumption that was then exploited later).
My day job involves a research OS, a research compiler, and research hardware. When something breaks and we can narrow it down to just two possibilities out of an OS bug, a compiler bug or a hardware bug, it's a good day...