Date: Tue, 6 Jul 1999 14:25:23 -0500 From: Jonathan Lemon <jlemon@americantv.com> To: Brian Dean <brdean@unx.sas.com> Cc: freebsd-hackers@freebsd.org Subject: Re: support for i386 hardware debug watch points Message-ID: <19990706142523.38487@right.PCS> In-Reply-To: <199907060225.WAA08230@dean.pc.sas.com>; from Brian Dean on Jul 07, 1999 at 10:25:12PM -0400 References: <199907041554.KAA22328@free.pcs> <199907060225.WAA08230@dean.pc.sas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 07, 1999 at 10:25:12PM -0400, Brian Dean wrote: > 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. Whatever you think is appropriate, and that Bruce doesn't complain about. The name you picked is fine with me. > 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 If a breakpoint is set in the kernel, and is hit in kernel mode, it will cause a breakpoint fault in kernel mode. This will drop into ddb (if enabled). Is it possible (when setting the debug registers) to check that the breakpoint is being set in user space? This should be fairly simple; just check the va against VM_MAXUSER_ADDRESS. However, interpreting the contents of the debug registers is MD code, and should probably wind up in a short routine inside i386/sys_machdep.c, the alpha would have their own version of this. -- Jonathan 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?19990706142523.38487>