Re: x86-64: int3 no longer causes SIGTRAP in 2.6.10

[Andi Kleen]

On Wed, Jan 19, 2005 at 05:06:36PM +0530, Prasanna S Panchamukhi wrote:
> Hi Andi,
> 
> > > > -	set_intr_gate(3,&int3);
> > > > +	set_system_gate(3,&int3);
> > > >  	set_system_gate(4,&overflow);	/* int4-5 can be called from all */
> > > >  	set_system_gate(5,&bounds);
> > > >  	set_intr_gate(6,&invalid_op);
> > > > Index: linux/arch/x86_64/kernel/kprobes.c
> 
> This looks good to me. Andi do you see any thing that will cause premption
>  by moving int3 to system gate.

The only difference between an interrupt gate and a system gate is 
that a system gate can be called directly from user space using "int". 

I don't see how that would affect preemption.



> 
> > > > ===================================================================
> > > > --- linux.orig/arch/x86_64/kernel/kprobes.c	2005-01-04 12:12:39.%N +0100
> > > > +++ linux/arch/x86_64/kernel/kprobes.c	2005-01-18 02:46:05.%N +0100
> > > > @@ -297,6 +297,8 @@
> > > >  	struct die_args *args = (struct die_args *)data;
> > > >  	switch (val) {
> > > >  	case DIE_INT3:
> > > > +		if (args->regs->cs & 3)
> > > > +			return NOTIFY_DONE;
> 
> This will prevent handling of userspace probes (privilege level 3). The 
> kprobe_exception handler will return from here and registered user space probe
> handler won't be called.

It's equivalent to the previous code - previously the CPU would reject
the int 3 call though and turn it into an GPF. If you prefer it I can
remove it. But were user space probes ever tested? It doesn't look like it.
If they're broken perhaps it would be better to disable it for now 
to prevent any unintended security issues.

-Andi

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