[opensuse] Time to look for a kernel update...
http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
* Affects all "modern" 64-bit Intel processors, though some newer "modern" chips might have some instruction to further limit potential impact * Fix in kernel software (Apple, Linux; Windows) instead of HW results in a 5-30% or 17-23% slowdown on EVERY system call * Not exploitable in itself, but could allow easier exploits against other kernel features like the library address space randomization. * need to be have a hostile program running on system to be abusable, including processes running in VM's, including many or most Cloud implementations (ex. Amazon EC2 and Google Compute Engine) ** side note: It doesn't appear developers are considering a "don't care" fix applicable where someone doesn't want a ~20% speed slowdown on syscalls and isn't running hostile code, even in a VM. This would apply to most non-cloud, end-user systems. * For good measure, similar software protections will be included on 64-bit ARM kernels as well; While AMD chips aren't affected by this bug, it's hard to see an update physically-splitting (instead of just virtually-splitting) all kernel & user code, only being applied against Intel and ARM (i.e. AMD chip-based systems may likely be affected by the slowdown due to the fix being applied across 64-bit kernels. -------- Of course, Intel hasn't stepped up to say they'll replace the faulty chips, which seem to be related mostly to Intel-specific chip speedups not in other chips (like Intel's "speculative execution" feature that pre-executes multiple branches of a conditional ahead of knowing which branch will be taken). Intel has a history of offering replacing HW or compensation for their chips being hit by a 20% perf-penalty in the field. Lovely... -l -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-01-03 17:48, Linda Walsh wrote:
* For good measure, similar software protections will be included on 64-bit ARM kernels as well; While AMD chips aren't affected by this bug, it's hard to see an update physically-splitting (instead of just virtually-splitting) all kernel & user code, only being applied against Intel and ARM (i.e. AMD chip-based systems may likely be affected by the slowdown due to the fix being applied across 64-bit kernels.
AMD has asked the measure not be applied to their processors. Any method to know if /my/ processor is affected? It was bought several years ago. A list of exact processor models for looking in /proc/cpuinfo, perhaps.
--------
Of course, Intel hasn't stepped up to say they'll replace the faulty chips, which seem to be related mostly to Intel-specific chip speedups not in other chips (like Intel's "speculative execution" feature that pre-executes multiple branches of a conditional ahead of knowing which branch will be taken). Intel has a history of offering replacing HW or compensation for their chips being hit by a 20% perf-penalty in the field.
Lovely...
Indeed. :-/ I guess they don't have the kind of money needed. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos, et al -- ...and then Carlos E. R. said... % ... % Any method to know if /my/ processor is affected? It was bought several % years ago. A list of exact processor models for looking in % /proc/cpuinfo, perhaps. [snip] That certainly would be a nice twist. Suddenly all of those old chips out there run faster than the fancy new whiz-bangs just because they don't need the super-secure kernel shuffling :-) Happy New Year :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2018-01-03 at 14:05 -0500, David T-G wrote:
Carlos, et al --
...and then Carlos E. R. said... % ... % Any method to know if /my/ processor is affected? It was bought several % years ago. A list of exact processor models for looking in % /proc/cpuinfo, perhaps. [snip]
That certainly would be a nice twist. Suddenly all of those old chips out there run faster than the fancy new whiz-bangs just because they don't need the super-secure kernel shuffling :-)
Now I wonder if single core CPUs are affected. This issue is related to paralelization optimizations. Thus I wonder whether a machine that doesn't paralelize is affected. I also wonder if a virtual machine that is given a single core of a multi-core CPU is affected. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpSaNAACgkQtTMYHG2NR9XzYACeKG2vkz7B+TLLRJZ7LDrkimCX B8QAn3yE7SrSsLtdauspPL7lQOouBqoA =ehPS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/01/18 18:37, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2018-01-03 at 14:05 -0500, David T-G wrote:
Carlos, et al --
...and then Carlos E. R. said... % ... % Any method to know if /my/ processor is affected? It was bought several % years ago. A list of exact processor models for looking in % /proc/cpuinfo, perhaps. [snip]
That certainly would be a nice twist. Suddenly all of those old chips out there run faster than the fancy new whiz-bangs just because they don't need the super-secure kernel shuffling :-)
Now I wonder if single core CPUs are affected.
This issue is related to paralelization optimizations. Thus I wonder whether a machine that doesn't paralelize is affected.
It's the pipeline that's affected. That's part of a single-core cpu, so yes it probably is affected.
I also wonder if a virtual machine that is given a single core of a multi-core CPU is affected.
I wonder what virtualisation does full stop. Obviously, if there are multiple virtual systems it can't control what other systems are running when, but if it gives away things like passwords etc then there's a problem. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On Wednesday, 2018-01-03 at 14:05 -0500, David T-G wrote:
Carlos, et al --
...and then Carlos E. R. said... % ... % Any method to know if /my/ processor is affected? It was bought several % years ago. A list of exact processor models for looking in % /proc/cpuinfo, perhaps. [snip]
That certainly would be a nice twist. Suddenly all of those old chips out there run faster than the fancy new whiz-bangs just because they don't need the super-secure kernel shuffling :-)
Now I wonder if single core CPUs are affected.
This issue is related to paralelization optimizations. Thus I wonder whether a machine that doesn't paralelize is affected.
Jump prediction in the pipeline is not related to the number of cores.
I also wonder if a virtual machine that is given a single core of a multi-core CPU is affected.
Yes it is. -- Per Jessen, Zürich (3.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-01-07 20:22, Per Jessen wrote:
Carlos E. R. wrote:
Now I wonder if single core CPUs are affected.
This issue is related to paralelization optimizations. Thus I wonder whether a machine that doesn't paralelize is affected.
Jump prediction in the pipeline is not related to the number of cores.
Well, it can preload in advance the pipeline. But it can not compute the alternatives; it has to wait till it evaluates the condition, then compute a single one, the correct one, that is hopefully already loaded in the pipeline. With a cpu that can do parallelization in hardware, both tracks can start to compute before reaching the branch; then one is discarded. That's from reading <https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/>
I also wonder if a virtual machine that is given a single core of a multi-core CPU is affected.
Yes it is.
:-( -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Sun, Jan 7, 2018 at 2:40 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2018-01-07 20:22, Per Jessen wrote:
Carlos E. R. wrote:
Now I wonder if single core CPUs are affected.
This issue is related to paralelization optimizations. Thus I wonder whether a machine that doesn't paralelize is affected.
Jump prediction in the pipeline is not related to the number of cores.
Well, it can preload in advance the pipeline. But it can not compute the alternatives; it has to wait till it evaluates the condition, then compute a single one, the correct one, that is hopefully already loaded in the pipeline.
With a cpu that can do parallelization in hardware, both tracks can start to compute before reaching the branch; then one is discarded.
That's from reading <https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/>
Carlos, You fundamentally misunderstand the raspberrypi article. The parallelism it describes is within a single superscalar core. Thus, a modern Intel "core" has internal parallelism as described in the article. Multiple cores are used to run multiple totally unrelated instruction streams (ie. 2 different programs), and each core has parallelism as described n the article. In fact a modern Intel core has so much internal parallelism, much of the parallelism is wasted. That's where hyperthreading comes in. With hyperthreading two instruction streams are executed simultaneously, but there are parts of the parallelism that are shared between the 2 instruction streams. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-01-08 01:31, Greg Freemyer wrote:
On Sun, Jan 7, 2018 at 2:40 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2018-01-07 20:22, Per Jessen wrote:
Carlos E. R. wrote:
Now I wonder if single core CPUs are affected.
This issue is related to paralelization optimizations. Thus I wonder whether a machine that doesn't paralelize is affected.
Jump prediction in the pipeline is not related to the number of cores.
Well, it can preload in advance the pipeline. But it can not compute the alternatives; it has to wait till it evaluates the condition, then compute a single one, the correct one, that is hopefully already loaded in the pipeline.
With a cpu that can do parallelization in hardware, both tracks can start to compute before reaching the branch; then one is discarded.
That's from reading <https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/>
Carlos,
You fundamentally misunderstand the raspberrypi article.
The parallelism it describes is within a single superscalar core. Thus, a modern Intel "core" has internal parallelism as described in the article.
AH! Yes, of course. Obviously. I see. :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Sun, Jan 7, 2018 at 2:22 PM, Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
On Wednesday, 2018-01-03 at 14:05 -0500, David T-G wrote:
Carlos, et al --
...and then Carlos E. R. said... % ... % Any method to know if /my/ processor is affected? It was bought several % years ago. A list of exact processor models for looking in % /proc/cpuinfo, perhaps. [snip]
That certainly would be a nice twist. Suddenly all of those old chips out there run faster than the fancy new whiz-bangs just because they don't need the super-secure kernel shuffling :-)
Now I wonder if single core CPUs are affected.
This issue is related to paralelization optimizations. Thus I wonder whether a machine that doesn't paralelize is affected.
Jump prediction in the pipeline is not related to the number of cores.
I also wonder if a virtual machine that is given a single core of a multi-core CPU is affected.
Yes it is.
The cloud VM providers like AWS were very involved in writing the patchset. Based on their major involvement, they may be even more vulnerable than the bare metal servers. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Quoting Greg Freemyer <greg.freemyer@gmail.com>:
On Sun, Jan 7, 2018 at 2:22 PM, Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
On Wednesday, 2018-01-03 at 14:05 -0500, David T-G wrote:
Carlos, et al --
...and then Carlos E. R. said... % ... % Any method to know if /my/ processor is affected? It was bought several % years ago. A list of exact processor models for looking in % /proc/cpuinfo, perhaps. [snip]
That certainly would be a nice twist. Suddenly all of those old chips out there run faster than the fancy new whiz-bangs just because they don't need the super-secure kernel shuffling :-)
Now I wonder if single core CPUs are affected.
This issue is related to paralelization optimizations. Thus I wonder whether a machine that doesn't paralelize is affected.
Jump prediction in the pipeline is not related to the number of cores.
I also wonder if a virtual machine that is given a single core of a multi-core CPU is affected.
Yes it is.
The cloud VM providers like AWS were very involved in writing the patchset. Based on their major involvement, they may be even more vulnerable than the bare metal servers.
Greg
I expect that virtual machines switch context even more often than the typical personal computer. Depending on how much of the VM runs in the kernel space, file I/O may take twice as many context switches. Many VM are running file and database heavy tasks. One benchmark of the patch performance hit used a relational database join, a common task, especially for applications like Rails that use a relational database for object-oriented data structures. And this applications are running much nearer capacity so performance hits reduce capacity and increase latency. On most personal computers, the performance reduces idle time and responsiveness (i.e., low latency). Just my .02USD, Jeffrey -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2018-01-03 at 19:45 +0100, Carlos E. R. wrote:
On 2018-01-03 17:48, Linda Walsh wrote:
* For good measure, similar software protections will be included on 64-bit ARM kernels as well; While AMD chips aren't affected by this bug, it's hard to see an update physically-splitting (instead of just virtually-splitting) all kernel & user code, only being applied against Intel and ARM (i.e. AMD chip-based systems may likely be affected by the slowdown due to the fix being applied across 64-bit kernels.
AMD has asked the measure not be applied to their processors.
- From AMD's perspective, it would definitely be exasperating to have your hardware penalized when you didn't screw stuff up... Surely there's got to be some way to selectively enable the "protections" based off of CPU model, like there is with other features? -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAlpNL4MACgkQQ1nEo4DF CIULPgf/Z6rFzxojdZpTwElm3hYtPfCfVblSqgfdfUqqbdmqqYH2mYP3YJow4Mwe xRZlVyAWfnJUfqdpsbVlDGD1xDtcEHz+pd71gk2KkPZZxoTvPDrL4Zj4XaYAbMJl AcJTGlpD95foM8IOVtSOXp7+jO97OkW/PLmFwAfdIJJSVJWvfBRnaR6Dn4FvtufA 7omT0yOBT03cKa/wiP9tyyNmk+hgZB0b0zzsEX3FM6VrIAMQ7utrCLR5VCX9kGQb +ud2l7os58MUQV2H7ENGpL6POkBkdVaSeYB6aURR3kkfo7ZBB7cG1ODFaDSCjWAR IYYoqmQxqRgpeXfpl42bBTR+JrBKxA== =bVwN -----END PGP SIGNATURE-----
On 03/01/18 19:31, Christopher Myers wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > On Wed, 2018-01-03 at 19:45 +0100, Carlos E. R. wrote: >> > On 2018-01-03 17:48, Linda Walsh wrote: >> > >>> > > >>> > > * For good measure, similar software protections will be included >>> > > on 64-bit ARM kernels as well; While AMD chips aren't affected >>> > > by this bug, it's hard to see an update physically-splitting >>> > > (instead of just virtually-splitting) all kernel & user code, >>> > > only being applied against Intel and ARM (i.e. AMD chip-based >>> > > systems >>> > > may likely be affected by the slowdown due to the fix being >>> > > applied >>> > > across 64-bit kernels. >> > >> > AMD has asked the measure not be applied to their processors. >> > > - From AMD's perspective, it would definitely be exasperating to have > your hardware penalized when you didn't screw stuff up... Surely > there's got to be some way to selectively enable the "protections" > based off of CPU model, like there is with other features? You mean, like, compile your own kernels? Actually, from what I've picked up there is a command-line kernel boot option that will disable it even if compiled in. But surely (I've never done it on S(uU)SE), you must be able to download the kernel source package, disable it, and recompile? Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/03/2018 11:31 AM, Christopher Myers wrote:
From AMD's perspective, it would definitely be exasperating to have your hardware penalized when you didn't screw stuff up... Surely there's got to be some way to selectively enable the "protections" based off of CPU model, like there is with other features?
It was in a patch that exempted AMD processors submitted by an AMD employee that the hint as to the root cause was found. So the patch, already accepted, will do as you suggest. -- After all is said and done, more is said than done.
On Wed, 3 Jan 2018 19:45, Carlos E. R. <robin.listas@...> wrote:
On 2018-01-03 17:48, Linda Walsh wrote:
* For good measure, similar software protections will be included on 64-bit ARM kernels as well; While AMD chips aren't affected by this bug, it's hard to see an update physically-splitting (instead of just virtually-splitting) all kernel & user code, only being applied against Intel and ARM (i.e. AMD chip-based systems may likely be affected by the slowdown due to the fix being applied across 64-bit kernels.
AMD has asked the measure not be applied to their processors.
Any method to know if /my/ processor is affected? It was bought several years ago. A list of exact processor models for looking in /proc/cpuinfo, perhaps.
AFAICT, if is has 'Core' in its name, its affected, as well as all other Processor models of the last 6 years at least, talk is going on on the older models, up to 10 years back is hit in certain models. Check the better sources, e.g. the more serious computer publications or proven to be better informed sources on the internet on details. Root cause is a 'accelerated' branch pre-execution, in other words, they dropped the security checks to gain speed. My Haswell is hit by it for sure. - Yamaban
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2018-01-03 at 23:48 +0100, Yamaban wrote:
On Wed, 3 Jan 2018 19:45, Carlos E. R. <robin.listas@...> wrote:
Any method to know if /my/ processor is affected? It was bought several years ago. A list of exact processor models for looking in /proc/cpuinfo, perhaps.
AFAICT, if is has 'Core' in its name, its affected, as well as all other Processor models of the last 6 years at least, talk is going on on the older models, up to 10 years back is hit in certain models.
Core 2 Duo, so yes, I'm hit.
Check the better sources, e.g. the more serious computer publications or proven to be better informed sources on the internet on details.
Links will pop up in time :-)
Root cause is a 'accelerated' branch pre-execution, in other words, they dropped the security checks to gain speed.
Yes, that part I found out. Intentionally? They forgot? Ineptitude? Did they really think they would not be found out? Sigh :-( - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpOIogACgkQtTMYHG2NR9V1zgCfYLafeqlzFFZ6P3MB7Uj8XAmj zPgAn1pm+mQ5Aq4dR/+ZrmtKsKQlQLkU =jiwx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 4 Jan 2018 13:48, Carlos E. R. wrote:
On Wednesday, 2018-01-03 at 23:48 +0100, Yamaban wrote:
On Wed, 3 Jan 2018 19:45, Carlos E. R. wrote:
Any method to know if /my/ processor is affected? It was bought several years ago. A list of exact processor models for looking in /proc/cpuinfo, perhaps.
AFAICT, if is has 'Core' in its name, its affected, as well as all other Processor models of the last 6 years at least, talk is going on on the older models, up to 10 years back is hit in certain models.
Core 2 Duo, so yes, I'm hit.
Check the better sources, e.g. the more serious computer publications or proven to be better informed sources on the internet on details.
Links will pop up in time :-)
Root cause is a 'accelerated' branch pre-execution, in other words, they dropped the security checks to gain speed.
Yes, that part I found out.
Intentionally? They forgot? Ineptitude? Did they really think they would not be found out? Sigh :-(
Well, no. "The Issue" dated back to the development of the "Pentium Pro", the 32bit dual-core Pentium from 1995. Intel found out the hard way that the branch prediction engine they planned to include was a mass grave of transistors, thus immensely expensive and drove the already low yield of the production down to single digits of percents. So, to get even a kind of a grip at the situation, the whole branch prediction engine was re-designed. Much simpler, used less cycles, used not even a tenth of the transistors. Intel hyped that as "Productivity Enhanced" Branch Prediction in the pre-release days. The documentation of the Pentium Pro clearly stated the restrictions the reduced branch prediction unit had, and the compilers at the time handled that with the needed care. Fast forward to around 2005, the race between Intel and AMD got "not nice" and thus Intel "optimised" its own compiler to reduce the prior as "must have" declared security checks to gain speed. In the name of performance over everything else this kind of optimisation found its way into other code. Databases, OS-kernels, compilers. You can easily do the math. Using a non paranoid compiler opens you up the the holes now published (they where found before October 2017). (Much of the harshness of the situation is the dramatically risen level of visualisation compared to ten years ago.) So, much to late for Intel or AMD to include a hardware based defence into the latest architectures (that needs at least 15 month lead time) Will Intel's next Arch (Core i{3,5,7,9}-9yyy) have such a defence? More likely no, same with AMD and ARM. At the base we are left with dropped security checks and left out early randomisation for context changes and other heavy lifting stuff in nearly very bit of code, simply because there are very little people left that can program such check without opening wide the doors for much more ugly attacks. The TODO now is to redefine "best (and/or) acceptable practises in coding for such situations. The fastest way to get the redefined message out would be compilers that will not accept code that violates such "best practises" easily. Will we see a real break-through on that matter in 2018? - My gut tells me: NO real chance, just some small steps (with performance penalties). So, pressing anyone for replacemnt hardware: Prepare to be laughed out of the doors, while fingers are pointed to the compiler guys. - Yamaban. PS: If I've got stuff wrong, please speak out with the truth. I'm no god, nor otherwise omnipotent. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 4 Jan 2018 17:47:28 +0100 (CET) Yamaban <foerster@lisas.de> wrote:
Well, no. "The Issue" dated back to the development of the "Pentium Pro", the 32bit dual-core Pentium from 1995.
Intel found out the hard way that the branch prediction engine they planned to include was a mass grave of transistors, thus immensely expensive and drove the already low yield of the production down to single digits of percents. So, to get even a kind of a grip at the situation, the whole branch prediction engine was re-designed. Much simpler, used less cycles, used not even a tenth of the transistors. Intel hyped that as "Productivity Enhanced" Branch Prediction in the pre-release days.
The documentation of the Pentium Pro clearly stated the restrictions the reduced branch prediction unit had, and the compilers at the time handled that with the needed care.
Fast forward to around 2005, the race between Intel and AMD got "not nice" and thus Intel "optimised" its own compiler to reduce the prior as "must have" declared security checks to gain speed. In the name of performance over everything else this kind of optimisation found its way into other code. Databases, OS-kernels, compilers. You can easily do the math. Using a non paranoid compiler opens you up the the holes now published (they where found before October 2017). (Much of the harshness of the situation is the dramatically risen level of visualisation compared to ten years ago.)
I am not a world-class expert in this, but I was watching and writing about this tech at the time. I have not heard about the details you're talking about here. Note, please, I am not saying you're wrong! There was a significant step that you don't mention though. The Pentium Pro was the first Intel micro-architecture (called P6) to break down instructions into micro-operations and do out-of-order execution on them (AFAICR.) The Pentium Pro was the basis of the Pentium II and Pentium III, with essentially the same P6 architecture. The Pentium 4 was a new chip with a new architecture, Netburst. Notably, along with everything else, it had an all-new branch-prediction unit. It was famous for high clock speeds, low instructions-per-clock (IPC) rate, running very hot and generally not being a great CPU family. AMD's Sledgehammer architecture (Athlon 64/Opteron) thrashed it. So, Intel Israel got the job of designing a successor. They produced the Pentium M low-power-draw chip for laptops: a P6 core, but on the new bus of the Pentium 4 and with Netburst's improved branch prediction unit. It had good IPC, ran cool, and was a success. Around the same time, Intel India was working on quad-core P4 CPUs. Due to violating Intel's strict policies on nepotism and cronyism, Intel India was shut down, meaning the end of the planned future line of Netburst CPUs. Intel switched emphasis to the Pentium M. Intel Texas got the job of updating the P4 line with dual-core models (2 separate CPU dies in 1 package) and with adapting AMD's 64-bit instruction set extensions. (Intel had devised its own x86-64 extension but Microsoft vetoed it. MS said it was already supporting x86-32, Itanium and AMD64, and would not additionally support another 64-bit instruction set architecture. Intel scrapped its own x86-64 ISA and implemented AMD's instead.) Meanwhile, Intel Israel enhanced the Pentium M to produce the 32-bit Core processors, and then those were enhanced to support AMD64, creating the Core 2 series. Netburst was discontinued, in a huge, humiliating and very expensive climb-down and turnaround for Intel. AFAICT, the Core series was where what's now being called Meltdown began. I.e. with the incorporation of the Netburst branch-prediction unit into a descendant of the P6 microarchitecture. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/01/18 23:48, Carlos E. R. wrote:
On Wednesday, 2018-01-03 at 23:48 +0100, Yamaban wrote:
On Wed, 3 Jan 2018 19:45, Carlos E. R. <robin.listas@...> wrote:
Any method to know if /my/ processor is affected? It was bought several years ago. A list of exact processor models for looking in /proc/cpuinfo, perhaps.
AFAICT, if is has 'Core' in its name, its affected, as well as all other Processor models of the last 6 years at least, talk is going on on the older models, up to 10 years back is hit in certain models.
Core 2 Duo, so yes, I'm hit.
Check the better sources, e.g. the more serious computer publications or proven to be better informed sources on the internet on details.
Links will pop up in time :-)
Root cause is a 'accelerated' branch pre-execution, in other words, they dropped the security checks to gain speed.
Yes, that part I found out.
Intentionally? They forgot? Ineptitude? Did they really think they would not be found out? Sigh :-(
But..but...it's taken some 20-odd years to be "found out"! :-) BC -- Always be nice to people on your way up -- you'll see the same people on your way down. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/04/2018 05:44 PM, Basil Chupin wrote:
But..but...it's taken some 20-odd years to be "found out"! :-)
As far as YOU know! -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/04/2018 09:42 PM, John Andersen wrote:
On 01/04/2018 05:44 PM, Basil Chupin wrote:
But..but...it's taken some 20-odd years to be "found out"! :-) As far as YOU know!
Here's something interesting: http://www.pcgamer.com/intel-ceo-sold-39-million-in-company-shares-prior-to-... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/04/2018 09:25 PM, James Knott wrote:
Here's something interesting: http://www.pcgamer.com/intel-ceo-sold-39-million-in-company-shares-prior-to-...
Text-book example of insider trading.... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2018-01-05 at 04:40 -0600, David C. Rankin wrote:
On 01/04/2018 09:25 PM, James Knott wrote:
Here's something interesting: http://www.pcgamer.com/intel-ceo-sold-39-million-in-company-shares-prior-to-...
Text-book example of insider trading....
They claim it is unrelated, because the sale was planned before. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpPfhoACgkQtTMYHG2NR9VlFACfTyFLrT9xYwz+WsHhScDmHGwH ytEAoJArwdvNEnSkUPIhbRMZHV0sc2lZ =fF/9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/05/2018 08:30 AM, Carlos E. R. wrote:
On Friday, 2018-01-05 at 04:40 -0600, David C. Rankin wrote:
On 01/04/2018 09:25 PM, James Knott wrote:
Here's something interesting:
http://www.pcgamer.com/intel-ceo-sold-39-million-in-company-shares-prior-to-...
Text-book example of insider trading....
They claim it is unrelated, because the sale was planned before.
From https://techcrunch.com/2018/01/04/after-meltdown-and-spectre-revelation-ques... "The shares were sold in accordance with a SEC Rule 10b5-1 plan, which is intended to prevent illegal insider trading by allowing company executives to create predetermined, automatic selling plans. The Form 4 filed by Krzanich, however, state that the plan was adopted on October 30, 2017—months after Google says it informed Intel and other affected companies <https://www.reuters.com/article/us-cyber-intel/design-flaw-found-in-intel-chips-fix-causes-them-to-slow-report-idUSKBN1ES1BO> about the bugs in June, which in turn were only made public this week in reports by The Register <https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/>and other media." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, 2018-01-05 at 08:49 -0500, James Knott wrote:
On 01/05/2018 08:30 AM, Carlos E. R. wrote:
On Friday, 2018-01-05 at 04:40 -0600, David C. Rankin wrote:
On 01/04/2018 09:25 PM, James Knott wrote:
Here's something interesting:
http://www.pcgamer.com/intel-ceo-sold-39-million-in-company-shares- prior-to-disclosure-of-cpu-security-flaws/
Text-book example of insider trading....
They claim it is unrelated, because the sale was planned before.
From https://techcrunch.com/2018/01/04/after-meltdown-and-spectre-revelati on-questions-arise-about-timing-of-intel-ceos-stock-sales/
"The shares were sold in accordance with a SEC Rule 10b5-1 plan, which is intended to prevent illegal insider trading by allowing company executives to create predetermined, automatic selling plans. The Form 4 filed by Krzanich, however, state that the plan was adopted on October 30, 2017—months after Google says it informed Intel and other affected companies <https://www.reuters.com/article/us-cyber-intel/design-flaw-found-in- intel-chips-fix-causes-them-to-slow-report-idUSKBN1ES1BO> about the bugs in June, which in turn were only made public this week in reports by The Register <https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/>and other media."
History repeats itself... https://www.reuters.com/article/us-equifax-cyber/equifax-clears-executi ves-who-sold-shares-after-hack-idUSKBN1D31EK I anticipate a similar course of action soon, where someone at Intel says "but the CEO didn't find out about the breach until aaaaaafter the sale!" Uh huh. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAlpPnToACgkQQ1nEo4DF CIVpBwf9Es+Vpb5d7Ta0un7b1HVVpJt0hZuKIWcZkCjp3ClXwSNRYTYgvWbwWixS 1fIxH9KX7vWGqh5r8pbZYOtTFr4thq0RynHN6lyiwIUgkz//vCwSs6Ho13dV9Qng 5YGmzMm0HzLpFac10fYFDQIgmOo/34JuJPhG9WzmNa7p3fVC0B5ICeWe3WzUj2Fc d26MWrwY8+9LP5nuaZ3nBcaWs1nJjMwpibdwvUP74GCcR8j7IOqMZ0LvoPzF6xpr hEb/oNvW8HQpMwclyBvBMxbxH74DX5B/fL49R92wkaul7P8uVpIkLYhnVJpHBao6 9bPQz4JTgh9UT2NZfcqPUbhU92Mdxg== =BSk4 -----END PGP SIGNATURE----- N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�: �{Zr�az�'z��j)h���Ǿ� ޮ�^�ˬz��
On 01/05/2018 07:30 AM, Carlos E. R. wrote:
They claim it is unrelated, because the sale was planned before.
You bought that BS, hook-line-and-sinker. Never trust a marketing statement by Intel. After Google informed Intel of the problem, Brian Krzanich put in place a planned divestiture program time to liquidate the shares BEFORE new of the flaw was scheduled to be released to the public. That's how insider-schemes generally work. To wade through the BS that is put out, you have to read more that what Intel puts out on Page1 -- you actually have to take the time to read what is on Page2 to get to the truth of the matter. (It would be a clear case of fraud if a used-car salesman did it that way, but press-releases by Intel aren't subject to the same penalty (that's a shame...) A good page two in this case is: http://www.businessinsider.com/intel-ceo-krzanich-sold-shares-after-company-... In this day of lying politicians, and abjectly false information being spread, it is up to all of us as thinking individuals to always make sure we read page 2 :) -- David C. Rankin, J.D.,P.E.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (let's take this to the OT list) On Monday, 2018-01-08 at 04:03 -0600, David C. Rankin wrote:
On 01/05/2018 07:30 AM, Carlos E. R. wrote:
They claim it is unrelated, because the sale was planned before.
You bought that BS, hook-line-and-sinker. Never trust a marketing statement by Intel.
No, I did not buy it. I simply wondered. Maybe somebody knew something else that could break their claim. So I asked, I commented.
After Google informed Intel of the problem, Brian Krzanich put in place a planned divestiture program time to liquidate the shares BEFORE new of the flaw was scheduled to be released to the public. That's how insider-schemes generally work.
To wade through the BS that is put out, you have to read more that what Intel puts out on Page1 -- you actually have to take the time to read what is on Page2 to get to the truth of the matter. (It would be a clear case of fraud if a used-car salesman did it that way, but press-releases by Intel aren't subject to the same penalty (that's a shame...)
A good page two in this case is: http://www.businessinsider.com/intel-ceo-krzanich-sold-shares-after-company-...
In this day of lying politicians, and abjectly false information being spread, it is up to all of us as thinking individuals to always make sure we read page 2 :)
- -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpTeowACgkQtTMYHG2NR9UqjwCfR9grX6SPnb/jbO9DmaXliovy 1WoAn0/2axQO0Rx9NqW5KfmJHElYg7og =PDUK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/01/18 13:42, John Andersen wrote:
On 01/04/2018 05:44 PM, Basil Chupin wrote:
But..but...it's taken some 20-odd years to be "found out"! :-) As far as YOU know!
True. And as moi k-n-o-w-s n-u-t-h-i-n', moi can only go on the year 1995 mentioned in this list :-) BC -- Always be nice to people on your way up -- you'll see the same people on your way down. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2018-01-05 at 12:44 +1100, Basil Chupin wrote:
On 04/01/18 23:48, Carlos E. R. wrote:
On Wednesday, 2018-01-03 at 23:48 +0100, Yamaban wrote:
...
Root cause is a 'accelerated' branch pre-execution, in other words, they dropped the security checks to gain speed.
Yes, that part I found out.
Intentionally? They forgot? Ineptitude? Did they really think they would not be found out? Sigh :-(
But..but...it's taken some 20-odd years to be "found out"! :-)
Riiiight. So... Really trust business and market forces to do the right thing? - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpPfoYACgkQtTMYHG2NR9WKqgCfen1rwKf0lDlW5zdrjlCAGeKV KPEAnRszlwTaXi/NQCp8+fULPM7rp9CO =hiAj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Carlos E. R. <robin.listas@telefonica.net> [01-05-18 08:35]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday, 2018-01-05 at 12:44 +1100, Basil Chupin wrote:
On 04/01/18 23:48, Carlos E. R. wrote:
On Wednesday, 2018-01-03 at 23:48 +0100, Yamaban wrote:
...
Root cause is a 'accelerated' branch pre-execution, in other words, they dropped the security checks to gain speed.
Yes, that part I found out.
Intentionally? They forgot? Ineptitude? Did they really think they would not be found out? Sigh :-(
But..but...it's taken some 20-odd years to be "found out"! :-)
Riiiight.
So... Really trust business and market forces to do the right thing?
yes, really. wasn't it you that commented on one of the intel exec's selling stock ahead of anticipated price drop? market force in action, prompting illegal activity to avoid monitary loss. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday, 2018-01-05 at 12:44 +1100, Basil Chupin wrote:
On 04/01/18 23:48, Carlos E. R. wrote:
On Wednesday, 2018-01-03 at 23:48 +0100, Yamaban wrote:
...
Root cause is a 'accelerated' branch pre-execution, in other words, they dropped the security checks to gain speed.
Yes, that part I found out.
Intentionally? They forgot? Ineptitude? Did they really think they would not be found out? Sigh :-(
But..but...it's taken some 20-odd years to be "found out"! :-)
Riiiight.
So... Really trust business and market forces to do the right thing?
Define the "right thing". -- Per Jessen, Zürich (9.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/05/2018 02:42 PM, Per Jessen wrote:
So... Really trust business and market forces to do the right thing? Define the "right thing".
There are a lot of people who want deregulation of business, because it gets in the way of making more money and they insist business will be good and do the "right thing" without regulations. They ignore the fact that it's contrary to what history shows in that very often business will do what's right for that business, without regard for harm to others. It's even got to the point where execs are doing what's good for them, regardless of damage they cause to the company they work for. It all boils down to blatant greed at the top. Trump, with his recent changes, will only make a very bad situation worse. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2018-01-05 at 15:16 -0500, James Knott wrote:
On 01/05/2018 02:42 PM, Per Jessen wrote:
So... Really trust business and market forces to do the right thing? Define the "right thing".
There are a lot of people who want deregulation of business, because it gets in the way of making more money and they insist business will be good and do the "right thing" without regulations. They ignore the fact that it's contrary to what history shows in that very often business will do what's right for that business, without regard for harm to others. It's even got to the point where execs are doing what's good for them, regardless of damage they cause to the company they work for. It all boils down to blatant greed at the top. Trump, with his recent changes, will only make a very bad situation worse.
My thoughts exactly :-) It is rip time for open source chips. It will be a good thing if Intel dies. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpP6igACgkQtTMYHG2NR9WGIACeKsiS0ofurS54j3CFdzLoly0y 5pUAnR9EfAL0jVWXSKXdw3VwFejuM1+b =Ua5I -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 01/05/2018 02:42 PM, Per Jessen wrote:
So... Really trust business and market forces to do the right thing? Define the "right thing".
There are a lot of people who want deregulation of business, because it gets in the way of making more money and they insist business will be good and do the "right thing" without regulations. They ignore the fact that it's contrary to what history shows in that very often business will do what's right for that business, without regard for harm to others. It's even got to the point where execs are doing what's good for them, regardless of damage they cause to the company they work for. It all boils down to blatant greed at the top. Trump, with his recent changes, will only make a very bad situation worse.
Oh I agree - I just wanted to point out that the "right thing" isn't always easy to determine or agree on. Anyway, off-topic stuff. -- Per Jessen, Zürich (3.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Jan 5, 2018 at 3:16 PM, James Knott <james.knott@rogers.com> wrote:
There are a lot of people who want deregulation of business, because it gets in the way of making more money and they insist business will be good and do the "right thing" without regulations. They ignore the fact that it's contrary to what history shows in that very often business will do what's right for that business, without regard for harm to others. It's even got to the point where execs are doing what's good for them, regardless of damage they cause to the company they work for. It all boils down to blatant greed at the top. Trump, with his recent changes, will only make a very bad situation worse.
So all businesses should be punished for the greed of a few? People have a choice(generally) as to doing business with a company of not. I don't do business with Facebook because I don't trust them or see any use in their "product"(basically selling my info to advertisers). I don't trust politicians to take tax money and do the right thing. If it's a choice between trusting a business or the government, I will take a business any day. Just my 2 cents. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/06/2018 11:33 AM, Larry Stotler wrote:
On Fri, Jan 5, 2018 at 3:16 PM, James Knott <james.knott@rogers.com> wrote:
There are a lot of people who want deregulation of business, because it gets in the way of making more money and they insist business will be good and do the "right thing" without regulations. They ignore the fact that it's contrary to what history shows in that very often business will do what's right for that business, without regard for harm to others. It's even got to the point where execs are doing what's good for them, regardless of damage they cause to the company they work for. It all boils down to blatant greed at the top. Trump, with his recent changes, will only make a very bad situation worse. So all businesses should be punished for the greed of a few? People have a choice(generally) as to doing business with a company of not. I don't do business with Facebook because I don't trust them or see any use in their "product"(basically selling my info to advertisers).
I don't trust politicians to take tax money and do the right thing. If it's a choice between trusting a business or the government, I will take a business any day.
Just my 2 cents.
No, I don't think all businesses should be punished for the few. However, I expect all businesses to held accountable for their actions, including personal penalties for the execs & board when appropriate. At one time the board was always legally responsible. As for examples of why this is needed, look at how the guy that owned most of Sears Canada stole the pension funds and wages from employees. Or how Nortel was trashed by execs cooking the books. There are a lot more examples of where greed at the top has caused a lot of harm for others. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/18 18:50, James Knott wrote:
As for examples of why this is needed, look at how the guy that owned most of Sears Canada stole the pension funds and wages from employees. Or how Nortel was trashed by execs cooking the books. There are a lot more examples of where greed at the top has caused a lot of harm for others.
Kenneth Lay? Rupert Murdoch. As you say, plenty more. The problem is how do you hold executives accountable for the actions of the company? How do you prove they knew what was going on, and weren't hoodwinked by the people below them? (Or were deluding themselves that things weren't as bad as they looked.) I think the real problem lies in the legislative assumption that companies are supposed to act in the interests of SHAREholders. The *reality* is that companies should act in the interests of their stakeholders because quite often you can't tell the difference between shareholders, employees and customers. But because of the way things are now set up, people don't have a clue ... The majority of people work for small companies. The system is rigged in favour of big companies. What more needs to be said? Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jan 6, 2018 at 1:50 PM, James Knott <james.knott@rogers.com> wrote:
No, I don't think all businesses should be punished for the few. However, I expect all businesses to held accountable for their actions, including personal penalties for the execs & board when appropriate. At one time the board was always legally responsible. As for examples of why this is needed, look at how the guy that owned most of Sears Canada stole the pension funds and wages from employees. Or how Nortel was trashed by execs cooking the books. There are a lot more examples of where greed at the top has caused a lot of harm for others.
I do agree with that. However, the problem is that corruption is everywhere. In business, government, etc, etc. Some people seem to think that you can legislate morality and you can't. People are going to do what they decide to do no matter what the law or the consequences may be. Lawyers get elected to office, and they write the laws. Other lawyers become judges and they decide/interpret the law. The rest of them argue the law and promise the world to their clients and charge outrageous fees to do so. The difference between business and government is that with business you have a choice to do business or not. With government, you have little choice other than trying to vote in someone else. But there are so many more "public servants" that are elected that are almost accountable to no one. Of course with Obamacare here in the US, the Government tried to force you to do business whether you wanted to or not. Money and wealth are what run the world. Those who have it make the rules to benefit them. Those who don't complain about the rules. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/06/2018 03:44 PM, Larry Stotler wrote:
Of course with Obamacare here in the US, the Government tried to force you to do business whether you wanted to or not.
Money and wealth are what run the world. Those who have it make the rules to benefit them. Those who don't complain about the rules.
One thing to bear in mind is that health care in the U.S. has been a disaster, for many years before Obama. It's is the most expensive in the world, yet leaves many without any health care. At least Omamacare tried to make health care universal. In Canada, our health care is paid through our taxes. As a result, I can go to a doctor or hospital and not worry about having to pay a bill. It falls short in that it does not cover dental or most prescriptions, both of which are essential to a proper health care system. The big problem in the U.S. are those who are absolutely against anything that helps those who need help. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/18 21:33, James Knott wrote:
The big problem in the U.S. are those who are absolutely against anything that helps those who need help.
The other big problem, from what I understand, is that as in so many other things, the number of healthcare providers has dropped massively. As a result, new startups rapidly get bought out ... The insurance companies can negotiate big discounts, but for those people who can't afford insurance they have to pay list price, which can easily be several times what the insurance companies charge. As always, those who can least afford it, have to pay most ... (I can't defend a lot about the NHS, I think we've gone the other way where we won't let people pay who can, but at least care is available to everyone, and it's reasonably decent care.) Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 6 Jan 2018 22:34:36 +0000 Wol's lists <antlists@youngman.org.uk> wrote:
(I can't defend a lot about the NHS, I think we've gone the other way where we won't let people pay who can, but at least care is available to everyone, and it's reasonably decent care.)
Your choice of the word 'care' was perhaps unfortunate, since that's exactly where the NHS isn't available to everyone. Local authorities pay discount rates to care homes for those un/lucky enough to qualify, whilst others have to pay themselves at inflated rates that subsidise the public purse. And of course, anybody can pay for pretty much anything if they want, the only thing that is not allowed is private care in some parts of some NHS hospitals, AIUI. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jan 6, 2018 at 5:34 PM, Wol's lists <antlists@youngman.org.uk> wrote:
The insurance companies can negotiate big discounts, but for those people who can't afford insurance they have to pay list price, which can easily be several times what the insurance companies charge. As always, those who can least afford it, have to pay most ...
Yep. Providers that accept insurance are told what they can charge and have to wait to get the payment. While those who would prefer to pay cash are charged more even though they can pay today. The insurance companies negotiate things this way to discourage providers from taking cash payments. It's rather retarded. Then again, M$ was allowed to charge for a copy of DOS and then DOS/Win for every computer you sold regardless of whether it went out the door with it or whether it was wanted. Money makes the rules. Not just here, but everywhere. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jan 6, 2018 at 4:33 PM, James Knott <james.knott@rogers.com> wrote:
The big problem in the U.S. are those who are absolutely against anything that helps those who need help.
The problem isn't so much as helping those who need it, it's about separating those who truly need help from the moochers. There are many in the US that will take a handout even if they don't deserve it and then do nothing to help cover it. At some point, you have to have people paying into the system to take care of those who aren't. The more you add to the dole, the less you have contributing. Further, the people in charge make it harder for everyone else by creating an artificial lower level standard. Who should a residence be required to be a certain size if someone would be just as happy with half that and is living well? 150 years ago, people didn't have power, running water, etc, but now those trying to live small and off the grid are considered wrong. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/07/2018 10:17 PM, Larry Stotler wrote:
The problem isn't so much as helping those who need it, it's about separating those who truly need help from the moochers. There are many in the US that will take a handout even if they don't deserve it and then do nothing to help cover it.
That describes some at the top too. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-01-07 at 22:17 -0500, Larry Stotler wrote:
Further, the people in charge make it harder for everyone else by creating an artificial lower level standard. Who should a residence be required to be a certain size if someone would be just as happy with half that and is living well?
Because if not, some builders try to build smaller and charge the same or more. And because those that are under some obligation (for whatever reason) to provide lodgings try to make do with smaller and cheaper. But this is offtopic. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpS6JUACgkQtTMYHG2NR9WEAgCbBL5XSJMeeWrsaWCm+aOWdlFP rh0An1a8l2/CNwsRJdGNToCD3UTS7/HF =dfNq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/18 00:32, Carlos E. R. wrote:
On Friday, 2018-01-05 at 12:44 +1100, Basil Chupin wrote:
On 04/01/18 23:48, Carlos E. R. wrote:
On Wednesday, 2018-01-03 at 23:48 +0100, Yamaban wrote:
...
Root cause is a 'accelerated' branch pre-execution, in other words, they dropped the security checks to gain speed.
Yes, that part I found out.
Intentionally? They forgot? Ineptitude? Did they really think they would not be found out? Sigh :-(
But..but...it's taken some 20-odd years to be "found out"! :-)
Riiiight.
So... Really trust business and market forces to do the right thing?
I was simply responding to what you wrote/asked in your last paragraph. But now I realise that I should have been less obtuse in what I wrote and should have written, "Yes, they did and they got away with it for 20-odd years." BC -- Always be nice to people on your way up -- you'll see the same people on your way down. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2018-01-06 at 16:08 +1100, Basil Chupin wrote:
On 06/01/18 00:32, Carlos E. R. wrote:
Intentionally? They forgot? Ineptitude? Did they really think they would not be found out? Sigh :-(
But..but...it's taken some 20-odd years to be "found out"! :-)
Riiiight.
So... Really trust business and market forces to do the right thing?
I was simply responding to what you wrote/asked in your last paragraph. But now I realise that I should have been less obtuse in what I wrote and should have written, "Yes, they did and they got away with it for 20-odd years."
Yes, indeed. It is just possible that somebody did find it and used it carefully and silently to their advantage. And I mean carefully because once found it can be used in any direction, so better it be a secret. Besides, I now consider open sourced CPUs a very interesting idea. Not trusting Intel anymore. Never. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpQyvIACgkQtTMYHG2NR9WNWACeOgMdjx7mXIKNOgzAYnGLtAYt 5/4Anj6gW/07ipBjIfxgoOdl7YYoiDaS =Eg1W -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/06/2018 05:11 AM, Carlos E. R. wrote:
Besides, I now consider open sourced CPUs a very interesting idea. Not trusting Intel anymore. Never.
I haven't trusted them since their FPU bug coverup! Yes, an open-sourced CPU design would be great. Perhaps Sun's SPARC could be used as a starting point? I believe they open-sourced it before they were subsumed by Oracle. Will this dust-up also re-awaken the CISC/RISC debates? Complexity and security are inversely proportional, and Intel's complex instruction set CPU's set the standard for complexity. They hide whole CPU's inside the CPU facade they publicly display! Reduced instruction set CPU's are consistent with the UNIX Philosophy: a function should do only a few basic things, but it should do them very well. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 6 Jan 2018 07:40:23 -0800 Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
On 01/06/2018 05:11 AM, Carlos E. R. wrote:
Besides, I now consider open sourced CPUs a very interesting idea. Not trusting > Intel anymore. Never.
I haven't trusted them since their FPU bug coverup!
Yes, an open-sourced CPU design would be great. Perhaps Sun's SPARC could be used as a starting point? I believe they open-sourced it before they were subsumed by Oracle.
Will this dust-up also re-awaken the CISC/RISC debates? Complexity and security are inversely proportional, and Intel's complex instruction set CPU's set the standard for complexity. They hide whole CPU's inside the CPU facade they publicly display! Reduced instruction set CPU's are consistent with the UNIX Philosophy: a function should do only a few basic things, but it should do them very well.
Perhaps a good starting point may be the RISC-V architecture: https://riscv.org/ In particular: https://riscv.org/2018/01/more-secure-world-risc-v-isa/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/18 15:40, Lew Wolfgang wrote:
On 01/06/2018 05:11 AM, Carlos E. R. wrote:
Besides, I now consider open sourced CPUs a very interesting idea. Not trusting Intel anymore. Never.
I haven't trusted them since their FPU bug coverup!
Companies aren't good - or bad. It's the people in them (usually set by direction from the top). That's why I trust Google, but not Facebook. Not that I trust them implicitly, but if Google messes me up I expect it to be a genuine accident. Facebook is far more likely to be "accidentally on purpose".
Yes, an open-sourced CPU design would be great. Perhaps Sun's SPARC could be used as a starting point? I believe they open-sourced it before they were subsumed by Oracle.
Surely it's not beyond the wit of the Open Source crowd to define a basic VLW RISC instruction set, and then put a CISC interpreter layer on top ...
Will this dust-up also re-awaken the CISC/RISC debates? Complexity and security are inversely proportional, and Intel's complex instruction set CPU's set the standard for complexity. They hide whole CPU's inside the CPU facade they publicly display!
For very good reason, unfortunately :-( Modern CPUs can be clocked to what - 5GHz? That means that - per instruction cycle - a signal can move approximately two inches. Meanwhile, a motherboard is about a foot square ... Today's fast chips *need* to have pretty much an entire computer inside the die simply to be able to work at speed.
Reduced instruction set CPU's are consistent with the UNIX Philosophy: a function should do only a few basic things, but it should do them very well.
That's great, but don't forget the SECOND half of Einstein's great dictum - make things as simple as possible BUT NO SIMPLER. (Don't get me started - relational theory is great but as the basis of a database engine IT'S TOO SIMPLE.) The following makes interesting reading ... https://science.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-commission/Ap... One of Feynmann's key points is that management has a habit of fooling itself, and I have no doubt that Intel are sincere. Whether they are, like the best conmen, fooling themselves is open to debate. And actually, why should I assume other companies are any different? Who remembers the Lenovo root certificate scandal? There are too many people in positions of influence who, in all sincerity, push for decisions whose consequences they have no clue about. And unfortunately usually the people who DO have a clue are in no position to influence the decision. What's that saying? "Trust but verify". What's that alleged saying by Churchill? "The Americans can always be trusted to do the right thing. After they've tried all the alternatives, of course". Companies are no different. Which is why the loss of so many engineers in senior management is a technological tragedy :-( Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/18 10:40 AM, Lew Wolfgang wrote:
Reduced instruction set CPU's are consistent with the UNIX Philosophy: a function should do only a few basic things, but it should do them very well.
Well RISC is at risk. The origins of the ARM lie in RISC but we've come a long way since then. <quote src="https://www.extremetech.com/computing/187513-why-apple-wont-dump-intel-x86-for-its-own-arm-chips-in-macbooks-and-the-mac-pro"> ... also reprints some laughably untrue assertions about the ARM-x86 comparison, writing “The aging x86 architecture is beset by layers of architectural silt accreted from a succession of additions to the instruction set. Emerging media formats demand new extensions, while obsolete constructs must be maintained for the sake of Microsoft’s backward compatibility religion.” </quote> Also https://www.androidauthority.com/arm-vs-x86-key-differences-explained-568718... Many years ago I worked with an English Electric 800 Series computer. It was all transistors, an asynchronous CPU, and was FAST! It did only have 16 opcodes They were hard-wired, not microcoded. I never peered at the logic and it must have been frightening. But it really really was just 16 instructions. I think it was a 803 with 39 bt words that contained 2 16-bit instructions (or one plus an address parameter). IO was TTY and paper-tape. Later models upped the instruction repertoire to 64 to do more things with arithmetic like 'negate and add', but model I had worked n 16 instructions. OK, one was "DO IO" which was ... complex ... but hard-wired. If you've read Knuth you'll be aware that you don't need more than those 16 opcodes. See the MIX assembly language, which, sadly, multiplies them out when it comes to writing, because of the way modifier works, so there are a half dozen ways the LOAD command can work. Again, in "Algorithms and Data structures = programs" there is a true RISK VM model in the PASCAL interpreter. The main difference between Knuth and Wirth is that the latter works with a single register machine, Europeans being more parsimonious in their architecture than Americans, who preferred multi-register machines, and as a side effect, the compiler parse tree is easily translated into reverse polish which is suitable for a single register machine. If you are going to throw compiler optimization at things, the RP/single register machine is very, very easy to optimise code pathways for, no need to worry about register allocation & dumping strategies (and less context to save on interrupts!). You can make the compiler small and fast; or you can make it capable of doing more global optimization and probabilistic execution tree-branch analysis. Some of there attempts at RISK were based on the idea that now there was so much silicon on the chip freed up -- oh, wait, we've moved on from transistors and are playing in a new field -- that the machine can now have lots of registers. One model was actually a zero-register concept with everything being indirect and the working memory being on chip. Dealing with interrupts means simply switching the register bank pointer. Silicon real estate was cheap; heck today its even cheaper and that kind of RISK makes more sense now. A variant of this is https://en.wikipedia.org/wiki/Register_window The SPARC architecture also makes use of a lot of registers and modern silicon fabrication can work on the initial spec to offer even more. <quote src="https://en.wikipedia.org/wiki/SPARC"> The SPARC processor usually contains as many as 160 general purpose registers. According to the "Oracle SPARC Architecture 2015" specification an "implementation may contain from 72 to 640 general-purpose 64-bit" registers.[3] At any point, only 32 of them are immediately visible to software — 8 are a set of global registers (one of which, g0, is hard-wired to zero, so only seven of them are usable as registers) and the other 24 are from the stack of registers. These 24 registers form what is called a register window, and at function call/return, this window is moved up and down the register stack. Each window has 8 local registers and shares 8 registers with each of the adjacent windows. </quote> There is also mention in the above that "Several fully open source implementations of the SPARC architecture exist". https://en.wikipedia.org/wiki/SPARC#Open_source_implementations Those seem to be 'designs' rather than 'in production'. I suspect, however, that if we were to drive for an implementation of the SPARC we might as well go the whole hog and go for the <quote src="https://en.wikipedia.org/wiki/UltraSPARC_T2"> Sun Microsystems' UltraSPARC T2 microprocessor is a multithreading, multi-core CPU. It is a member of the SPARC family, and the successor to the UltraSPARC T1. The chip is sometimes referred to by its codename, Niagara 2. </quote> And at https://en.wikipedia.org/wiki/UltraSPARC_T2#Open_design <quote> On December 11, 2007, Sun made the UltraSPARC T2 processor design publicly available under the GNU General Public License via the OpenSPARC project. The release includes: Verilog RTL source code of the design Verification environment Diagnostics tests Open source tools, scripts and Sun internal tools needed to simulate the design ISA specification (UltraSPARC Architecture 2007) Solaris 10 OS simulation images </quote> I'm not aware of any FOSS implementation. </quote> We had the Elliott Algol compiler was co-written by C.A.R. (Tony) Hoare. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/18 16:48, Anton Aylward wrote:
The SPARC processor usually contains as many as 160 general purpose registers. According to the "Oracle SPARC Architecture 2015" specification an "implementation may contain from 72 to 640 general-purpose 64-bit" registers.[3] At any point, only 32 of them are immediately visible to software — 8 are a set of global registers (one of which, g0, is hard-wired to zero, so only seven of them are usable as registers) and the other 24 are from the stack of registers. These 24 registers form what is called a register window, and at function call/return, this window is moved up and down the register stack. Each window has 8 local registers and shares 8 registers with each of the adjacent windows.
This sounds to me a bit like the NatSemi 32000 line - it used main memory iirc as its registers, and to save the current settings, you just pushed the base address onto the stack and then moved said base address. But as I said in my other post, the increasing clock speed of cpu's means that more and more stuff has had to move into the cpu chip itself. That said, the ability to do a complete context shift just by changing the value of one offset sounds a very nice thing to have... Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2018-01-06 at 07:40 -0800, Lew Wolfgang wrote:
On 01/06/2018 05:11 AM, Carlos E. R. wrote:
Besides, I now consider open sourced CPUs a very interesting idea. Not trusting Intel anymore. Never.
I haven't trusted them since their FPU bug coverup!
Yes, an open-sourced CPU design would be great. Perhaps Sun's SPARC could be used as a starting point? I believe they open-sourced it before they were subsumed by Oracle.
But this is a company that is very happy to litigate, so nobody wanted to risk it. At least, this is what one of the recent articles I read said. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpSZyAACgkQtTMYHG2NR9WqmACfdILltZlrnPnnF4Me/wKWph2q hGsAn2asp3FV0syD1bWC5tbhaVkyUVNW =4CV0 -----END PGP SIGNATURE-----
Am Sonntag, 7. Januar 2018, 19:29:52 schrieb Carlos E. R.:
On Saturday, 2018-01-06 at 07:40 -0800, Lew Wolfgang wrote:
On 01/06/2018 05:11 AM, Carlos E. R. wrote:
Besides, I now consider open sourced CPUs a very interesting idea. Not trusting Intel anymore. Never.
I haven't trusted them since their FPU bug coverup!
Yes, an open-sourced CPU design would be great. Perhaps Sun's SPARC could be used as a starting point? I believe they open-sourced it before they were subsumed by Oracle.
But this is a company that is very happy to litigate, so nobody wanted to risk it. At least, this is what one of the recent articles I read said. There is the OpenRisc Project ( https://openrisc.io/) .
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/01/18 01:38 PM, Markus Koßmann wrote:
There is the OpenRisc Project ( https://openrisc.io/) .
This, and other links such as those I mentioned in a previous email, are very frustrating. Flashbacks to Swift and Gulliver: all about designs and simulations, but where can I get the real silicon and real microATX mobo for my desktop PC running Linux? At some point the intellectual exercises become self-indulgent and unproductive. (There's a word beginning with 'M' that describes that when its associated with sex, but I think that's a trivial point.) Read: standardization; commercialism, consumerism. Right now we have a wave of "I hate Intel" going on and there's a wonderful marketing opportunity for Linux provided its not on Intel/AMD but *IS* packaged like a regular desktop/mobo and supported the way Ubuntu/Suse/Redhat... are with repositories, office, games ... and a neat GUI admin tool like YAST. The window of opportunity is closing. A month from not many people will be saying "Oh, I have that patched" and "oh, I haven't been affected...". There won't be the interest or incentive. Just watch this list; a month from not what will we be discussing? A month from not what will the media be discussing? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2018-01-08 at 05:44 -0500, Anton Aylward wrote:
On 07/01/18 01:38 PM, Markus Koßmann wrote:
There is the OpenRisc Project ( https://openrisc.io/) .
This, and other links such as those I mentioned in a previous email, are very frustrating. Flashbacks to Swift and Gulliver: all about designs and simulations, but where can I get the real silicon and real microATX mobo for my desktop PC running Linux?
At some point the intellectual exercises become self-indulgent and unproductive. (There's a word beginning with 'M' that describes that when its associated with sex, but I think that's a trivial point.)
Read: standardization; commercialism, consumerism. Right now we have a wave of "I hate Intel" going on and there's a wonderful marketing opportunity for Linux provided its not on Intel/AMD but *IS* packaged like a regular desktop/mobo and supported the way Ubuntu/Suse/Redhat... are with repositories, office, games ... and a neat GUI admin tool like YAST.
The window of opportunity is closing. A month from not many people will be saying "Oh, I have that patched" and "oh, I haven't been affected...". There won't be the interest or incentive.
Just watch this list; a month from not what will we be discussing? A month from not what will the media be discussing?
It needs big players to build silicon. Like those having huge computer farms that now run slower, so that they have to buy more hardware to cope. Are they pushing for a new processor design? - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpTec4ACgkQtTMYHG2NR9XKRgCgksC9RG5S9sMaGbnIJyqCjSoW /esAoI+tz2GUC5UKvC/k8+W3mvDWesKh =+aQp -----END PGP SIGNATURE-----
On Mon, 8 Jan 2018 05:44:59 -0500 Anton Aylward <opensuse@antonaylward.com> wrote:
On 07/01/18 01:38 PM, Markus Koßmann wrote:
There is the OpenRisc Project ( https://openrisc.io/) .
This, and other links such as those I mentioned in a previous email, are very frustrating. Flashbacks to Swift and Gulliver: all about designs and simulations, but where can I get the real silicon and real microATX mobo for my desktop PC running Linux?
Well there is silicon available for the RISC-V architecture I mentioned before, and projects to run Debian are under way. gcc is ported, kernel et al are in progress. https://blog.hackster.io/building-open-hardware-with-risc-v-silicon-39c8348b... https://www.electronicsweekly.com/blogs/engineer-in-wonderland/risc-v-silico... https://www.designnews.com/content/linux-now-has-its-first-open-source-risc-... https://wiki.debian.org/RISC-V -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/01/18 09:57 AM, Dave Howorth wrote:
On Mon, 8 Jan 2018 05:44:59 -0500 Anton Aylward <opensuse@antonaylward.com> wrote:
On 07/01/18 01:38 PM, Markus Koßmann wrote:
There is the OpenRisc Project ( https://openrisc.io/) .
This, and other links such as those I mentioned in a previous email, are very frustrating. Flashbacks to Swift and Gulliver: all about designs and simulations, but where can I get the real silicon and real microATX mobo for my desktop PC running Linux?
Well there is silicon available for the RISC-V architecture I mentioned before, and projects to run Debian are under way. gcc is ported, kernel et al are in progress.
https://blog.hackster.io/building-open-hardware-with-risc-v-silicon-39c8348b...
https://www.electronicsweekly.com/blogs/engineer-in-wonderland/risc-v-silico...
https://www.designnews.com/content/linux-now-has-its-first-open-source-risc-...
The developments, and the speed at which it runs, are a long way removed from what I was asking for. A year? Fiver years? A Decade? Right now there's the pressure. As I said: <quote> Right now we have a wave of "I hate Intel" going on and there's a wonderful marketing opportunity for Linux provided its not on Intel/AMD but *IS* packaged like a regular desktop/mobo and supported the way Ubuntu/Suse/Redhat... are with repositories, office, games ... and a neat GUI admin tool like YAST. The window of opportunity is closing. A month from not many people will be saying "Oh, I have that patched" and "oh, I haven't been affected...". There won't be the interest or incentive. </quote> There is an opportunity for Linux to take over, displace the Intel/Microsoft monopoly. But that's not going to happen with development boards that run one tenth the speed of current CPUs. A fabulous instruction set and great, "mature" compilers isn't going to displace Intel. Now if those chips fitted AM2+, AM3/3+, AM4 LGA-H/H2, FM2/2+, the various server sockets ... Yes, replacement would require some technical dexterity, but for new product there's a host of existing motherboards already in existence & production just waiting to be filled and shipped As I said, there's ta window of opportunity for Linux to take over. It won't happen with a development board. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 8 Jan 2018 11:04:51 -0500 Anton Aylward <opensuse@antonaylward.com> wrote:
On 08/01/18 09:57 AM, Dave Howorth wrote:
On Mon, 8 Jan 2018 05:44:59 -0500 Anton Aylward <opensuse@antonaylward.com> wrote:
On 07/01/18 01:38 PM, Markus Koßmann wrote:
There is the OpenRisc Project ( https://openrisc.io/) .
This, and other links such as those I mentioned in a previous email, are very frustrating. Flashbacks to Swift and Gulliver: all about designs and simulations, but where can I get the real silicon and real microATX mobo for my desktop PC running Linux?
Well there is silicon available for the RISC-V architecture I mentioned before, and projects to run Debian are under way. gcc is ported, kernel et al are in progress.
https://blog.hackster.io/building-open-hardware-with-risc-v-silicon-39c8348b...
https://www.electronicsweekly.com/blogs/engineer-in-wonderland/risc-v-silico...
https://www.designnews.com/content/linux-now-has-its-first-open-source-risc-...
The developments, and the speed at which it runs, are a long way removed from what I was asking for. A year? Fiver years? A Decade? Right now there's the pressure.
Well, there's more available than anybody else has suggested for any other project, AIUI, so I'm not apologetic for mentioning it.
As I said:
<quote> Right now we have a wave of "I hate Intel" going on and there's a wonderful marketing opportunity for Linux provided its not on Intel/AMD but *IS* packaged like a regular desktop/mobo and supported the way Ubuntu/Suse/Redhat... are with repositories, office, games ... and a neat GUI admin tool like YAST.
The window of opportunity is closing. A month from not many people will be saying "Oh, I have that patched" and "oh, I haven't been affected...". There won't be the interest or incentive. </quote>
There is an opportunity for Linux to take over, displace the Intel/Microsoft monopoly. But that's not going to happen with development boards that run one tenth the speed of current CPUs. A fabulous instruction set and great, "mature" compilers isn't going to displace Intel.
Now if those chips fitted AM2+, AM3/3+, AM4 LGA-H/H2, FM2/2+, the various server sockets ...
Yes, replacement would require some technical dexterity, but for new product there's a host of existing motherboards already in existence & production just waiting to be filled and shipped
As I said, there's ta window of opportunity for Linux to take over. It won't happen with a development board.
Putting up strawmen and then shooting them down is not very productive at the best of times, let alone in offtopic mails. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/03/2018 08:48 AM, Linda Walsh wrote:
Of course, Intel hasn't stepped up to say they'll replace the faulty chips, which seem to be related mostly to Intel-specific chip speedups not in other chips (like Intel's "speculative execution" feature that pre-executes multiple branches of a conditional ahead of knowing which branch will be taken). Intel has a history of offering replacing HW or compensation for their chips being hit by a 20% perf-penalty in the field.
Lovely... -l
Even if they *did* offer replacements, there would be a lot of machines that could not take advantage of the offer. In recent years, Intel's laptop chips are BGA (Bubble Grid Array), precision-soldered to the motherboard (a precision that cannot be done by humans, must be done by machine). In other words, you cannot switch out the CPUs in newer "Intel Inside" laptops. As an aside: I bought a new laptop with one of these new Intel mobile chips the other day, brought it home, fired it up and it ran like a dog at high noon in the desert. My 10+ year-old laptops all ran circles around it, even though it had quantum-more included Memory. No problem, I thought, I will get a faster CPU and switch it out ... until I looked it up only to learn about BGA. I started checking other Intel Laptops online to discover they were all BGA, then called a Senior Tech at my major Supplier, only to be told All Laptops with Intel are now BGA, as far as he knows. He said that the only way to change the CPU in them is to replace the complete motherboard. I did not know this, retired my business a few years ago so have not been looking inside new laptops for some time, now. Needless to say, laptop went back to the store. I am dusting off some of my 10-year-old laptops and reviving them. I like the superior speed these old beasts provide as well as the option to be able to replace the CPUs if they burn out. Sounds like Regression in CPUs rather than Progression, lately. -- -Gerry Makaro aka Fraser_Bell on the forums, IRC, and mail at openSUSE.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 4 Jan 2018 19:59:39 -0800 Fraser_Bell <Fraser_Bell@openSUSE.org> wrote:
I am dusting off some of my 10-year-old laptops and reviving them.
I like the superior speed these old beasts provide as well as the option to be able to replace the CPUs if they burn out.
I currently use a mixture of DDR2 and DDR3 Core 2 Duos and a couple of early Core i5 machines. With 8GB of RAM and an SSD, they're perfectly capable machines for all I need, able to drive 2 big screens each. And all cost under GBP 150 each.
Sounds like Regression in CPUs rather than Progression, lately.
Most of tech, really. ;-) -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I like the idea of an Open Source chip! <quote src=" http://www.zdnet.com/article/why-intel-x86-must-die-our-cloud-centric-future-depends-on-open-source-chips-meltdown/"> We need to stop thinking about microprocessor systems' architectures as these licensed things that are developed in secrecy by mega-companies like Intel or AMD or even ARM. Sun had the right idea ====================== In 2008, when I wrote the precursor to this article, the now-defunct Sun Microsystems -- whose intellectual property assets are owned today by Oracle -- decided to open-source a chip architecture, the OpenSPARC T2. The concept at the time did not exactly fly and didn't get any real takers. What has since happened to Sun in its absorption by Oracle has been less than pleasant for all the parties involved, and given the extremely litigious nature of the company, it is understandable why nobody has latched onto OpenSPARC. However, despite the history, I think Sun had the right idea at the time. We need to develop a modern equivalent of an OpenSPARC that any processor foundry can build upon without licensing of IP, in order to drive down the costs of building microprocessors at immense scale for the cloud, for mobile and the IoT. It makes the $200 smartphone as well as hyperscale datacenter lifecycle management that much more viable and cost-effective. Just as Linux and open source transformed how we view operating systems and application software, we need the equivalent for microprocessors in order to move out of the private datacenter rife with these legacy issues and into the green field of the cloud. We need to create something new =============================== Indeed, there are some risks, such as forking, which has been known to plague open-source systems -- but, more often than not, it creates an ecosystem of competition between the well-run communities and the bad ones. And, more often than not, the good ones emerge as the standards that get embraced. I cannot say definitively what architecture this new chip family needs to be based on. However, I don't see ARM donating its IP to this effort, and I think OpenSPARC may not be it either. Perhaps IBM POWER? It would certainly be a nice gesture of Big Blue, and it would help to maintain and establish the company's relevancy in the cloud going forward. The reality is that we now need to create something new, free from any legacy entities and baggage that has been driving the industry and dragging it down the past 40 years. Just as was done with Linux. </quote. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2018-01-05 at 07:41 -0500, Anton Aylward wrote:
I like the idea of an Open Source chip!
Me too. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpPf3IACgkQtTMYHG2NR9XIuwCgg+mTM+wrBZbbUje+vC/JaFj4 Yd8AnRSo/dJukNkDfRCXLToJ7+RhlSg+ =LRbP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 05/01/2018 à 14:36, Carlos E. R. a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday, 2018-01-05 at 07:41 -0500, Anton Aylward wrote:
I like the idea of an Open Source chip!
Me too.
zdnet also http://www.zdnet.com/article/why-intel-x86-must-die-our-cloud-centric-future... jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi, The advisories have just been published by the researchers. http://meltdownattack.com/ / https://spectreattack.com/ SUSE has been aware of these problems and we are in the process of preparing and soon releasing fixes. Ciao, Marcus On Wed, Jan 03, 2018 at 01:02:31PM +0100, Roger Oberholtzer wrote:
http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
-- Roger Oberholtzer
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real <meissner@suse.de> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/01/18 10:34, Marcus Meissner wrote:
Hi,
The advisories have just been published by the researchers.
http://meltdownattack.com/ / https://spectreattack.com/
SUSE has been aware of these problems and we are in the process of preparing and soon releasing fixes.
Ciao, Marcus
My take on this is that nobody with a Nvidia GPU will be installing the new kernel -- assuming that the 'fix' will be in the form of a new kernel -- until the problem with compiling the nIvidia driver under the
= 4.14.11 version is resolved.
BC -- Always be nice to people on your way up -- you'll see the same people on your way down. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
04.01.2018 09:55, Basil Chupin пишет:
On 04/01/18 10:34, Marcus Meissner wrote:
Hi,
The advisories have just been published by the researchers.
http://meltdownattack.com/ / https://spectreattack.com/
SUSE has been aware of these problems and we are in the process of preparing and soon releasing fixes.
Ciao, Marcus
My take on this is that nobody with a Nvidia GPU will be installing the new kernel -- assuming that the 'fix' will be in the form of a new kernel -- until the problem with compiling the nIvidia driver under the
= 4.14.11 version is resolved.
BC
And you point is? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/01/18 18:53, Andrei Borzenkov wrote:
04.01.2018 09:55, Basil Chupin пишет:
On 04/01/18 10:34, Marcus Meissner wrote:
Hi,
The advisories have just been published by the researchers.
http://meltdownattack.com/ / https://spectreattack.com/
SUSE has been aware of these problems and we are in the process of preparing and soon releasing fixes.
Ciao, Marcus My take on this is that nobody with a Nvidia GPU will be installing the new kernel -- assuming that the 'fix' will be in the form of a new kernel -- until the problem with compiling the nIvidia driver under the = 4.14.11 version is resolved. BC
And you point is?
Ce`? BC -- Always be nice to people on your way up -- you'll see the same people on your way down. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Jan 4, 2018 at 7:55 AM, Basil Chupin <blchupin@iinet.net.au> wrote:
My take on this is that nobody with a Nvidia GPU will be installing the new kernel -- assuming that the 'fix' will be in the form of a new kernel -- until the problem with compiling the nIvidia driver under the
= 4.14.11 version is resolved.
We have stayed with the nouveau driver, so I guess a new kernel will be possible. For Leap 42.3, will the patch be applied to the 4.4.92 kernel? At least that is what I have installed. My bigger concern is the speed penalty. Our applications are very network and I/O bound (meaning lots of system calls). I wonder what the effect will be. There were mentions of up to a 10% speed penalty. I hope our use does not suffer that. My own computer has an AMD CPU. I guess it is not effected. But our production systems are all intel. We're just waiting for the list of effected CPU models to be released. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/01/18 07:55, Roger Oberholtzer wrote:
My bigger concern is the speed penalty. Our applications are very network and I/O bound (meaning lots of system calls). I wonder what the effect will be. There were mentions of up to a 10% speed penalty. I hope our use does not suffer that.
You could suffer worse ... TYPICAL slowdown is supposed to be about 5%. Worst case is nearer 30% I believe ... Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/04/2018 01:45 PM, Wol's lists wrote:
On 04/01/18 07:55, Roger Oberholtzer wrote:
My bigger concern is the speed penalty. Our applications are very network and I/O bound (meaning lots of system calls). I wonder what the effect will be. There were mentions of up to a 10% speed penalty. I hope our use does not suffer that.
You could suffer worse ... TYPICAL slowdown is supposed to be about 5%. Worst case is nearer 30% I believe ...
I see there's a couple of software updates available now, kernel-firmware and microcode updates for AMD CPUs. Would these have anything to do with this problem. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/04/2018 01:50 PM, James Knott wrote:
You could suffer worse ... TYPICAL slowdown is supposed to be about
5%. Worst case is nearer 30% I believe ... I see there's a couple of software updates available now, kernel-firmware and microcode updates for AMD CPUs. Would these have anything to do with this problem.
It appears they do. Here's what the patch description says: "openSUSE-2018-1 - Security update for kernel-firmware This update for kernel-firmware fixes the following issues: - Add microcode_amd_fam17h.bin (bsc#1068032 CVE-2017-5715) This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715)." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 04.01.2018 um 19:52 schrieb James Knott:
On 01/04/2018 01:50 PM, James Knott wrote:
You could suffer worse ... TYPICAL slowdown is supposed to be about
5%. Worst case is nearer 30% I believe ... I see there's a couple of software updates available now, kernel-firmware and microcode updates for AMD CPUs. Would these have anything to do with this problem.
It appears they do. Here's what the patch description says:
"openSUSE-2018-1 - Security update for kernel-firmware
This update for kernel-firmware fixes the following issues: - Add microcode_amd_fam17h.bin (bsc#1068032 CVE-2017-5715) This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715)."
So with intel this doesn't help and must not be installed? -- Daniel Bauer photographer Basel Barcelona https://www.patreon.com/danielbauer http://www.daniel-bauer.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Jan 04, 2018 at 08:12:53PM +0100, Daniel Bauer wrote:
Am 04.01.2018 um 19:52 schrieb James Knott:
On 01/04/2018 01:50 PM, James Knott wrote:
You could suffer worse ... TYPICAL slowdown is supposed to be about
5%. Worst case is nearer 30% I believe ... I see there's a couple of software updates available now, kernel-firmware and microcode updates for AMD CPUs. Would these have anything to do with this problem.
It appears they do. Here's what the patch description says:
"openSUSE-2018-1 - Security update for kernel-firmware
This update for kernel-firmware fixes the following issues: - Add microcode_amd_fam17h.bin (bsc#1068032 CVE-2017-5715) This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715)."
So with intel this doesn't help and must not be installed?
For Intel the update is "ucode-intel". it is just part of the fix, the kernel update is needed to implement it. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 04.01.2018 um 21:25 schrieb Marcus Meissner: ...
It appears they do. Here's what the patch description says:
"openSUSE-2018-1 - Security update for kernel-firmware
...
So with intel this doesn't help and must not be installed?
For Intel the update is "ucode-intel".
it is just part of the fix, the kernel update is needed to implement it.
Thanks Marcus! So with installing Kernel 4.4.104-39-default and ucode-intel installed with latest zypper up on OS 42.3 I have done what I should? Sorry for stupid question... these things are far beyond of my horizon of knowledge... Daniel -- Daniel Bauer photographer Basel Barcelona https://www.patreon.com/danielbauer http://www.daniel-bauer.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Jan 05, 2018 at 11:47:33AM +0100, Daniel Bauer wrote:
Am 04.01.2018 um 21:25 schrieb Marcus Meissner: ...
It appears they do. Here's what the patch description says:
"openSUSE-2018-1 - Security update for kernel-firmware
...
So with intel this doesn't help and must not be installed?
For Intel the update is "ucode-intel".
it is just part of the fix, the kernel update is needed to implement it.
Thanks Marcus!
So with installing Kernel 4.4.104-39-default and ucode-intel installed with latest zypper up on OS 42.3 I have done what I should?
Sorry for stupid question... these things are far beyond of my horizon of knowledge...
Variant 3 aka Meltdown is fixed with the update due to "PTI" being enabled and deployed. Variant 1 of Spectre has a lot of fixes applied to the kernel, so should be mostly fixed for the kernel. Variant 2 of Spectre needs the ucode-intel package, and is partially fixed, as we only mitigated Haswell-X, Broadwell-X and Skylake-X with the ucode and kernel update so far. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/04/2018 01:55 AM, Basil Chupin wrote:
On 04/01/18 10:34, Marcus Meissner wrote:
Hi,
The advisories have just been published by the researchers.
http://meltdownattack.com/ / https://spectreattack.com/
SUSE has been aware of these problems and we are in the process of preparing and soon releasing fixes.
Ciao, Marcus
My take on this is that nobody with a Nvidia GPU will be installing the new kernel -- assuming that the 'fix' will be in the form of a new kernel -- until the problem with compiling the nIvidia driver under the
= 4.14.11 version is resolved.
BC
This is all it takes to build on 4.14 kernels: int __init nv_drm_init( struct pci_driver *pci_driver ) { int ret = 0; #if defined(NV_DRM_AVAILABLE) #if LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 0) ret = drm_pci_init(&nv_drm_driver, pci_driver); #else ret = drm_legacy_pci_init(&nv_drm_driver, pci_driver); #endif #endif return ret; } void nv_drm_exit( struct pci_driver *pci_driver ) { #if defined(NV_DRM_AVAILABLE) #if LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 0) drm_pci_exit(&nv_drm_driver, pci_driver); #else drm_legacy_pci_exit(&nv_drm_driver, pci_driver); #endif #endif } Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/01/18 23:02, Roger Oberholtzer wrote:
http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
Or is it a 'backdoor' which has been discovered only now? BC -- Always be nice to people on your way up -- you'll see the same people on your way down. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2018-01-04 at 17:30 +1100, Basil Chupin wrote:
On 03/01/18 23:02, Roger Oberholtzer wrote:
http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
Or is it a 'backdoor' which has been discovered only now?
Second person I see asking that ;-) I doubt it. A backdoor is done subtly, and you need to control it (meaning you need to protect yourself, enable/disable at will). This thing affects all computers, even those on "your" side. So yes, you may attack others, and they can attack you back. You can not be sure the bad guys and intelligence agencies don't find about about this. There is no way you can secure your own computer, you need a redesign of the kernel in a way that affects speed: not something you want for yourself. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpOI7cACgkQtTMYHG2NR9WibQCdHBatvcyWQC6JMKzhUE95f84G SZoAmwWtWf+z0uBbo7UcLE1CRAWPSonn =KZe/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
an interesting statement from Intel: https://newsroom.intel.com/news/intel-responds-to-security-research-findings... On 01/04/2018 01:53 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2018-01-04 at 17:30 +1100, Basil Chupin wrote:
On 03/01/18 23:02, Roger Oberholtzer wrote:
http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
Or is it a 'backdoor' which has been discovered only now?
Second person I see asking that ;-)
I doubt it. A backdoor is done subtly, and you need to control it (meaning you need to protect yourself, enable/disable at will).
This thing affects all computers, even those on "your" side. So yes, you may attack others, and they can attack you back. You can not be sure the bad guys and intelligence agencies don't find about about this. There is no way you can secure your own computer, you need a redesign of the kernel in a way that affects speed: not something you want for yourself.
- -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iEYEARECAAYFAlpOI7cACgkQtTMYHG2NR9WibQCdHBatvcyWQC6JMKzhUE95f84G SZoAmwWtWf+z0uBbo7UcLE1CRAWPSonn =KZe/ -----END PGP SIGNATURE-----
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2018-01-04 at 18:19 +0100, ArnoB wrote:
an interesting statement from Intel: https://newsroom.intel.com/news/intel-responds-to-security-research-findings...
"Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data." No? <https://hardzone.es/2018/01/03/demuestran-fallo-seguridad-intel/> (Spanish) How easy is to do an exploit proof. Some more links: <https://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/> We translated Intel's crap attempt to spin its way out of CPU security bug PR nightmare As Linus Torvalds lets rip on Chipzilla (Skipping: Spanish link on what Linus Torvalds said, not nicely) <https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr> Speculative Execution and Indirect Branch Prediction Side Channel Analysis Method <https://meltdownattack.com/> Meltdown and Spectre Bugs in modern computers leak passwords and sensitive data. <https://www.profesionalreview.com/2018/01/04/intel-lanza-una-herramienta-saber-equipo-vulnerable/> Intel launches a tool to find if a processor is affected. Spanish. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpOsA0ACgkQtTMYHG2NR9X0zACfdOEZ/PHvWlOh9CxgXVf1SAqD bQkAn22snnKtjWKx3IeyD1VUYul3KBYM =fIJd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (29)
-
Andrei Borzenkov -
Anton Aylward -
ArnoB -
Basil Chupin -
Carlos E. R. -
Christopher Myers -
Daniel Bauer -
Dave Howorth -
David C. Rankin -
David T-G -
Fraser_Bell -
Greg Freemyer -
James Knott -
jdd＠dodin.org -
Jeffrey L. Taylor -
John Andersen -
Larry Stotler -
Lew Wolfgang -
Liam Proven -
Linda Walsh -
Marcus Meissner -
Mark Hounschell -
Markus Koßmann -
Patrick Shanahan -
Per Jessen -
Roger Oberholtzer -
Wol's lists -
Wols Lists
-
Yamaban