rick@nyit.UUCP (Rick Ace) (03/14/86)
[]
Description:
It's rather easy for anyone with read access to /dev/kmem to
crash a 4.2bsd VAX with a trap-9 (protection fault) panic.
Apparently, kernacc() (in vax/locore.s) gets confused when
called to verify access to a region of memory that straddles
P1 and S0 space, ultimately making a wild reference.
Even well-intentioned utilities such as "ps" and "uptime" can
conceivably trip over this bug because they are taking
snapshots of data that is changing out from underneath them.
Repeat-By:
char buf[168];
main()
{
int fd;
fd = open("/dev/kmem", 0);
if (fd < 0) {
perror("/dev/kmem");
exit(1);
}
lseek(fd, 0x7fffffff, 0); /* begin near the end of P1 space */
read(fd, buf, sizeof buf); /* crosses from P1 into S0 space */
}
Fix:
One possible fix to kernacc() would check for a region
that began in one quadrant of virtual memory and ended
in a different quadrant. If so, the existing kernacc
logic could be invoked twice, to verify each quadrant's
portion independently. I haven't tried this yet.
-----
Rick Ace
Computer Graphics Laboratory
New York Institute of Technology
Old Westbury, NY 11568
(516) 686-7644
{decvax,seismo}!philabs!nyit!rickchris@umcp-cs.UUCP (Chris Torek) (03/22/86)
My 4.3ish kernel does not crash with Rick's example, but the bug is real. As a quick fix, I would suggest just disallowing accesses to discontiguous regions. (The only one that makes even slight sense is P1/S space, and no current programs cross the boundary in a single read, or at least not intentionally.) Change the very beginning of kernacc to read as follows (just add the lines marked): ENTRY(kernacc, 0) # in 4.2 it was `_kernacc:', I think movl 4(ap),r0 # virtual address + bicl3 $0x3fffffff,r0,r1 + addl3 8(ap),r0,r2 # ending virtual address + bicl2 $0x3fffffff,r2 + cmpl r1,r2 # same region? + bneq kacerr # no, disallow it bbcc $31,r0,kacc1 . . . Warning: the above is untested. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu