linux-kernel - Re: [PATCH v3 2/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr

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: <20201123180142.GB20279@redhat.com>
Date:   Mon, 23 Nov 2020 19:01:43 +0100
From:   Oleg Nesterov <oleg@...hat.com>
To:     Christophe Leroy <christophe.leroy@...roup.eu>
Cc:     Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Madhavan Srinivasan <maddy@...ux.vnet.ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Paul Mackerras <paulus@...ba.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
        Christophe Leroy <christophe.leroy@....fr>,
        Jan Kratochvil <jan.kratochvil@...hat.com>,
        Nicholas Piggin <npiggin@...il.com>,
        linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in
 gpr_get() too

Christophe, et al,

So what?

Are you going to push your change or should I re-send 1-2 without
whitespace cleanups?

On 11/19, Oleg Nesterov wrote:
>
> On 11/19, Christophe Leroy wrote:
> >
> > I think the following should work, and not require the first patch (compile
> > tested only).
> >
> > --- a/arch/powerpc/kernel/ptrace/ptrace-view.c
> > +++ b/arch/powerpc/kernel/ptrace/ptrace-view.c
> > @@ -234,9 +234,21 @@ static int gpr_get(struct task_struct *target, const
> > struct user_regset *regset,
> >  	BUILD_BUG_ON(offsetof(struct pt_regs, orig_gpr3) !=
> >  		     offsetof(struct pt_regs, msr) + sizeof(long));
> > 
> > +#ifdef CONFIG_PPC64
> > +	membuf_write(&to, &target->thread.regs->orig_gpr3,
> > +		     offsetof(struct pt_regs, softe) - offsetof(struct pt_regs,
> > orig_gpr3));
> > +	membuf_store(&to, 1UL);
> > +
> > +	BUILD_BUG_ON(offsetof(struct pt_regs, trap) !=
> > +		     offsetof(struct pt_regs, softe) + sizeof(long));
> > +
> > +	membuf_write(&to, &target->thread.regs->trap,
> > +		     sizeof(struct user_pt_regs) - offsetof(struct pt_regs, trap));
> > +#else
> >  	membuf_write(&to, &target->thread.regs->orig_gpr3,
> >  			sizeof(struct user_pt_regs) -
> >  			offsetof(struct pt_regs, orig_gpr3));
> > +#endif
> >  	return membuf_zero(&to, ELF_NGREG * sizeof(unsigned long) -
> >  				 sizeof(struct user_pt_regs));
> >  }
> 
> Probably yes.
> 
> This mirrors the previous patch I sent (https://lore.kernel.org/lkml/20190917143753.GA12300@redhat.com/)
> and this is exactly what I tried to avoid, we can make a simpler fix now.
> 
> But let me repeat, I agree with any fix even if imp my version simplifies the code, just
> commit this change and lets forget this problem.
> 
> Oleg.