Additionally, why skipping -current entirely:
- GCC 7.3 already has an official backport, and we might update to this.
- I'm not good at compilers
p.s. for people who desperately want -current patches, we can still use
GCC 5.5 on current with HAVE_GCC=5.
sorry for being terse, I'm not very knowledgeable about GCC/x86 but
applied it to our copy of GCC.
what it should be adding
Add -mindirect-branch-register to force indirect branch via register.
This is implemented by disabling patterns of indirect branch via memory,
similar to TARGET_X32.
https:/
Hi,
I've done the following, hopefully it will enable others.
Completed:
- Builds amd64 tools
- Builds working amd64 kernel (*without new mitigations*!)
Need:
- Test full release, stress test
- Test i386 too
- Decide which spectre mitigation to use
- Test that kernel with that mitigation
Hello,
On Fri, 19 Jan 2018 21:55:12 +
wrote:
> > On Jan 19, 2018, at 4:47 PM, wrote:
> >
> > Hi folks.
> >
> > I think that the spectre variant 2 situation is a lot worse for:
> > - Speculative CPU
> > - Weak memory protection
&g
> On Jan 19, 2018, at 4:47 PM, wrote:
>
> Hi folks.
>
> I think that the spectre variant 2 situation is a lot worse for:
> - Speculative CPU
> - Weak memory protection
>
> Then I don't need a JIT for gadgets.
>
> Architectures that fall into this:
Spectre variant 2 also relies on me being able to poison the branch
target buffer. loongson had a similar issue where errant BTB entries
would cause hangs, and they then claimed this at kernel entry clears
out their BTB:*
jal 1f
nop
1: jal 1f
Hi folks.
I think that the spectre variant 2 situation is a lot worse for:
- Speculative CPU
- Weak memory protection
Then I don't need a JIT for gadgets.
Architectures that fall into this:
- default i386 netbsd, because it is missing NX bit (PAE is optional)
- MIPS for us, because we don&
m...@netbsd.org wrote:
> Considering JITs are a much bigger risk, and how cheap this suggestion
> is, should we use lfence / similar for other architectures within sljit
> (and possibly lua)?
While everyone seems to be concerned on negative performance impact
of Spectre, I recently
Considering JITs are a much bigger risk, and how cheap this suggestion
is, should we use lfence / similar for other architectures within sljit
(and possibly lua)?
The slides also talk about adding rules to detect likely gadgets to
coverity. I wonder whether they can be added also to static analyze
> On Jan 18, 2018, at 10:31 AM, Mouse wrote:
>
>> ...
>
>> The Spectre fixes all amount to a speculative barrier, which will do
>> the job just as well (though it requires code change).
>
> Yes...but it requires a code change in the wrong place.
>
> Th
ngs
care too much about performance.
But I do think it is a good thing to have available. Sandboxes, for
example, might want to do so when executing sandboxed code. (Might.
Not, of course, always will; see also below.)
> The Spectre fixes all amount to a speculative barrier, which will do
&g
g.
> >
> > To my mind, the bug here is that annulling spec ex doesn't annul _all_
> > its effects. That, fundamentally, is what's behind both spectre and
> > meltdown. In meltdown it's exacerbated by spec ex's failure to check
> > permissions fully
t's the same fundamental hardware bug as meltdown, but
> not compounded by an additional hardware property (which I'm not sure I
> would call a bug) which is made much worse by the actual bug.
>
> To my mind, the bug here is that annulling spec ex doesn't annul _all_
>
y an additional hardware property (which I'm not sure I
would call a bug) which is made much worse by the actual bug.
To my mind, the bug here is that annulling spec ex doesn't annul _all_
its effects. That, fundamentally, is what's behind both spectre and
meltdown. In meltdown i
> Consider something like BPF [...]
Yes, that's the "on the one hand" part: using this property to read
outside a sandbox.
> -- code executed in the kernel with an enforced security model to
> prevent "undesirable" acceses.
Such CPUs are inappropriate for such uses.
Whether that's a bug in the
ointer speculatively results in a visible side effect that
> defeats in part the access check. In short, it can effectively invert
> access control checks for verified code.
Yes, you've just described Spectre. Since this involves a speculative
load that is legal from the hardware definition
On Wed, Jan 17, 2018 at 09:38:27PM -0500, Mouse wrote:
> But, on the other hand, I can easily imagine a CPU designer looking at
> it and saying "What's the big deal if this code can read that location?
> It can get it anytime it wants with a simple load instruction anyway.",
> something I have trou
It's a lot less obvious from a CPU designer perspective. One will make
the speculative bits, declare 'all the actions I do are rolled back, so
this is perfectly safe!' and someone else making the cache doesn't
realize that the reads were speculative and their effects should have
been rolled back.
> Spectre is unrelated and does not depend on a mistake of this kind,
> since there you're dealing with speculative loads that ARE permitted
> as far as access control goes; they just aren't wanted because they
> are preceded by range checks or the like.
Yes. I'm of
On Thu, Jan 18, 2018 at 12:37:11AM +, co...@sdf.org wrote:
> - Variant 1 seems possible to avoid with low cost. It will likely result
> in an error somewhere along the line, which is detectable. Flushing
> the entire cache on userret will make it hard to exploit. Do all
> bound checks fai
On Wed, Jan 17, 2018 at 08:08:06PM -0500, Mouse wrote:
> Unfortunately, they appear to be exported only on the Web, and even
> then only over HTTPS. I can send copies privately to anyone for whom
> those are obstacles (probably not very many, but they were for me).
> https://spectreattack.com/ and
h time the speculatively loaded data is in the cache and some
other operations may be done based on it.
Obviously, if speculative loads check permissions prior to launching
the load, the issue goes away. If so, Meltdown is completely
prevented.
Spectre is unrelated and does not depend on a mistak
>
I'd suggest reading the papers describing spectre and meltdown. They
are fairly readable - I would expect anyone working on the NetBSD
kernel to be competent to understand them - and they describe the
vulnerabilities, and how the authors exploited them, in reasonable
detail.
Unfor
On Thu, Jan 18, 2018 at 12:37:11AM +, co...@sdf.org wrote:
> - Intel and AMD have pushed microcode updates that introduce
> instructions, for Intel they are 'IBPB' and 'IBRS'.
+ STIBP for Intel.
> - I'm not sure how easy it is to find a good enough gadget without
> something like eBPF
Lu
Hi folks.
Spectre is also a vulnerability. It's been discussed in the context of
web browsers, but it does have repercussions for kernel.
The gist of it seems to be, if you have code that looks like this:
Variant 1:
if (malicious offset is safe)
value = array[malicious_offset];
v
25 matches
Mail list logo
