On January 13, 2018 10:26:00 AM HST, Ralf Mardorf <ralf.mardorf@xxxxxxxxxxxxx> wrote: > On Sat, 13 Jan 2018 20:02:28 +0000, Will Godfrey wrote: > >On Sat, 13 Jan 2018 20:52:36 +0100 > >David Kastrup <dak@xxxxxxx> wrote: > > > >>Ralf Mardorf <ralf.mardorf-ZCLZIpdjs0kJGwgDXS7ZQA@xxxxxxxxxxxxxxxx> > >>writes: > >> > >>> On Sat, 13 Jan 2018 15:29:27 +0000, Pablo Fernandez wrote: > >>>>El sáb., 13 ene. 2018 13:58, Thomas Pfundt escribió: > >>>>> However, this site doesn't list your Celeron G as vulnerable: > >>>>> > https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr > >>>>> Do you even need to concern with the patch and performance at > this > >>>>> point? > >>> > >>> That is interesting news. I'll forward this, since actually it's > >>> claimed that all x86 CPUs since the Pentium Pro from 1995 suffer > >>> from this issue. > >>> > >>> Does anybody know how to value this information from Intel? > >> > >>The vulnerability is speculative execution in connection with memory > >>fetch. Basically, you make a conditional indirect branch via the > >>location you want to read out with the condition being later figured > >>out as false. The execution is abandoned at that time, but the > >>indirect branch has invalidated previous contents of the cache > >>depending on the abandoned target. Now you use timing registers in > >>connection with accesses in order to figure out just where the cache > >>is no longer valid. > >> > >>Since kernel and user processes generally share the same virtual > >>address space for efficiency reasons (though obviously not the same > >>permissions)... > >> > >>Basically, I'd be surprised about exceptions. > >> > > > >Bearing in mind Intel's past behaviour > > Hi, > > I'm not aware of Intel's past behaviour, since I was an unsatisfied > AMD > user. Now with my first Intel based machine I'm still satisfied, but > since a few weeks I'm uncertain. For some usage I need security, for > other usage I need performance. I could separate both desires, but one > link claims I could disable a patch set using "nopti" and one > changelog > claims I could disable a patch set using "nokasier" and that is just > about meltdown, not about spectre, let alone the third nameless > vulnerability ... or does Meltdown and/or Spectre cover the third > thingy, too? > > >I regard missing entries in that list as simply meaning those CPUs > >have not been tested, not that they in the clear. > and never will be tested, since they are discontinued or > something like this ;) > > That is my guess, too, since they formally mentioned "For non-Intel > based systems please contact your system manufacturer or > microprocessor > vendor (AMD, ARM, Qualcomm, etc.) for updates." To me that sounds much > like an insincerely "we're all in the same boat" statement, while CPUs > from other vendors might be a little bit vulnerable, too, seemingly > only Intel suffers from a disaster. > > IOW you confirmed my worries. Well, for those who might be open to this, here's a hands-on experience re the Intel Meltdown/Spectre patches and performance: https://www.pcworld.com/article/3247847/computers/heres-how-much-the-meltdown-and-spectre-fix-hurt-my-surface-book-performance.html -- David W. Jones gnome@xxxxxxxxxxxxx authenticity, honesty, community http://dancingtreefrog.com Sent from my Android device with K-9 Mail. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx https://lists.linuxaudio.org/listinfo/linux-audio-user
