On Sat, Jan 06, 2018 at 01:41:38AM -0500, Michael wrote:
> R10k had all sorts of weirdo speculative execution related problems
> ( see hardware workarounds in the O2 ), and I doubt it's the first to
> implement it.
Loongson-2 had an issue where from branch prediction it would prefetch
>> "Possibly more"? Anything that does speculative execution needs a
>> good hard look, and that's damn near everything these days.
> I wonder about just "these days". The potential for this kind of
> problem goes all the way back to STRETCH or the 6600, doesn't it?
I don't know; I don't know
On Thu, Jan 04, 2018 at 04:58:30PM -0500, Mouse wrote:
> > As I understand it, on intel cpus and possibly more, we'll need to
> > unmap the kernel on userret, or else userland can read arbitrary
> > kernel memory.
>
> "Possibly more"? Anything that does speculative execution needs a good
> hard
> I think you are confusing spectre and meltdown.
Yes, my apologies.
--Tery
> On Jan 4, 2018, at 6:01 PM, Warner Losh wrote:
>
>
>
> On Thu, Jan 4, 2018 at 2:58 PM, Mouse wrote:
> > As I understand it, on intel cpus and possibly more, we'll need to
> > unmap the kernel on userret, or else userland can read arbitrary
> >
If there's anything this issue showed is that we definitely need fewer
people independently considering the issue and openly discussing their
own (occasionally wrong) suggestions.
It was just a suggestion, I'm not a source of authority.
Taylor R Campbell wrote:
> > Date: Tue, 28 Mar 2017 16:58:58 +0200
> > From: Maxime Villard
> >
> > Having read several papers on the exploitation of cache latency to defeat
> > aslr (kernel or not), it appears that disabling the rdtsc instruction is a
> > good mitigation on
On Jan 4, 2018, at 15:22, Phil Nelson wrote:
> How about turning on the workaround for any process that ignores
> or catches SEGV.Any process that is terminated by a SEGV should
> be safe, shouldn't it?
Isn't there a suggested mitigation? Seems to me NetBSD should
On Thursday 04 January 2018 12:49:22 m...@netbsd.org wrote:
> I wonder if we can count the number of SEGVs and if we get a few, turn
> on the workaround?
How about turning on the workaround for any process that ignores
or catches SEGV.Any process that is terminated by a SEGV should
be safe,