Re: meltdown

2018-01-05 Thread maya
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

Re: meltdown

2018-01-05 Thread Mouse
>> "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

Re: meltdown

2018-01-05 Thread Thor Lancelot Simon
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

RE: meltdown

2018-01-05 Thread Terry Moore
> I think you are confusing spectre and meltdown. Yes, my apologies. --Tery

Re: meltdown

2018-01-05 Thread Paul.Koning
> 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 > >

Re: meltdown

2018-01-05 Thread maya
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.

Re: Restricting rdtsc [was: kernel aslr]

2018-01-05 Thread Alexander Nasonov
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

Re: meltdown

2018-01-05 Thread Dave Huang
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

Re: meltdown

2018-01-05 Thread Phil Nelson
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,