linux-kernel - Re: [PATCH] arm64: hw_breakpoint: don't clear debug registers in halt mode

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]

Message-ID: <20200331074147.GA25612@willie-the-truck>
Date:   Tue, 31 Mar 2020 08:41:47 +0100
From:   Will Deacon <will@...nel.org>
To:     tingwei@...eaurora.org
Cc:     Mark Rutland <mark.rutland@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: hw_breakpoint: don't clear debug registers in
 halt mode

On Tue, Mar 31, 2020 at 10:39:42AM +0800, tingwei@...eaurora.org wrote:
> 在 2020-03-30 21:42，Will Deacon 写道：
> > On Mon, Mar 30, 2020 at 01:39:46PM +0100, Mark Rutland wrote:
> > > On Sat, Mar 28, 2020 at 04:32:09PM +0800, Tingwei Zhang wrote:
> > > > If external debugger sets a breakpoint for one Kernel function
> > > > when device is in bootloader mode and loads Kernel, this breakpoint
> > > > will be wiped out in hw_breakpoint_reset(). To fix this, check
> > > > MDSCR_EL1.HDE in hw_breakpoint_reset(). When MDSCR_EL1.HDE is
> > > > 0b1, halting debug is enabled. Don't reset debug registers in this
> > case.
> > > 
> > > I don't think this is sufficient, because the kernel can still
> > > subsequently mess with breakpoints, and the HW debugger might not be
> > > attached at this point in time anyhow.
> > > 
> > > I reckon this should hang off the existing "nodebumon" command line
> > > option, and we shouldn't use HW breakpoints at all when that is
> > > passed.
> > > Then you can pass that to prevent the kernel stomping on the external
> > > debugger.
> > > 
> > > Will, thoughts?
> > 
> > I was going to suggest the same thing, although we will also need to
> > take
> > care to reset the registers if "nodebugmon" is toggled at runtime via
> > the
> > "debug_enabled" file in debugfs.
> > 
> Thanks for the suggestion, Mark and Will. It's a great idea to use
> "nodebugmon". When "nodebugmon" is set, Kernel won't change HW breakpoints.
> 
> For reset the registers after "debug_enabled" is toggled, I'm thinking if
> we are adding unnecessary complexity here.If we take that approach, we will
> hook "debug_enabled" interface and use smp_call_function_single() to call
> hw_breakpoint_reset() on each CPU. Wait for all CPUs' execution done and
> change "debug_enabled". External debugger would clear the breakpoints when
> it detaches the device and restores its breakpoints when attaches the
> device.
> Assume debug_enabled is changed to one after external debugger detaches the
> device. Debugger would already clear the breakpoint registers. If debgger is
> still attached, there's nothing Kernel can do to stop it restores/programs
> the breakpoint registers.
> 
> What do you think of this?

It's all a bit of a mess. Looking at it some more, why can't the external
debugger simply trap access to the debug registers using EDSCR.TDA? That
way, we don't have to change anything in the kernel.

Will