lkml.org 
[lkml]   [2019]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 1/9] x86/ptrace: Prevent truncation of bitmap size

* Thomas Gleixner <tglx@linutronix.de> wrote:

> The active() callback of the IO bitmap regset divides the IO bitmap size by
> the word size (32/64 bit). As the I/O bitmap size is in bytes the active
> check fails for bitmap sizes of 1-3 bytes on 32bit and 1-7 bytes on 64bit.
>
> Use DIV_ROUND_UP() instead.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> arch/x86/kernel/ptrace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/arch/x86/kernel/ptrace.c
> +++ b/arch/x86/kernel/ptrace.c
> @@ -697,7 +697,7 @@ static int ptrace_set_debugreg(struct ta
> static int ioperm_active(struct task_struct *target,
> const struct user_regset *regset)
> {
> - return target->thread.io_bitmap_max / regset->size;
> + return DIV_ROUND_UP(target->thread.io_bitmap_max, regset->size);
> }
>
> static int ioperm_get(struct task_struct *target,

Reviewed-by: Ingo Molnar <mingo@kernel.org>


But the ioperm core dumping logic in ptrace.c looks a bit weird. For
example why do we alias REGSET_IOPERM64 to REGSET_XFP:

enum x86_regset {
REGSET_GENERAL,
REGSET_FP,
REGSET_XFP,
REGSET_IOPERM64 = REGSET_XFP,
REGSET_XSTATE,
REGSET_TLS,
REGSET_IOPERM32,
};

This has been so since the original regset commit (325af5fb1418).

Unless I'm misreading the code this makes either REGSET_XFP or
REGSET_IOPERM64 misbehave? What am I missing?

Thanks,

Ingo

\
 
 \ /
  Last update: 2019-11-07 08:31    [W:0.107 / U:15.248 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site