... seriously... nature did that. Nature killed off those least able to survive. The end result is a species that is well adapted to live in nature. Guess where we are going now? We are making a species better able to survive a modern society with its technologies like internet, computers, and advanced health care. So fat people live, and thrive.. at least long enough to make a couple babies... which they don't have to care for.
So what is the excuse of Massachusetts for destroying the lives of people and not making them whole after it becomes clear they are completely innocent... including restoring his employment and all backpay? Do they even have an excuse? The recovery cap SHOULD (in the moral sense... I don't know what their laws actually say) not apply to ACTUAL costs, the backpay, and restoring employment in good standing. It should only apply to the added on awards like "pain and suffering". And they should also pay their health costs (and probably will have to eventually, anyway, after things get worse because they won't pay them now).
It still comes down to whether the radar gun was wrong or the GPS was wrong. Since they didn't agree on the speed, at least one of them must be wrong since it is not possible to actually be going two different speeds at the same time in one vehicle. Or it could have been operator error (radar gun actually picked up reflection from another vehicle the cop didn't notice... this kind of error actually happens a lot). It sure sounds fishy that they are saying that they are not challenging the accuracy of the GPS, yet they are challenging the numbers from it. It sure sounds like they are challenging the accuracy of the GPS (and maybe it really is inaccurate).
As for the court games being played... typical lawyer shenanigans. They all do it to try to get the upper hand. It means nothing about the basis of the case.
I see no problem with blocking copyright infringement web sites.
What I do see a problem with is the jump to conclusion that a given web site is bad in some way, whether that be copyright infringement, scammer fraud, or other bad stuff, without the appropriate due diligence and due process, and including fair use consideration. I see a problem in mandating particular kinds of blocking mechanisms that have collateral damage. I see a problem in requiring the ISPs the take on all the costs (which means customers not even accessing those sites are paying for it). And I see a problem with confused lawyers always claiming that even slight similarity of trademarks constitutes widespread public confusion (which is virtually never the case).
So what we really need is a proper due process for determining if a given site truly is bad (enough to block) as defined under the law, including full legal notice, opportunity to dispute and defend, and a genuine appeal route. In most cases, genuine bad people won't even show up and will lose by default judgment. This can be more complex if the bad site is out of the jurisdiction.
We need for anyone making claims of copyright infringement to be putting themselves on the line in the event it is not real infringement. If they lose, they pay the defendant's legal costs. If the court determines it is clearly not infringement, they also have to pay a penalty. OTOH, if it's not all that clear a case and the court determines it is borderline, everyone pays their own legal costs.
The above should also include a provision for "take down consent". That means the party accused can elect to take down the site by consent pending outcome of the case, if the accuser asks for this. But if the defendant wins, the plaintiff pays the loses the defendant incurred by having the site down. OTOH, if the defendant elects to not take the site down, and loses, the defendant has to pay all the loses the plaintiff incurred to have the site up. Determination of loses do have to be genuine and provable.
Once a site is ordered to be taken down, and the site operator, or his ISP, refuses, then it can be ordered to be blocked. This order must include a provision to use the method of least collateral damage. And the plaintiff must pay for 50% of any new equipment required to perform the blocking... but gets that money back pro-rated for proportion of use, when the next plaintiff gets an order for blocking when the same equipment can do the 2nd blocking order, too.
Such technical means must never do things like block DNS to force customers to use the ISP's DNS servers.
I think I understand this now, so I will try to re-phrase and give a different explanation. It is NOT a case of memory being accessed between user processes. Instead, it is a case of memory being access between a user process and the kernel.
The kernel needs to access both its own memory, as well as the memory of the user process. Not all parts of the kernel need to do this, but the parts directly servicing the currently running user process do. For example, the sys_read() function inside the kernel services the read() system call. That function has to be able to store the data it obtained into the user process virtual address space. So it has to have some view of that user process virtual address space.
The view of the user process space COULD have been done by changing the addresses the kernel code sees it as. The catch with that is that it requires a change of segment tables (either reconstructing a new one, or switching to a standby one already constructed) and the corresponding flush of the address translation cache (TLD) which has a performance penalty. So, instead, the kernel changes its view of real physical memory.
Now we have a situation where there can be user-determined data sitting at page 0 as the kernel code sees it. If the kernel hits a place where it has a bug and makes a jump to NULL, which is 0, then the user-determined data is now executing in a kernel context. This problem could happen with the kernel jumping to user code anywhere, but the cases where it jumps to 0 are more deterministic and easier to exploit. If you know of a twisty bug to make the kernel jump to 0 where it would otherwise be a kernel panic at worst (a DoS attack), which has a lower priority to be resolved, you can turn that into a complete capture of the kernel.
If the architecture provided a means to let the kernel access user space in some protected or alternative way, that could be done instead. Kernel code already uses specific macros to access user space where it needs to do that. So if the architecture had a special set of instructions to do it, those could be used. Those special instructions could be a special memory load and memory store that uses a secondary page/segment table with a secondary (or even absent) TLB cache. Or with such instructions, the kernel could potentially run without address translation turned on at all, where these special instructions make use of the address translation that is currently the selected one, even though it is off for all other instructions.
Another PARTIAL solution would be a way to disable execution at page 0. This would not be a complete solution. Instead, the solution currently chosen is to disallow user processes to map memory at page 0 in the mmap() call. The mmap_min_addr setting makes this configurable by root. And an issue raised is that certain distributions have elected to not set this properly. Maybe the kernel should default this to PAGE_SIZE and then let a distribution or system administrator be stupid and set it to 0 if they want to.
So this isn't really a bug in and of itself, but a method by which a known bug can be exploited. I don't see a design fault by Intel in this. Instead, I see it as a fault of the design of the Linux kernel wanting to view both address spaces at the same time AND having the user space be mapped at the same addresses as the user process sees it. Of course we could blame Intel for not including features to make it easier to not do this. Still, this is a complicated requirement because you have to ensure that mmap() cannot allocate user process virtual memory addresses that are the same as any kernel addresses. In a way, you are doing that with mmap_min_addr for one or a few pages. You do point out the issue with respect to corrupt addresses (BTW, I see that more often than NULL address faults).
So is the Intel fault one where they don't allow 2 separated (with separate TLB cache) virtual address spaces and a special instruction to access the alternate for just fetch and store purposes?
Are you sure it is local physical access (where I can tear the machine apart and insert whatever I want, as in the "evil maid" scenario)? Or is it just access to run a (evil) program I provide to the machine (as in a user shell account)? As far as I'm concerned, once you have root access, all bets are off. If you can make your program suid root, you've already exploited the machine. But is the suid reference about root, or about some other user?
And how is page 0 involved in this? And are the references to page 0 talking about virtual page 0 or real page 0? And is this really a cache line conflict at page 0?
So all these companies like Matlab, Mathematica, Fluent, Abaqus would rather have you waste more power per CPU cycle, and help harm the environment, by limiting you to lesser efficient machines, just because they have no idea how to compile their application on another architecture, and have no idea how to make the application portable across even different distributions of Linux? It's the app vendors that need to be in the hall of shame.
I agree about government money. That's too risky. And I'm a supporter of single payer health care, so I'm not some right wing nut.
Legacy newspapers, if they survive long enough, will eventually see what others are doing and copy off of those that are successful. That, or they will just be replaced by people with a clue who don't hire the crony PHBs.
... newspapers and journalists to start "getting it" and understand how this new media can work to keep the world informed. "get it" number 1 is that the profit model is not going to work the way it used to... news will no longer be a monopoly affair that allows the newspaper owners to get rich. If they want to get rich they will have to compete and bring in the eyeballs.
Maybe. The sandbox would have to exist, or ldd spend the time to build one. And it would need to be run as non-root as part of the sandbox. Ideally, the safest way to test things is a non-networked disposable (e.g. delete the image when done and make new images from a master copy when it is needed again) virtual machine.
Spam levels were above 96% in some groups I accessed. And more than 90% of the spam came from Google Groups. I guess they put it on autopilot without any spam checks and walked away. So I just blocked all of Google Groups in my killfile. At least for now, any legitimate posts from there I will see if someone from outside Google Groups posts a followup and includes it. But some of the groups are just dead, now. In a couple cases it's definitely due to the spam.
Actually, no. The bug is NOT in the dynamic loader. In particular, when the exploiting executable specifies a different dynamic loader in the binary interpreter field, then the system dynamic loader is not even involved.
RTFA again. The exploit involves using a different dynamic loader. The evil person has made a fake loader that does the evil deed. That's NOT a bug, since it does what he (the evil person) wanted.
The bug is... at least partly... in the/usr/bin/ldd script. The real source of the bug is in the thinking that every dynamic loader would do this and that no dynamic loader that failed to would ever be used. That's saying that the design of doing it this way is what is buggy.
There are some possible fixes. One fix is to make a program to replace/usr/bin/ldd that understand by itself how to parse and interpret all executables. That might be done best via a new flag on the dynamic linker or dynamic loader programs. This needs to work for all executable formats the system might need to work with. Another fix is to provide for a list of allowed (trusted) dynamic loaders that would be enforced most likely by the kernel. That list could be managed via a/proc entry that can only be written/appended to by root (and uses a built-in list prepared when the kernel was compiled, whenever that/proc entry list is empty).
It's the dynamic loader that knows how to interpret that executable format's list of libraries it depends on. What "ldd" does is just trigger the dynamic loader to output the libraries instead of run the program. The weakness is that an alternate dynamic loader might not do that and will just run the program anyway. Possible fixes include a new "ldd" that parses the executable itself instead of trying to get the dynamic loader to do it, or a means to restrict what dynamic loaders can be used (to just the ones that play well with "ldd").
An associative memory requirement could be better served by a custom high-core count, CPU... if it has sufficient memory on board (e.g. sufficient total memory bus bandwidth).
Slashdot Mirror
What are you trying to do? Make the police and prosecution actually have to PROVE that someone actually LOOKED AT the CP, over and over?
... seriously ... nature did that. Nature killed off those least able to survive. The end result is a species that is well adapted to live in nature. Guess where we are going now? We are making a species better able to survive a modern society with its technologies like internet, computers, and advanced health care. So fat people live, and thrive .. at least long enough to make a couple babies ... which they don't have to care for.
So what is the excuse of Massachusetts for destroying the lives of people and not making them whole after it becomes clear they are completely innocent ... including restoring his employment and all backpay? Do they even have an excuse? The recovery cap SHOULD (in the moral sense ... I don't know what their laws actually say) not apply to ACTUAL costs, the backpay, and restoring employment in good standing. It should only apply to the added on awards like "pain and suffering". And they should also pay their health costs (and probably will have to eventually, anyway, after things get worse because they won't pay them now).
It still comes down to whether the radar gun was wrong or the GPS was wrong. Since they didn't agree on the speed, at least one of them must be wrong since it is not possible to actually be going two different speeds at the same time in one vehicle. Or it could have been operator error (radar gun actually picked up reflection from another vehicle the cop didn't notice ... this kind of error actually happens a lot). It sure sounds fishy that they are saying that they are not challenging the accuracy of the GPS, yet they are challenging the numbers from it. It sure sounds like they are challenging the accuracy of the GPS (and maybe it really is inaccurate).
As for the court games being played ... typical lawyer shenanigans. They all do it to try to get the upper hand. It means nothing about the basis of the case.
So where do the REAL neutrons REALLY come from?
And they can tell this is the decay of a positron and not an electron by what means? Shouldn't they have the same energy wavelength?
I see no problem with blocking copyright infringement web sites.
What I do see a problem with is the jump to conclusion that a given web site is bad in some way, whether that be copyright infringement, scammer fraud, or other bad stuff, without the appropriate due diligence and due process, and including fair use consideration. I see a problem in mandating particular kinds of blocking mechanisms that have collateral damage. I see a problem in requiring the ISPs the take on all the costs (which means customers not even accessing those sites are paying for it). And I see a problem with confused lawyers always claiming that even slight similarity of trademarks constitutes widespread public confusion (which is virtually never the case).
So what we really need is a proper due process for determining if a given site truly is bad (enough to block) as defined under the law, including full legal notice, opportunity to dispute and defend, and a genuine appeal route. In most cases, genuine bad people won't even show up and will lose by default judgment. This can be more complex if the bad site is out of the jurisdiction.
We need for anyone making claims of copyright infringement to be putting themselves on the line in the event it is not real infringement. If they lose, they pay the defendant's legal costs. If the court determines it is clearly not infringement, they also have to pay a penalty. OTOH, if it's not all that clear a case and the court determines it is borderline, everyone pays their own legal costs.
The above should also include a provision for "take down consent". That means the party accused can elect to take down the site by consent pending outcome of the case, if the accuser asks for this. But if the defendant wins, the plaintiff pays the loses the defendant incurred by having the site down. OTOH, if the defendant elects to not take the site down, and loses, the defendant has to pay all the loses the plaintiff incurred to have the site up. Determination of loses do have to be genuine and provable.
Once a site is ordered to be taken down, and the site operator, or his ISP, refuses, then it can be ordered to be blocked. This order must include a provision to use the method of least collateral damage. And the plaintiff must pay for 50% of any new equipment required to perform the blocking ... but gets that money back pro-rated for proportion of use, when the next plaintiff gets an order for blocking when the same equipment can do the 2nd blocking order, too.
Such technical means must never do things like block DNS to force customers to use the ISP's DNS servers.
I think I understand this now, so I will try to re-phrase and give a different explanation. It is NOT a case of memory being accessed between user processes. Instead, it is a case of memory being access between a user process and the kernel.
The kernel needs to access both its own memory, as well as the memory of the user process. Not all parts of the kernel need to do this, but the parts directly servicing the currently running user process do. For example, the sys_read() function inside the kernel services the read() system call. That function has to be able to store the data it obtained into the user process virtual address space. So it has to have some view of that user process virtual address space.
The view of the user process space COULD have been done by changing the addresses the kernel code sees it as. The catch with that is that it requires a change of segment tables (either reconstructing a new one, or switching to a standby one already constructed) and the corresponding flush of the address translation cache (TLD) which has a performance penalty. So, instead, the kernel changes its view of real physical memory.
Now we have a situation where there can be user-determined data sitting at page 0 as the kernel code sees it. If the kernel hits a place where it has a bug and makes a jump to NULL, which is 0, then the user-determined data is now executing in a kernel context. This problem could happen with the kernel jumping to user code anywhere, but the cases where it jumps to 0 are more deterministic and easier to exploit. If you know of a twisty bug to make the kernel jump to 0 where it would otherwise be a kernel panic at worst (a DoS attack), which has a lower priority to be resolved, you can turn that into a complete capture of the kernel.
If the architecture provided a means to let the kernel access user space in some protected or alternative way, that could be done instead. Kernel code already uses specific macros to access user space where it needs to do that. So if the architecture had a special set of instructions to do it, those could be used. Those special instructions could be a special memory load and memory store that uses a secondary page/segment table with a secondary (or even absent) TLB cache. Or with such instructions, the kernel could potentially run without address translation turned on at all, where these special instructions make use of the address translation that is currently the selected one, even though it is off for all other instructions.
Another PARTIAL solution would be a way to disable execution at page 0. This would not be a complete solution. Instead, the solution currently chosen is to disallow user processes to map memory at page 0 in the mmap() call. The mmap_min_addr setting makes this configurable by root. And an issue raised is that certain distributions have elected to not set this properly. Maybe the kernel should default this to PAGE_SIZE and then let a distribution or system administrator be stupid and set it to 0 if they want to.
So this isn't really a bug in and of itself, but a method by which a known bug can be exploited. I don't see a design fault by Intel in this. Instead, I see it as a fault of the design of the Linux kernel wanting to view both address spaces at the same time AND having the user space be mapped at the same addresses as the user process sees it. Of course we could blame Intel for not including features to make it easier to not do this. Still, this is a complicated requirement because you have to ensure that mmap() cannot allocate user process virtual memory addresses that are the same as any kernel addresses. In a way, you are doing that with mmap_min_addr for one or a few pages. You do point out the issue with respect to corrupt addresses (BTW, I see that more often than NULL address faults).
So is the Intel fault one where they don't allow 2 separated (with separate TLB cache) virtual address spaces and a special instruction to access the alternate for just fetch and store purposes?
Are you sure it is local physical access (where I can tear the machine apart and insert whatever I want, as in the "evil maid" scenario)? Or is it just access to run a (evil) program I provide to the machine (as in a user shell account)? As far as I'm concerned, once you have root access, all bets are off. If you can make your program suid root, you've already exploited the machine. But is the suid reference about root, or about some other user?
And how is page 0 involved in this? And are the references to page 0 talking about virtual page 0 or real page 0? And is this really a cache line conflict at page 0?
Just what design choice was made (wrong) by Intel, and why is it a bad choice?
So all these companies like Matlab, Mathematica, Fluent, Abaqus would rather have you waste more power per CPU cycle, and help harm the environment, by limiting you to lesser efficient machines, just because they have no idea how to compile their application on another architecture, and have no idea how to make the application portable across even different distributions of Linux? It's the app vendors that need to be in the hall of shame.
I agree about government money. That's too risky. And I'm a supporter of single payer health care, so I'm not some right wing nut.
Legacy newspapers, if they survive long enough, will eventually see what others are doing and copy off of those that are successful. That, or they will just be replaced by people with a clue who don't hire the crony PHBs.
... newspapers and journalists to start "getting it" and understand how this new media can work to keep the world informed. "get it" number 1 is that the profit model is not going to work the way it used to ... news will no longer be a monopoly affair that allows the newspaper owners to get rich. If they want to get rich they will have to compete and bring in the eyeballs.
Maybe. The sandbox would have to exist, or ldd spend the time to build one. And it would need to be run as non-root as part of the sandbox. Ideally, the safest way to test things is a non-networked disposable (e.g. delete the image when done and make new images from a master copy when it is needed again) virtual machine.
Maybe they're using the DSL those turtles like slow much.
What about my storage unit? Or my box at the post office? Or my box at the bank?
Spam levels were above 96% in some groups I accessed. And more than 90% of the spam came from Google Groups. I guess they put it on autopilot without any spam checks and walked away. So I just blocked all of Google Groups in my killfile. At least for now, any legitimate posts from there I will see if someone from outside Google Groups posts a followup and includes it. But some of the groups are just dead, now. In a couple cases it's definitely due to the spam.
and have up to four teraflops ... http://www.nvidia.com/object/tesla_supercomputer_wtb.html
... to speed up web access on an HTTPS-only web site?
... the Windows way, since 1981.
Actually, no. The bug is NOT in the dynamic loader. In particular, when the exploiting executable specifies a different dynamic loader in the binary interpreter field, then the system dynamic loader is not even involved.
RTFA again. The exploit involves using a different dynamic loader. The evil person has made a fake loader that does the evil deed. That's NOT a bug, since it does what he (the evil person) wanted.
The bug is ... at least partly ... in the /usr/bin/ldd script. The real source of the bug is in the thinking that every dynamic loader would do this and that no dynamic loader that failed to would ever be used. That's saying that the design of doing it this way is what is buggy.
There are some possible fixes. One fix is to make a program to replace /usr/bin/ldd that understand by itself how to parse and interpret all executables. That might be done best via a new flag on the dynamic linker or dynamic loader programs. This needs to work for all executable formats the system might need to work with. Another fix is to provide for a list of allowed (trusted) dynamic loaders that would be enforced most likely by the kernel. That list could be managed via a /proc entry that can only be written/appended to by root (and uses a built-in list prepared when the kernel was compiled, whenever that /proc entry list is empty).
It's the dynamic loader that knows how to interpret that executable format's list of libraries it depends on. What "ldd" does is just trigger the dynamic loader to output the libraries instead of run the program. The weakness is that an alternate dynamic loader might not do that and will just run the program anyway. Possible fixes include a new "ldd" that parses the executable itself instead of trying to get the dynamic loader to do it, or a means to restrict what dynamic loaders can be used (to just the ones that play well with "ldd").
An associative memory requirement could be better served by a custom high-core count, CPU ... if it has sufficient memory on board (e.g. sufficient total memory bus bandwidth).