Re: Spectre

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.

Re: Spectre

> 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 two minds whether it's even

Re: Spectre

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

Re: /dev/ksyms permissions

On Wed, Jan 17, 2018 at 07:19:32PM +0100, Anders Magnusson wrote: > libkvm uses it to get the kernel symbol namelist instead of reading /netbsd > for it (originally kvmdb, which was retired when ksyms was added). > Programs like ps, netstat etc... uses it to find in-kernel stuff, so you > cannot

Re: Spectre

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/

Re: Spectre

> On Jan 17, 2018, at 8:08 PM, Mouse wrote: > > ... >> - Even speculative execution obeys access restrictions, > > In some respects. Meltdown is possible because Intel spec ex does not > obey access restrictions in one particular respect; I don't know what >

Re: Spectre

> 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. Unfortunately,

Re: Spectre

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

Spectre

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]; value2 =

Re: amd64: kernel aslr support

On Wed, Jan 17, 2018 at 08:01:19AM +0100, Maxime Villard wrote: > Or, you can dump the location of the segments by loading a kernel module > that calls the following function ... > It will give you the addresses of the pages containing the kernel sections. > Note however that the sections may not

Re: /dev/ksyms permissions

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 privileges when calling ksyms read routines. I

Re: /dev/ksyms permissions

>>> 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 privileges when calling ksyms read > routines. I don't see why not - or, at

Re: /dev/ksyms permissions

Den 2018-01-17 kl. 20:03, 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 privileges when calling ksyms read routines.

Re: /dev/ksyms permissions

> libkvm uses it to get the kernel symbol namelist instead of reading > /netbsd for it (originally kvmdb, which was retired when ksyms was > added). Programs like ps, netstat etc... uses it to find in-kernel > stuff, so you cannot change it to require root privs to be read. But the symbol values

Re: /dev/ksyms permissions

In article <20180117152524.ga11...@sdf.org>, wrote: >-=-=-=-=-=- > >This leaks information that unprivileged user probably has no reason to >own: > >> cat /dev/ksyms > ksyms >> readelf -a ksyms |wc -l > 47594 > >Any strong reason not to apply the following? >Presumably it will

Re: /dev/ksyms permissions

libkvm uses it to get the kernel symbol namelist instead of reading /netbsd for it (originally kvmdb, which was retired when ksyms was added). Programs like ps, netstat etc... uses it to find in-kernel stuff, so you cannot change it to require root privs to be read. Maybe group kmem read, but

/dev/ksyms permissions

This leaks information that unprivileged user probably has no reason to own: > cat /dev/ksyms > ksyms > readelf -a ksyms |wc -l 47594 Any strong reason not to apply the following? Presumably it will have benefits for GENERIC_KASLR, or people with Intel CPUs :-) Index: MAKEDEV.tmpl