Re: [TUHS] Accessing the PDP-11/70 MMU registers and the kernel's u area

Re: [TUHS] Accessing the PDP-11/70 MMU registers and the kernel's u area

[Noel Chiappa]

    > From: Diomidis Spinellis

    > From the 2.11 BSD sources I understand that the PDP-11/70 MMU address
    > and data registers, KDSA and KDSD, start at 0172360 and 0172320
    > respectively ...

Expressed as 16-bit addreses, on a PDP-11 with mapping disabled, yes.

    > I checked this by looking at /dev/mem. 

I don't know about 2.11, but in other PDP-11 Unixes, /dev/mem gives access to
the actual CPU memory bus (which on a /34, etc, is the 18-bit address UNIBUS;
on a /70 it's a separate 22-bit address bus).  In the /70 memory address
space, the 'I/O page' (which is where the PxR's live) is at the top end of it,
i.e. the registers are at 017772360 (KDSAR0), etc.

    > What am I missing?

PDP-11's have a plethora of address spaces, of different sizes. You need to
always be aware of which one you're working in.

    > My goal is to access from the console the kernel's u area.  According to
    > mem(4) and the symbols in /unix, this should be at address 0140000.

In the kernel virtual address space, yes.

    > Indeed, accessing it through /dev/kmem I get the expected results for
    > e.g. u_comm and u_uid.

Because /dev/kmem gives access to kernel address space for the _current_
process.

    > I have been unable to find it in the machine's physical memory

By far and away the easiest thing, for the _current_ process, is to
use /dev/kmem, which automagally applies the correct mapping.

For other processes, if the process is swapped in, there's some field in the
proc structure which says where in physical memory it us. IIRC, the user
struct and the kernel stack are stored in the very bottom of that.

(This article:

    http://gunkies.org/wiki/Unix_V6_dump_analysis#Memory_layouts

goes into some detail for V6. Not sure how different 2.11 is; I know it uses
one block of kernel address space to map in code overlays, but I don't know
all the details of how it works.)

Anyway, using that, one could read the user area in /dev/mem, at the
appropriate location.

For swapped-out processes, a similar algorithm applies, but you'll
have to look in the swap device (obviously).

     Noel

Re: [TUHS] Accessing the PDP-11/70 MMU registers and the kernel's u area

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

On Sun, Jun 14, 2020 at 8:47 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

> Not sure how different 2.11 is; I know it uses
> one block of kernel address space to map in code overlays, but I don't know
> all the details of how it works.
>

 Yes. There's 1 8kB instruction segment that implements the overlays. The
calls to these routines are bounced through thunks that flips the segment
register if needed on the call. Each overlay is limited to 8k. The 2.11BSD
kernel has about 70k of overlays these days... and they are all almost
full, as is the text segment (which is limited to 56k). They get around
this by running the TCP/IP stack in supervisor mode, kinda as a process..
This means the total size of the kernel and data for the kernel is 320k on
a machine with a 128k address space :).

I've been looking a lot at that code lately... I'm back to patch 0, but am
missing ld.c and ranlib.c in my push to get back to the start since they
were augmented between 2.10.1 and 2.11 for the new portable archive
format... Once I solve those two, it's off to build testing in simh.

Warner

[-- Attachment #2: Type: text/html, Size: 1508 bytes --]

Re: [TUHS] Accessing the PDP-11/70 MMU registers and the kernel's u area

[Diomidis Spinellis]

On 14-Jun-20 17:46, Noel Chiappa wrote:
> I don't know about 2.11, but in other PDP-11 Unixes, /dev/mem gives access to
> the actual CPU memory bus (which on a /34, etc, is the 18-bit address UNIBUS;
> on a /70 it's a separate 22-bit address bus).  In the /70 memory address
> space, the 'I/O page' (which is where the PxR's live) is at the top end of it,
> i.e. the registers are at 017772360 (KDSAR0), etc.

Indeed, fetching data from the I/O page region gives plausible values 
and everything works beautifully.  Thank you!

The value of the kernel's u is 0140000 so it begins exactly at the start 
of the memory mapped by kernel D-space PAR #6

sim> examine 17772374
17772374:       016226

Offset of u_uid in struct user is 0242, so its physical memory address is:

016226 * 0100 + 0242 = 01623042

sim> examine 1623042
1623042:        000145
sim> examine 1623044
1623044:        000145
sim> examine 1623046
1623046:        000145

This indeed matches my uid (0145) repeated for svuid and ruid.

Even better (and this was my original proof of concept goal), setting 
those addresses to 0 provides root access.

$ id
uid=101(dds) gid=101 groups=101, 0(wheel)
$ while : ; do : ; done

Simulation stopped, PC: 040214 (BNE 40232)
sim> deposit 1623042 0
sim> deposit 1623044 0
sim> deposit 1623046 0
sim> cont

$ id
uid=0(root) gid=101 groups=101, 0(wheel)

One remaining puzzle is why doesn't this work when examining the 
kernel's virtual address.   I would expect to see again my user id below.

sim> examine -v -k -d -o 140242
140242: 000026


Diomidis

[TUHS] Accessing the PDP-11/70 MMU registers and the kernel's u area

[Diomidis Spinellis]

 From the 2.11 BSD sources I understand that the PDP-11/70 MMU address 
and data registers, KDSA and KDSD, start at 0172360 and 0172320 
respectively [1].  Yet, when I read the register contents I don't get 
what I would expect to see: increasing by 0200 memory values for KDSA 
and the same constant value for KDSD [2].  I checked this by looking at 
/dev/mem.

# od -o /dev/mem 0172360 | head -1
0172360  000002 000016 001403 012700 000400 000402 012700 000200

# od /dev/mem 0172320 | head -1
0172320  101016 005064 000026 005067 175456 016467 000006 175430

I get the same results when I examine the memory through SIMH:

sim> examine 172360
172360: 000002
sim> examine 172362
172362: 000016
sim> examine 172364
172364: 001403

sim> examine 172320
172320: 101016
sim> examine 172322
172322: 005064

The MMU kernel instruction registers, KISA and KISD, contain similarly 
nonsensical values as do the registers located at a different memory 
location (077320, 0772360) indicated in another source [3].  What am I 
missing?

My goal is to access from the console the kernel's u area.  According to 
mem(4) and the symbols in /unix, this should be at address 0140000. 
Indeed, accessing it through /dev/kmem I get the expected results for 
e.g. u_comm and u_uid.  However, I have been unable to find it in the 
machine's physical memory, hence my question regarding the MMU's operation.

[1] 
https://github.com/RetroBSD/2.11BSD/blob/master/usr/sys/pdpstand/M.s#L346
[2] 
https://github.com/RetroBSD/2.11BSD/blob/master/usr/sys/pdpstand/M.s#L247
[3] https://gunkies.org/wiki/PDP-11_Memory_Management

Diomidis