linux-kernel - Re: [PATCH 0/3] MIPS: DSP ASE regset support

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: <20180719205630.osfdzk7gqv4djvqc@pburton-laptop>
Date:   Thu, 19 Jul 2018 13:56:30 -0700
From:   Paul Burton <paul.burton@...s.com>
To:     "Maciej W. Rozycki" <macro@...s.com>
Cc:     Alexander Viro <viro@...iv.linux.org.uk>,
        James Hogan <jhogan@...nel.org>,
        Ralf Baechle <ralf@...ux-mips.org>,
        linux-fsdevel@...r.kernel.org, linux-mips@...ux-mips.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] MIPS: DSP ASE regset support

Hi Maciej,

On Tue, May 15, 2018 at 11:32:11PM +0100, Maciej W. Rozycki wrote:
>  For years, quite oddly, we have been missing DSP ASE register state from 
> core files.  These days regsets are used to define what goes into a core 
> file, so here's a change adding one.
> 
>  As a side effect ptrace(2) can now also access this regset, however no 
> complementing client implementation has been made.  Eventually that'll 
> have to change though so that DSP ASE registers can be correctly accessed 
> in n32 processes, which suffer from ptrace(2) 32-bit data types truncating 
> contents exchanged by PTRACE_PEEKUSR and PTRACE_POKEUSR requests with 
> 64-bit registers and no means defined to access partial registers via this 
> API.
> 
>  In the course of this implementation I came across two bugs affecting the 
> area being updated and hence this has become a small patch series with the 
> audience wider than originally expected.
> 
>  See individual commit descriptions for the details of changes made.  
> 
>  NB there is no strict functional dependency between 1/3 and 2/3-3/3, so 
> the order of commits does not have to be preserved as far as these two 
> subsets are concerned.  However 3/3 does trigger the problem addressed 
> with 1/3 (and gracefully handles it), hence the grouping in a series.
> 
>  Please apply.

Thanks - applied to mips-next for 4.19, though I removed the stable tags
on patches 1/3 & 3/3 & it's worth noting that the ELF note numbers are
changed to from 0x70X to 0x80X, since 0x700 has been used already.

If you really care about a stable backport for 3/3 let's talk, but I'm
doubtful as to its use when we've been missing this for so long.

Paul