On Tue, 2017-08-29 at 18:09 +0200, Borislav Petkov wrote:
> On Fri, Aug 18, 2017 at 05:27:46PM -0700, Ricardo Neri wrote:
> > Even though memory addresses are unsigned, the operands used to compute the
> > effective address do have a sign. This is true for ModRM.rm, SIB.base,
> > SIB.index as well as the displacement bytes. Thus, signed variables shall
> > be used when computing the effective address from these operands. Once the
> > signed effective address has been computed, it is casted to an unsigned
> > long to determine the linear address.
> > 
> > Variables are renamed to better reflect the type of address being
> > computed.
> > 
> > Cc: Borislav Petkov <b...@suse.de>
> > Cc: Andy Lutomirski <l...@kernel.org>
> > Cc: Dave Hansen <dave.han...@linux.intel.com>
> > Cc: Adam Buchbinder <adam.buchbin...@gmail.com>
> > Cc: Colin Ian King <colin.k...@canonical.com>
> > Cc: Lorenzo Stoakes <lstoa...@gmail.com>
> > Cc: Qiaowei Ren <qiaowei....@intel.com>
> > Cc: Peter Zijlstra <pet...@infradead.org>
> > Cc: Nathan Howard <liverl...@gmail.com>
> > Cc: Adan Hawthorn <adanhawth...@gmail.com>
> > Cc: Joe Perches <j...@perches.com>
> > Cc: Ravi V. Shankar <ravi.v.shan...@intel.com>
> > Cc: x...@kernel.org
> > Signed-off-by: Ricardo Neri <ricardo.neri-calde...@linux.intel.com>
> > ---
> >  arch/x86/mm/mpx.c | 20 ++++++++++++++------
> >  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> I think you can simplify this function even more (diff ontop):
> 
> diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
> index 9eec98022510..d0ec5c9b2a57 100644
> --- a/arch/x86/mm/mpx.c
> +++ b/arch/x86/mm/mpx.c
> @@ -139,7 +139,7 @@ static int get_reg_offset(struct insn *insn, struct 
> pt_regs *regs,
>  static void __user *mpx_get_addr_ref(struct insn *insn, struct pt_regs *regs)
>  {
>       int addr_offset, base_offset, indx_offset;
> -     unsigned long linear_addr;
> +     unsigned long linear_addr = -1;
>       long eff_addr, base, indx;
>       insn_byte_t sib;
>  
> @@ -150,18 +150,18 @@ static void __user *mpx_get_addr_ref(struct insn *insn, 
> struct pt_regs *regs)
>       if (X86_MODRM_MOD(insn->modrm.value) == 3) {
>               addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
>               if (addr_offset < 0)
> -                     goto out_err;
> +                     goto out;
>  
>               eff_addr = regs_get_register(regs, addr_offset);
>       } else {
>               if (insn->sib.nbytes) {
>                       base_offset = get_reg_offset(insn, regs, REG_TYPE_BASE);
>                       if (base_offset < 0)
> -                             goto out_err;
> +                             goto out;
>  This is a good suggestion. This is a good suggestion. 
>                       indx_offset = get_reg_offset(insn, regs, 
> REG_TYPE_INDEX);
>                       if (indx_offset < 0)
> -                             goto out_err;
> +                             goto out;
>  
>                       base = regs_get_register(regs, base_offset);
>                       indx = regs_get_register(regs, indx_offset);
> @@ -170,7 +170,7 @@ static void __user *mpx_get_addr_ref(struct insn *insn, 
> struct pt_regs *regs)
>               } else {
>                       addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
>                       if (addr_offset < 0)
> -                             goto out_err;
> +                             goto out;
>  
>                       eff_addr = regs_get_register(regs, addr_offset);
>               }
> @@ -180,9 +180,8 @@ static void __user *mpx_get_addr_ref(struct insn *insn, 
> struct pt_regs *regs)
>  
>       linear_addr = (unsigned long)eff_addr;
>  
> +out:
>       return (void __user *)linear_addr;
> -out_err:
> -     return (void __user *)-1;

This is a good suggestion. I will work on it. By now my series comprises
28 patches. If you plan to review the rest of the series and you don't
have major objections, could I work on these updates as increments from
my v8 series? I think that with 28 patches in the series is becoming
difficult to review.

Thanks and BR,
Ricardo

Reply via email to