Re: amd64 SMEP SMAP trap panic print

2020-01-09 Thread Mark Kettenis
> Date: Thu, 9 Jan 2020 14:01:32 +0100 > From: Alexander Bluhm > > On Thu, Jan 09, 2020 at 12:01:07PM +0100, Mark Kettenis wrote: > > By splitting this out, the "retain the kernel lock" bit of the > > comment doesn't make a lot of sense anymore... > > Then move the comment to the return where

Re: amd64 SMEP SMAP trap panic print

2020-01-09 Thread Alexander Bluhm
On Thu, Jan 09, 2020 at 12:01:07PM +0100, Mark Kettenis wrote: > By splitting this out, the "retain the kernel lock" bit of the > comment doesn't make a lot of sense anymore... Then move the comment to the return where we retain it. bluhm Index: arch/amd64/amd64/db_trace.c

Re: amd64 SMEP SMAP trap panic print

2020-01-09 Thread Mark Kettenis
> Date: Thu, 9 Jan 2020 10:42:55 +0100 > From: Alexander Bluhm > > On Thu, Dec 26, 2019 at 08:12:50PM +0100, Alexander Bluhm wrote: > > Any more concerns or can this be commited? > > Any ok? > > > Index: arch/amd64/amd64/db_trace.c > >

Re: amd64 SMEP SMAP trap panic print

2020-01-09 Thread Alexander Bluhm
On Thu, Dec 26, 2019 at 08:12:50PM +0100, Alexander Bluhm wrote: > Any more concerns or can this be commited? Any ok? > Index: arch/amd64/amd64/db_trace.c > === > RCS file:

Re: amd64 SMEP SMAP trap panic print

2019-12-26 Thread Alexander Bluhm
Any more concerns or can this be commited? bluhm Index: arch/amd64/amd64/db_trace.c === RCS file: /data/mirror/openbsd/cvs/src/sys/arch/amd64/amd64/db_trace.c,v retrieving revision 1.47 diff -u -p -r1.47 db_trace.c ---

Re: amd64 SMEP SMAP trap panic print

2019-12-20 Thread Alexander Bluhm
On Fri, Dec 20, 2019 at 11:15:09AM -0700, Theo de Raadt wrote: > Alexander Bluhm wrote: > > > On Thu, Dec 19, 2019 at 06:25:06PM -0800, Philip Guenther wrote: > > > For this part, should we reuse the 'faultstr' logic seen later to set the > > > panic string and do something like, say... > > > >

Re: amd64 SMEP SMAP trap panic print

2019-12-20 Thread Theo de Raadt
Alexander Bluhm wrote: > On Thu, Dec 19, 2019 at 06:25:06PM -0800, Philip Guenther wrote: > > For this part, should we reuse the 'faultstr' logic seen later to set the > > panic string and do something like, say... > > That makes sense. I need another workaround for the stack trace > after

Re: amd64 SMEP SMAP trap panic print

2019-12-20 Thread Alexander Bluhm
On Thu, Dec 19, 2019 at 06:25:06PM -0800, Philip Guenther wrote: > For this part, should we reuse the 'faultstr' logic seen later to set the > panic string and do something like, say... That makes sense. I need another workaround for the stack trace after calling the NULL function. This time I

Re: amd64 SMEP SMAP trap panic print

2019-12-19 Thread Philip Guenther
On Fri, 20 Dec 2019, Alexander Bluhm wrote: > Can we use the regular trap panic for SMEP and SMAP? pageflttrap() > returns 0 to print a nice reason in kerntrap(). Especially if ddb is > disabled, additional information is printed. > > attempt to access user address 0xe27539f1000 in supervisor

amd64 SMEP SMAP trap panic print

2019-12-19 Thread Alexander Bluhm
Hi, Can we use the regular trap panic for SMEP and SMAP? pageflttrap() returns 0 to print a nice reason in kerntrap(). Especially if ddb is disabled, additional information is printed. attempt to access user address 0xe27539f1000 in supervisor mode fatal page fault in supervisor mode trap type