From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753651AbcEJDdX (ORCPT ); Mon, 9 May 2016 23:33:23 -0400 Received: from mail.kernel.org ([198.145.29.136]:55221 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752937AbcEJDdW (ORCPT ); Mon, 9 May 2016 23:33:22 -0400 Subject: Re: Is it really correct to check for breakpoint in kernel space against ptracer's address space? To: Ruslan Kabatsayev , linux-kernel@vger.kernel.org References: From: Andy Lutomirski Message-ID: <25b7bea4-e319-99b8-ac4b-019f5b2a1904@kernel.org> Date: Mon, 9 May 2016 20:33:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/09/2016 01:43 AM, Ruslan Kabatsayev wrote: > Hello all. > > Currently a 32-bit ptracer can't set HW breakpoints in tracee over > address space limitations of _tracer_. Even if the tracee is 64-bit, > doing PTRACE_POKEUSER into u_debugreg[n] with value>=0xffffe000 leads > to EINVAL (below is a test tracer program to reproduce this). At the > same time, if tracer is 64-bit, then for both 32- and 64-bit tracees > the PTRACE_POKEUSER call will succeed even if violates address space > constraints for tracee. > > I've traced this to arch_check_bp_in_kernel_space() in > arch/x86/kernel/hw_breakpoint.c, which checks the address against > TASK_SIZE, which as I understood refers to the current task, i.e. > caller of the syscall, instead of the tracee (at least tracing this in > Bochs leads me to this conclusion). Is there any reason at all for TASK_SIZE to be different from TASK_SIZE_MAX? /me needs to audit this stuff. --Andy