home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / sysv386 / 16298 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  2.0 KB
  1. Xref: sparky comp.unix.sysv386:16298 comp.unix.sys5.r4:452
  2. Newsgroups: comp.unix.sysv386,comp.unix.sys5.r4
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!darwin.sura.net!wupost!gumby!yale!yale.edu!think.com!ames!kronos.arc.nasa.gov!iscnvx!netcomsv!cichlid!aab
  4. From: aab@cichlid.com (Andy Burgess)
  5. Subject: mmap and segv, a better way. Was: Re: av386mon source posted to alt.sources
  6. Message-ID: <1992Nov6.181051.8438@cichlid.com>
  7. Organization: SIlma Inc.
  8. References: <1992Oct2.184624.4441@omega.ssw.de>
  9. Date: Fri, 6 Nov 1992 18:10:51 GMT
  10. Lines: 28
  11.  
  12. In <1992Oct2.184624.4441@omega.ssw.de> av@omega.ssw.de (Andreas Vogel) writes:
  13.  
  14. >I've done some investigations about accessing kernel memory without
  15. >using the lseek() and read() system calls. This could be done with
  16. >the mmap() system call. The main point is, that the kernel pages will
  17. >be mapped in user address space on demand. If the user accesses a kernel
  18. >page, which is currently not mapped in user space, a SIGSEGV signal is
  19. >send by the kernel. A signal handler routine handles this signal by
  20. >mapping the kernel page holding the requested address and maps it
  21. >to user space. Afterwards the instruction which initiated the SIGSEGV
  22. >is restarted by a call to longjmp(). So before addressing a kernel
  23. >address a call to setjmp() must be done.
  24.  
  25. An even cleaner way works on SunOS. You may want to check if sysvr4
  26. supports this. In the signal handler if you simply return the
  27. OS retrys the faulting instruction. Thus no longjmp/setjmp is necessary,
  28. any access violation can be trapped, the memory permission 'fixed'
  29. via mmap, any you continue on your merry way...
  30.  
  31. Oh yes, the exact details of what address was accessed, program counter, etc
  32. is supplied to the signal handler (3rd argument is pointer to a struct that
  33. contains this info, as I recall).
  34.  
  35. Andy
  36. -- 
  37. ==============================================================================
  38. Andrew A. Burgess            aab@cichlid.com              voice (408) 335 4779
  39. ==============================================================================
  40.