linux-kernel - Re: [PATCH 1/2] riscv: ptrace: Use the correct API for `fcsr' access

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:   Wed, 05 Aug 2020 12:48:51 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     macro@....com
CC:     viro@...iv.linux.org.uk, linux-riscv@...ts.infradead.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject:     Re: [PATCH 1/2] riscv: ptrace: Use the correct API for `fcsr' access

On Wed, 05 Aug 2020 03:25:11 PDT (-0700), macro@....com wrote:
> On Wed, 5 Aug 2020, Al Viro wrote:
>
>> > I'm not sure I understand what you're saying, but given that branch replaces
>> > all of this I guess it's best to just do nothing on our end here?
>>
>> It doesn't replace ->put() (for now); it _does_ replace ->get() and AFAICS the
>> replacement is much saner:
>>
>> static int riscv_fpr_get(struct task_struct *target,
>>                          const struct user_regset *regset,
>>                          struct membuf to)
>> {
>> 	struct __riscv_d_ext_state *fstate = &target->thread.fstate;
>>
>> 	membuf_write(&to, fstate, offsetof(struct __riscv_d_ext_state, fcsr));
>> 	membuf_store(&to, fstate->fcsr);
>> 	return membuf_zero(&to, 4);     // explicitly pad
>> }
>
>  I'm glad to see the old interface go, it was cumbersome.
>
>> user_regset_copyout() calling conventions are atrocious and so are those of
>> regset ->get().  The best thing to do with both is to take them out of their
>> misery and be done with that.  Do you see any problems with riscv gdbserver
>> on current linux-next?  If not, I'd rather see that "API" simply go away...
>> If there are problems, I would very much prefer fixes on top of what's done
>> in that branch.
>
>  I can push linux-next through regression-testing with RISC-V gdbserver
> and/or native GDB if that would help.  This is also used with core dumps,
> but honestly I don't know what state RISC-V support is in in the BFD/GDB's
> core dump interpreter, as people tend to forget about the core dump
> feature nowadays.

IIRC Andrew does GDB test suite runs sometimes natively on Linux as part of
general GDB maintiance and we don't see major issues, but I'm pretty checked
out of GDB development these days so he would know better than I do.  It's
always great to have someone test stuff, though -- and I doubt he's testing
linux-next.  It's been on my TODO list for a long time now to put together
tip-of-tree testing for the various projects but I've never gotten around to
doing it.

Oddly enough, despite not really using GDB I have used it for core dumps -- I
was writing a tool to convert commit logs to coredumps with the GDB reverse
debugging annotations, but I never got around to finishing it.