Re: [v2 2/7] x86/mpx: Fail when implicit zero-displacement is used along with R/EBP

Ricardo Neri <[email protected]>
Newsgroups org.kernel.vger.linux-msdos,org.kernel.vger.linux-kernel
Message-ID <1482878000.106950.10.camel@ranerica-desktop>
On Fri, 2016-12-23 at 17:58 -0800, Andy Lutomirski wrote:
> On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
> <[email protected]> wrote:
> > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> > Developer's Manual volume 2A states that when memory addressing with no
> > explicit displacement (i.e, mod part of ModR/M is 0), a SIB byte is used
> > and the base of the SIB byte points to (R/EBP) (i.e., base = 5), an
> > explicit displacement of 0 must be used.
> >
> > Make the address decoder to return -EINVAL in such a case.
> >
> > Cc: Dave Hansen <[email protected]>
> > Cc: Adam Buchbinder <[email protected]>
> > Cc: Colin Ian King <[email protected]>
> > Cc: Lorenzo Stoakes <[email protected]>
> > Cc: Qiaowei Ren <[email protected]>
> > Cc: Ravi V. Shankar <[email protected]>
> > Cc: [email protected]
> > Signed-off-by: Ricardo Neri <[email protected]>
> > ---
> >  arch/x86/mm/mpx.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
> > index 6a75a75..71681d0 100644
> > --- a/arch/x86/mm/mpx.c
> > +++ b/arch/x86/mm/mpx.c
> > @@ -120,6 +120,13 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs,
> >
> >         case REG_TYPE_BASE:
> >                 regno = X86_SIB_BASE(insn->sib.value);
> > +               if (regno == 5 && X86_MODRM_RM(insn->modrm.value) == 0) {
> > +                       WARN_ONCE(1, "An explicit displacement is required when %sBP used as SIB base.",
> > +                                 (IS_ENABLED(CONFIG_X86_64) && insn->x86_64) ?
> > +                                 "R13 or R" : "E");
> > +                       return -EINVAL;
> > +               }
> > +
> 
> Now that I've read the cover letter, I see what's going on.  This
> should not warn -- user code can easily trigger this deliberately.

OK, I'll remove it. Are you concerned about the warning printing the
calltrace, even only once?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.