Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1722588 > unrolled thread

Re: [PATCH v8 05/28] x86/mpx: Use signed variables to compute effective addresses

Started byBorislav Petkov <bp@suse.de>
First post2017-08-29 18:10 +0200
Last post2017-08-31 12:00 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v8 05/28] x86/mpx: Use signed variables to compute  effective addresses Borislav Petkov <bp@suse.de> - 2017-08-29 18:10 +0200
    Re: [PATCH v8 05/28] x86/mpx: Use signed variables to compute  effective addresses Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-08-31 06:20 +0200
      Re: [PATCH v8 05/28] x86/mpx: Use signed variables to compute  effective addresses Borislav Petkov <bp@suse.de> - 2017-08-31 12:00 +0200

#1722588 — Re: [PATCH v8 05/28] x86/mpx: Use signed variables to compute effective addresses

FromBorislav Petkov <bp@suse.de>
Date2017-08-29 18:10 +0200
SubjectRe: [PATCH v8 05/28] x86/mpx: Use signed variables to compute effective addresses
Message-ID<ujRfs-4Ns-17@gated-at.bofh.it>
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 <bp@suse.de>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
> Cc: Colin Ian King <colin.king@canonical.com>
> Cc: Lorenzo Stoakes <lstoakes@gmail.com>
> Cc: Qiaowei Ren <qiaowei.ren@intel.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Nathan Howard <liverlint@gmail.com>
> Cc: Adan Hawthorn <adanhawthorn@gmail.com>
> Cc: Joe Perches <joe@perches.com>
> Cc: Ravi V. Shankar <ravi.v.shankar@intel.com>
> Cc: x86@kernel.org
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@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;
 
 			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;
 }
 
 static int mpx_insn_decode(struct insn *insn,

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [next] | [standalone]


#1723799

FromRicardo Neri <ricardo.neri-calderon@linux.intel.com>
Date2017-08-31 06:20 +0200
Message-ID<ukp7r-Oj-3@gated-at.bofh.it>
In reply to#1722588
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 <bp@suse.de>
> > Cc: Andy Lutomirski <luto@kernel.org>
> > Cc: Dave Hansen <dave.hansen@linux.intel.com>
> > Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
> > Cc: Colin Ian King <colin.king@canonical.com>
> > Cc: Lorenzo Stoakes <lstoakes@gmail.com>
> > Cc: Qiaowei Ren <qiaowei.ren@intel.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Nathan Howard <liverlint@gmail.com>
> > Cc: Adan Hawthorn <adanhawthorn@gmail.com>
> > Cc: Joe Perches <joe@perches.com>
> > Cc: Ravi V. Shankar <ravi.v.shankar@intel.com>
> > Cc: x86@kernel.org
> > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@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

[toc] | [prev] | [next] | [standalone]


#1724053

FromBorislav Petkov <bp@suse.de>
Date2017-08-31 12:00 +0200
Message-ID<ukuqu-3ZB-13@gated-at.bofh.it>
In reply to#1723799
On Wed, Aug 30, 2017 at 09:19:14PM -0700, Ricardo Neri wrote:
> 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.

See my other reply. Just merge this diff with your patch - no need for a
separate one.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web