On January 13, 2018 10:26:00 AM HST, Ralf Mardorf <ralf.mardorf@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@gnu.org> wrote:
> >
> >>Ralf Mardorf <ralf.mardorf-ZCLZIpdjs0kJGwgDXS7ZQA@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:
-- David W. Jones gnome@hawaii.rr.com authenticity, honesty, community http://dancingtreefrog.com Sent from my Android device with K-9 Mail. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-userReceived on Sun Jan 14 00:15:02 2018
This archive was generated by hypermail 2.1.8 : Sun Jan 14 2018 - 00:15:02 EET