netdev - Re: [PATCH v6 22/36] nds32: Debugging 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: <CAJsyPhwPsgMoReEaijkL6SAM6Q_fTL3BK9opa3yTaLtEE1PNTA@mail.gmail.com>
Date:   Tue, 23 Jan 2018 15:28:07 +0800
From:   Vincent Chen <deanbo422@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Greentime Hu <green.hu@...il.com>,
        Greentime <greentime@...estech.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Networking <netdev@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        David Howells <dhowells@...hat.com>,
        Will Deacon <will.deacon@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        linux-serial@...r.kernel.org,
        Geert Uytterhoeven <geert.uytterhoeven@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Mark Rutland <mark.rutland@....com>, Greg KH <greg@...ah.com>,
        Guo Ren <ren_guo@...ky.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        David Miller <davem@...emloft.net>,
        Jonas Bonn <jonas@...thpole.se>,
        Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
        Stafford Horne <shorne@...il.com>,
        Vincent Chen <vincentc@...estech.com>
Subject: Re: [PATCH v6 22/36] nds32: Debugging support

2018-01-18 18:37 GMT+08:00 Arnd Bergmann <arnd@...db.de>:
> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@...il.com> wrote:
>> From: Greentime Hu <greentime@...estech.com>
>>
>> This patch adds ptrace support.
>>
>> Signed-off-by: Vincent Chen <vincentc@...estech.com>
>> Signed-off-by: Greentime Hu <greentime@...estech.com>
>
> I must have missed this patch earlier, unfortunately I don't think
> this is ready:
>
>> +long arch_ptrace(struct task_struct *child, long request, unsigned long addr,
>> +                unsigned long data)
>> +{
>> +       int ret;
>> +
>> +       switch (request) {
>> +       case PTRACE_PEEKUSR:
>> +               ret =
>> +                   ptrace_read_user(child, addr, (unsigned long __user *)data);
>> +               break;
>> +
>> +       case PTRACE_POKEUSR:
>> +               ret = ptrace_write_user(child, addr, data);
>> +               break;
>> +
>> +       case PTRACE_GETREGS:
>> +               ret = ptrace_getregs(child, (void __user *)data);
>> +               break;
>> +
>> +       case PTRACE_SETREGS:
>> +               ret = ptrace_setregs(child, (void __user *)data);
>> +               break;
>> +
>> +       case PTRACE_GETFPREGS:
>> +               ret = ptrace_getfpregs(child, (void __user *)data);
>> +               break;
>> +
>> +       case PTRACE_SETFPREGS:
>> +               ret = ptrace_setfpregs(child, (void __user *)data);
>> +               break;
>> +
>> +       default:
>> +               ret = ptrace_request(child, request, addr, data);
>> +               break;
>> +       }
>> +
>> +       return ret;
>> +}
>
> It appears that you are implementing the old-style ptrace handling
> with architecture specific commands. Please have a look at how
> this is done in risc-v or arm64. If this takes more too much time
> to address, I'd suggest using an empty stub function for sys_ptrace
> and adding it back at a later point, but not send the current version
> upstream.
>
>      Arnd

Dear Arnd:

Thanks for your comments.

After referring to risc-v and arm64, I realize that PTRACE_GETREGSET
and PTRACE_SETREGSET is used to replace arch specific command.
The needed port for the two ptrace commands had done in current
version patch.

Could I keep them and just removing the code for old-style ptrace
handling in the next version patch?

Thanks

Vincent