linux-kernel - Re: [PATCH v2] powerpc: slightly improve cache helpers

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]

Message-ID: <20190722024140.GA55142@archlinux-threadripper>
Date:   Sun, 21 Jul 2019 19:41:40 -0700
From:   Nathan Chancellor <natechancellor@...il.com>
To:     Segher Boessenkool <segher@...nel.crashing.org>
Cc:     Christophe Leroy <christophe.leroy@....fr>,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        clang-built-linux@...glegroups.com
Subject: Re: [PATCH v2] powerpc: slightly improve cache helpers

Hi Segher,

On Sun, Jul 21, 2019 at 01:01:50PM -0500, Segher Boessenkool wrote:
> On Sun, Jul 21, 2019 at 12:58:46AM -0700, Nathan Chancellor wrote:
> > I have attached the disassembly of arch/powerpc/kernel/mem.o with
> > clear_page (working) and broken_clear_page (broken), along with the side
> > by side diff. My assembly knowledge is fairly limited as it stands and
> > it is certainly not up to snuff on PowerPC so I have no idea what I am
> > looking for. Please let me know if anything immediately looks off or if
> > there is anything else I can do to help out.
> 
> You might want to use a disassembler that shows most simplified mnemonics,
> and you crucially should show the relocations.  "objdump -dr" works nicely.

Copy, those are attached below if you want to take a further look at
them.

> > 0000017c clear_user_page:
> >      17c: 38 80 00 80                  	li 4, 128
> >      180: 7c 89 03 a6                  	mtctr 4
> >      184: 7c 00 1f ec                  	dcbz 0, 3
> >      188: 38 63 00 20                  	addi 3, 3, 32
> >      18c: 42 00 ff f8                  	bdnz .+65528
> 
> That offset is incorrectly disassembled, btw (it's a signed field, not
> unsigned).
> 
> > 0000017c clear_user_page:
> >      17c: 94 21 ff f0                  	stwu 1, -16(1)
> >      180: 38 80 00 80                  	li 4, 128
> >      184: 38 63 ff e0                  	addi 3, 3, -32
> >      188: 7c 89 03 a6                  	mtctr 4
> >      18c: 38 81 00 0f                  	addi 4, 1, 15
> >      190: 8c c3 00 20                  	lbzu 6, 32(3)
> >      194: 98 c1 00 0f                  	stb 6, 15(1)
> >      198: 7c 00 27 ec                  	dcbz 0, 4
> >      19c: 42 00 ff f4                  	bdnz .+65524
> 
> Uh, yeah, well, I have no idea what clang tried here, but that won't
> work.  It's copying a byte from each target cache line to the stack,
> and then does clears the cache line containing that byte on the stack.
> 
> I *guess* this is about "Z" and not about "%y", but you'll have to ask
> the clang people.
> 
> Or it may be that they do not treat inline asm operands as lvalues
> properly?  That rings some bells.  Yeah that looks like it.
> 
> 
> Segher

Okay, I think I understand... I think this is enough to bring up an LLVM
bug report but I'll ask some of the LLVM folks I know before doing so.

Thank you for all of the input, I really appreciate it,
Nathan

View attachment "mem-working.txt" of type "text/plain" (19428 bytes)

View attachment "mem-broken.txt" of type "text/plain" (19642 bytes)

View attachment "mem-diff.txt" of type "text/plain" (40266 bytes)