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]
Date:   Sat, 25 May 2019 10:49:49 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     kan.liang@...ux.intel.com
Cc:     vincent.weaver@...ne.edu, ak@...ux.intel.com, peterz@...radead.org,
        alexander.shishkin@...ux.intel.com, acme@...hat.com,
        jolsa@...hat.com, eranian@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] perf/x86/regs: Check reserved bits


* kan.liang@...ux.intel.com <kan.liang@...ux.intel.com> wrote:

> From: Kan Liang <kan.liang@...ux.intel.com>
> 
> The perf fuzzer triggers a warning which map to:
> 
> 	if (WARN_ON_ONCE(idx >= ARRAY_SIZE(pt_regs_offset)))
> 		return 0;
> 
> The bits between XMM registers and generic registers are reserved.
> But perf_reg_validate() doesn't check these bits.
> 
> Add REG_RESERVED for reserved bits.
> Check the reserved bits in perf_reg_validate().
> 
> Fixes: 878068ea270e ("perf/x86: Support outputting XMM registers")
> Reported-by: Vince Weaver <vincent.weaver@...ne.edu>
> Signed-off-by: Kan Liang <kan.liang@...ux.intel.com>
> ---
>  arch/x86/kernel/perf_regs.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/perf_regs.c b/arch/x86/kernel/perf_regs.c
> index 86ffe5a..3f8c1fc 100644
> --- a/arch/x86/kernel/perf_regs.c
> +++ b/arch/x86/kernel/perf_regs.c
> @@ -79,6 +79,9 @@ u64 perf_reg_value(struct pt_regs *regs, int idx)
>  	return regs_get_register(regs, pt_regs_offset[idx]);
>  }
>  
> +#define REG_RESERVED	(((1ULL << PERF_REG_X86_XMM0) - 1) & \
> +			~((1ULL << PERF_REG_X86_MAX) - 1))

This is just randomly polluting the macro namespace with a new variant. 
We have PERF_REG_X86_ pattern - why not name the new one within that 
pattern?

Thanks,

	Ingo

Powered by blists - more mailing lists