lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 1 Sep 2018 18:13:31 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Juergen Gross <jgross@...e.com>
Cc:     Jiri Kosina <jikos@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>
Subject: Re: Access to non-RAM pages

On Sat, Sep 01, 2018 at 12:47:48PM +0200, Juergen Gross wrote:
> On 31/08/18 23:18, Jiri Kosina wrote:
> > On Wed, 29 Aug 2018, Juergen Gross wrote:
> > 
> >> While being very unlikely I still believe this is possible. Any
> >> thoughts?
> > 
> > So in theory we should somehow test whether the next page is some form of 
> > mmio/gart/... mapping, but I guess that by itself would kill the 
> > performance advantage of the whole load_unaligned_zeropad() trick.
> > 
> > And yes, the sideffects of reading from mmio mapping is a real thing -- 
> > see for example the issue fixed by 2a3e83c6f9.
> > 
> > If noone has any clever idea how to work this around (I don't), I am 
> > afraid we'd have to ditch the whole DCACHE_WORD_ACCESS optimization, as 
> > it's silently dangerous.
> 
> Are there any architectures which can still use DCACHE_WORD_ACCESS?
> 
> x86 shouldn't, what about powerpc, arm and arm64?

IMO that's crap.  In absolute majority of cases there is a guaranteed gap
between the end of accessed object and the next page boundary.  Penalizing
each syscall that does pathname resolution to deal with something that
might only happen when the pathname length is just under 4Kb looks like
a bloody bad idea.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ