linux-kernel - Re: [PATCH 3/3] riscv: fix __user annotation for __copy

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:   Tue, 12 Jun 2018 10:12:08 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...ive.com>
To:     luc.vanoostenryck@...il.com
CC:     atish.patra@....com, linux-riscv@...ts.infradead.org,
        linux-kernel@...r.kernel.org, albert@...ive.com
Subject:     Re: [PATCH 3/3] riscv: fix __user annotation for __copy_user()

On Mon, 11 Jun 2018 20:00:08 PDT (-0700), luc.vanoostenryck@...il.com wrote:
> On Mon, Jun 11, 2018 at 12:01:37PM -0700, Palmer Dabbelt wrote:
>> On Sat, 09 Jun 2018 14:42:12 PDT (-0700), luc.vanoostenryck@...il.com wrote:
>> > On Sat, Jun 09, 2018 at 01:00:08PM -0700, Palmer Dabbelt wrote:
>> > > On Fri, 08 Jun 2018 17:13:12 PDT (-0700), luc.vanoostenryck@...il.com wrote:
>> > > > I tried it and ... the preprocessed asm is as expected:
>> > > > 	.globl __asm_copy_to_user ; .balign 4 ; __asm_copy_to_user:
>> > > > 	.globl __asm_copy_from_user ; .balign 4 ; __asm_copy_from_user:
>> > > >
>> > > >
>> > > > 	 li t6, 0x00040000
>> > > > 	 csrs sstatus, t6
>> > > > 	 ...
>> > > >
>> > > > But the nm -S returns different sizes for them:
>> > > > 	0000000000000004 000000000000006c T __asm_copy_from_user
>> > > > 	0000000000000002 000000000000006e T __asm_copy_to_user
>> > > >
>> > > > and the object code is:
>> > > > 	0000000000000000 <__asm_copy_to_user-0x2>:
>> > > > 	   0:   0001                    nop
>> > > >
>> > > > 	0000000000000002 <__asm_copy_to_user>:
>> > > > 	   2:   0001                    nop
>> > > >
>> > > > 	0000000000000004 <__asm_copy_from_user>:
>> > > > 	   4:   00040fb7                lui     t6,0x40
>> > > > 	   8:   100fa073                csrs    sstatus,t6
>> > > > 	   ...
>> > > >
>> > > > Why these unnneded nops?
>> > > > Is this a known problem of my toolchain (I use a plain gcc 7.3 +
>> > > > binutils 2.29, both configured as riscv64-none-elf)?
>> > > >
>> > > > If I remove the two ENTRY() and use instead:
>> > > > 	.globl __asm_copy_to_user ; __asm_copy_to_user:
>> > > > 	.globl __asm_copy_from_user ; __asm_copy_from_user:
>> > > > (IOW, I drop the .balign) then I get the expected result.
>> > > > But well, this seems unrelated to the double ENTRY.
>> > > >
>> > > > I can't test it more for now because I've some link errors (which,
>> > > > I understand are probably solved in the riscv tree of binutils).
>> > > >
>> > > > I'll send you the patch anyway since, as far as I understand the changes
>> > > > specific to this copy_to/from_user is OK.
>> > >
>> > > I think it's probably a bug in binutils-2.29 that should be fixed by
>> > > 2.30 -- IIRC we had some bugs that looked like this and they got
>> > > fixed, though it might be just in master (so 2.31).
>> >
>> > I've tried binutils-2.30 and riscv-binutils-gdb, both still have
>> > the problem and master binutils-gdb doesn't compile for me.
>> > OTOH, everything is fine if I disabled CONFIG_RISCV_ISA_C.
>>
>> OK, I'll try and figure out what's going on.  We've had a handful of
>> headaches trying to get things like '.align 2; .align 2' to actually produce
>> no NOPs for the second alignment directive, which is surprisingly
>> complicated due to the aggressive linker relaxation we do.
>
> OK. I imagine indeed but note that no linker is involved here so,
> if the problem is still present, it must already be in the assembler.

Ah, OK -- in that case then it's just not a bug.  In RISC-V land we handle 
alignment as part of relaxation in the linker, so if you're looking at the 
output of the assembler then you'll always see a bunch of NOPs for every 
alignment directive.  If you 'objdump -dr' you should be able to see the 
relocations that get emitted, there should be a R_RISCV_ALIGN that points to 
the run of NOPs.

>> > With this, the RISC-V arch should be sparse clean.
>> > I'll recheck after -rc1.
>>
>> This will be part of the PR that I tag today, so I anticipate it'll be in.
>
> Cool!
>
> -- Luc