linux-kernel - Re: [patch 01/11] Introducing generic hardware breakpoint handler interfaces

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: <20090311125705.GB9547@in.ibm.com>
Date:	Wed, 11 Mar 2009 18:27:05 +0530
From:	"K.Prasad" <prasad@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>
Subject: Re: [patch 01/11] Introducing generic hardware breakpoint handler
	interfaces

On Tue, Mar 10, 2009 at 03:50:36PM +0100, Ingo Molnar wrote:
> 
> * Alan Stern <stern@...land.harvard.edu> wrote:
> 
> > On Tue, 10 Mar 2009, Ingo Molnar wrote:
> > 
> > > * prasad@...ux.vnet.ibm.com <prasad@...ux.vnet.ibm.com> wrote:
> > > 
> > > 
> > > > +static u8			tprio[HB_NUM];	/* Thread bp max priorities */
> > > > +LIST_HEAD(kernel_bps);			/* Kernel breakpoint list */
> > > > +static LIST_HEAD(thread_list);			/* thread_hw_breakpoint list */
> > > > +DEFINE_PER_CPU(struct cpu_hw_breakpoint, cpu_bp);
> > 
> > If nobody minds, I'll answer some of these questions on 
> > Prasad's behalf because they address parts of the code that 
> > were written before he took over the project.
> > 
> > > hm, why do we need the whole 'priority' mechanism? It seems 
> > > very over-designed to me.
> > 
> > This was done at Roland McGrath's express request.  We should 
> > see what he has to say about it.
> > 
> > > The likelyhood of both user-space and kernel-space to use 
> > > hw-breakpoints is very low to begin with. And if they use 
> > > them, the likelyhood of there being more than 4 debugregs 
> > > required in the same context is even lower.
> > 
> > Not all architectures have 4 debug registers.  Most have only 
> > one.
> >
> > > If that happens we shouldnt try to be too smart about them - 
> > > just override user-space ones with kernel space ones and 
> > > that's it. No explicit priorities are needed.
> > 
> > Roland really did not want it done this way.
> 
> Well i guess i'll have to wait for Roland's reply then.
> 
> 	Ingo

For the benefit of continuing discussion on this topic, here's an
extract from an old mail (http://lkml.org/lkml/2007/2/5/465) from
Roland, explaining the need for prioritisation of requests. It must have
been utrace as a potential user that made him suggest this.

"I am all in favor of a facility to manage shared use of the debug
registers, such as your debugreg.h additions.  I just think it needs to be
a little more flexible.  An unobtrusive kernel facility has to get out of
the way when user-mode decides to use all its debug registers.  It's not
immediately important what it's going to about it when contention arises,
but there has to be a way for the user-mode facilities to say they need to
allocate debugregs with priority and evict other squatters.  So, something
like code allocating a debugreg can supply a callback that's made when its
allocation has to taken by something with higher priority.  

Even after utrace, there will always be the possibility of a traditional
uncoordinated user of the raw debug registers, if nothing else ptrace
compatibility will always be there for old users.  So anything new and
fancy needs to be prepared to back out of the way gracefully.  In the case
of kwatch, it can just have a handler function given by the caller to start
with.  It's OK if individual callers can specially declare "I am not
well-behaved" and eat debugregs so that well-behaved high-priority users
like ptrace just have to lose (breaking compatibility).  But no
well-behaved caller of kwatch will do that.

I certainly intend for later features based on utrace to include
higher-level treatment of watchpoints so that user debugging facilities can
also become responsive to debugreg allocation pressure.  (Eventually, the
user facilities might have easier ways of falling back to other methods and
getting out of the way of kernel debugreg consumers, than can be done for
the kernel-mode-tracing facilities.)  To that end, I'd like to see a clear
and robust interface for debugreg sharing, below the level of kwatch."

Thanks,
K.Prasad

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/