Hello,
On Sat, 6 Jan 2018 07:33:50 +
m...@netbsd.org wrote:
> Loongson-2 had an issue where from branch prediction it would prefetch
> instructions from the I/O area and deadlock.
>
> This happened in normal usage so we build the kernel with a binutils
> flag to output different jumps and fl
> On Jan 5, 2018, at 8:55 PM, Thor Lancelot Simon wrote:
>
> 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 mor
>> Though of course "fail early" is an obvious principle to security
>> types, given the cost of aborting work in progress I can easily see
>> the opposite being true for CPU designers (I'm not one, so I don't
>> really know). Which idiom (check permissions, then speculate /
>> speculate, then che
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
instructions
Hello,
On Fri, 5 Jan 2018 20:55:19 -0500
Thor Lancelot Simon wrote:
> 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 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 en
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 l
On Jan 5, 2018, at 8:52 AM, wrote:
> so the illegal read is also speculative, and is voided (exception
> and all) when the wrong branch prediction is sorted out. But it
> looks like the paper is saying that refinement has not been
> demonstrated, though such branch prediction hacks have been show
> 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
> > kernel memory.
>
> "Possibly more"? Anything
> 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.
Actually, it seems to me we need more. More minds looking at it, more
discussion of the various ramifications a
On Fri, Jan 05, 2018 at 02:48:11AM -0600, Dave Huang wrote:
> 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 sugg
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.
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 implement
it as suggested,
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, s
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
> > kernel memory.
>
> "Possibly more"? Anything that does speculative execution needs a good
> hard look, and
> 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.
>
> People seem to be mentioning a 50% performance penalty and we might do
> worse (we don't have vDSOs...)
I suggest sticking to the original pa
> On Jan 4, 2018, at 4: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
>> kernel memory.
>
> "Possibly more"? Anything that does speculative execution needs a good
> hard look, and
> 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 look, and that's damn near everything these days.
> Also, I underst
On Thu, Jan 04, 2018 at 10:01:34PM +0100, Kamil Rytarowski wrote:
> We have: PaX Segvguard. Can we mitigate it with this feature?
>
that's what gave me the idea, but I think segvguard is per-binary, and I
could just make new binaries to keep on attacking the kernel.
On 04.01.2018 21:49, m...@netbsd.org wrote:
> Also, I understand that to exploit this, one has to attempt to access
> kernel memory a lot, and SEGV at least once per bit.
>
> I wonder if we can count the number of SEGVs and if we get a few, turn
> on the workaround? that would at least spare us th
21 matches
Mail list logo
