Re: Spectre

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 worked on

Re: Spectre

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

Re: Spectre

> 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. > > That "if

Re: Spectre

> It seems to me that blocking all observable side effects of > speculative execution can probably only be done by disabling > speculative execution outright. Hmm. Probably. > That clearly isn't a good thing. I agree it would not be a good thing to do globally. Too many things care too much

Re: Spectre

On Thu, Jan 18, 2018 at 7:58 AM, wrote: > > > > On Jan 18, 2018, at 9:48 AM, Mouse wrote: > > > >> Since this involves a speculative load that is legal from the > >> hardware definition point of view (the load is done by kernel code), > >> this

Re: Spectre

> On Jan 18, 2018, at 9:48 AM, Mouse wrote: > >> Since this involves a speculative load that is legal from the >> hardware definition point of view (the load is done by kernel code), >> this isn't a hardware bug the way Meltdown is. > > Well, I'd say it's the same

Re: Spectre

> Since this involves a speculative load that is legal from the > hardware definition point of view (the load is done by kernel code), > this isn't a hardware bug the way Meltdown is. Well, I'd say it's the same fundamental hardware bug as meltdown, but not compounded by an additional hardware

Re: Spectre

> 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

Re: Spectre

> On Jan 18, 2018, at 8:49 AM, Joerg Sonnenberger wrote: > > 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

Re: Spectre

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

Re: /dev/ksyms permissions

Maxime Villard writes: > Well, looking at the code, it seems to me that _kvm_open() should be > changed to keep /dev/ksyms open, the same way it keeps /dev/kmem open. Agreed. This works fine for me, with and without /dev/ksyms present: Index: lib/libkvm/kvm.c

Re: mutex vs turnstile

On 01/09/18 03:30, Mateusz Guzik wrote: Some time ago I wrote about performance problems when doing high -j build.sh and made few remarks about mutex implementation. TL;DR for that one was mostly that cas returns the found value, so explicit re-reads can be avoided. There are also avoidable

Re: /dev/ksyms permissions

Le 18/01/2018 à 11:03, Tom Ivar Helbekkmo a écrit : Maxime Villard writes: So, making /dev/ksyms 440 root:kmem should not break anything. If it does, then there's a bug in the offending tool in the first place. Agreed. systat is one of them. It takes care to call

Re: /dev/ksyms permissions

Maxime Villard writes: > So, making /dev/ksyms 440 root:kmem should not break anything. > > If it does, then there's a bug in the offending tool in the first place. Agreed. systat is one of them. It takes care to call kvm_openfiles() while setgid kmem, but kvm_openfiles()

Re: /dev/ksyms permissions

Le 17/01/2018 à 21:43, Anders Magnusson a écrit : Den 2018-01-17 kl. 20:20, skrev Mouse: Maybe group kmem read, but that might require more elevated privileges in the programs that uses ksyms. What program uses ksyms now that doesn't require at least group kmem? You cannot give up kmem read