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
| ||
|
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
Powered by blists - more mailing lists