[LAU] Meltdown – Spectre

David W. Jones gnome at hawaii.rr.com
Sat Jan 13 21:33:00 UTC 2018



On January 13, 2018 10:26:00 AM HST, Ralf Mardorf <ralf.mardorf at alice-dsl.net> 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 at gnu.org> wrote:
> >
> >>Ralf Mardorf <ralf.mardorf-ZCLZIpdjs0kJGwgDXS7ZQA at public.gmane.org>
> >>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 at hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com

Sent from my Android device with K-9 Mail.


More information about the Linux-audio-user mailing list