Date: Mon, 5 Jul 1999 22:25:12 -0400 (EDT) From: Brian Dean <brdean@unx.sas.com> To: jlemon@americantv.com (Jonathan Lemon) Cc: freebsd-hackers@freebsd.org Subject: Re: support for i386 hardware debug watch points Message-ID: <199907060225.WAA08230@dean.pc.sas.com> In-Reply-To: <199907041554.KAA22328@free.pcs> from Jonathan Lemon at "Jul 4, 1999 10:54:41 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Lemon writes: > In article <local.mail.freebsd-hackers/199907041453.KAA03044@dean.pc.sas.com> you write: > >This is not as efficent as it could be implemented with a separate > >flag to indicate whether saving the debug registers is necessary since > >loading/storing the debug registers is fairly expensive (11 clocks on > >an i486). > > Yes; you may want to just use another bit in pcb_flags that indicates > if the debug registers are in use. OK, I did that. What is the convention for naming the flags? The only one in use for that set of flags is FP_SOFTFP. I'm currently using PCB_DBREGS, but I but I easily change the name to whatever convention dictates - please advise. > >Should 'struct reg' be extended to directly include the debug > >registers or should we go the route of having another data structure > >for the debug registers, not unlike how the floating point registers > >are handled? > > I'd be inclined to create another data structure, unless the debug > registers are architecturally defined to be identical on all x86 > chips. > > > >Otherwise, I think I will need to set up a 'struct dbregs', provide > >the appropriate 'fill_dbregs()' and 'set_dbregs()', and then provide a > >PT_SETDBREGS, PT_GETDBREGS interface to 'ptrace()'. > > Either that, or create a routine like i386_set_breakpoint() in > sys_machdep that would handle setting breakpoints for different > types of cpu architectures. What I ended up doing is make a new struct dbregs, similar to struct fpregs. Additionally, I modified the necessary procfs code to create a view to read and write the registers called "dbregs". The only thing that concerns me here is that maybe this entry in procfs is too architecture dependent, or maybe it violates some standards regarding procfs semantics (if there are any). I don't know enough about the Alpha architecture to know if this entry makes sense or not. Any comments here are appreciated. It appears as though some other systems do this with an ioctl call using the fd to the "/proc/$pid/ctl" file. However, these semantics seem to go against the precedent set by the ./regs and ./fpregs interfaces. I chose to use ./dbregs primarily because it was consistant with the use of ./regs and ./fpregs. Again, comments here are appreciated. I've got this kernel running right now and everything seems to be working fine, at least no panics or smoke. Here's a question: Are there any security concerns with being able to update the debug registers? Should a process be able to set a breakpoint inside the kernel, for example? In such a case, an INT 3 exception would be generated from within kernel code. Would this drop the system into the kernel debugger if it was enabled? If I've implemented the saving and restoring (and clearing) of the debug registers in cpu_switch() the way that I have intended, a watchpoint that a process sets within the kernel should not be able to occur outside the context of the process in which it was set. However, it is conceivable that a user (if allowed to put a breakpoint outside of his address space) could force the kernel to be interrupted at any location that could execute within the context of his process. This could result in breaking into code that was never designed to be interruptible, such as in the middle of updating a shared data structure. Any ideas are welcome, and I will do my best to implement them. Now that I've done this much, I now need to look at gdb some more and hook in the new interface. I'll follow that up with additional testing. Thanks, -Brian -- Brian Dean SAS Institute Inc brdean@unx.sas.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907060225.WAA08230>