[9fans] which register is used as FP on the x86

[9fans] which register is used as FP on the x86

[ron minnich]

I'm trying to see which one is the FP. I thought the SP was the FP too but 
assembly code sez "nope" as far as I can tell. Anyone know?

ron

Re: [9fans] which register is used as FP on the x86

[rog]

no register is dedicated as a frame pointer.

if you know the PC, you can find out the FP from the SP.

Re: [9fans] which register is used as FP on the x86

[Andrew Lynch]

On Jun 25,  6:53pm, rog@vitanuova.com wrote:
> no register is dedicated as a frame pointer.
>
> if you know the PC, you can find out the FP from the SP.

Maybe not dedicated, in the sense that you can also use it for other stuff, but
the EBP register is intended to be used as FP:

"3. Stack-Frame Base Pointer (EBP) Register: The EBP register typically is used
to access data structures passed on the stack. [...] If the stack pointer is
copied into the base pointer before anything is pushed on the stack, the base
pointer can be used to reference data structures with fixed offsets. [...]
Instructions, such as ENTER and LEAVE instructions, are provided which
automatically set up the EBP register for convenient access to variables."

intel 386DX Microprocessor Programmer's Reference Manual 1990

Andrew.

P.S. If you have a gcc targeted for x86 you can see for yourself by comparing
the output of "gcc -S" with "gcc -fomit-frame-pointer -S".

Re: [9fans] which register is used as FP on the x86

[Latchesar Ionkov]

The Plan9 calling convention doesn't use BP as frame pointer.

	Lucho

PS. gcc -fomit-frame-pointer doesn't guarantee that no frame pointers will be
generated.

On Sat, Jun 26, 2004 at 01:56:04PM +0200, Andrew Lynch said:
> On Jun 25,  6:53pm, rog@vitanuova.com wrote:
> > no register is dedicated as a frame pointer.
> >
> > if you know the PC, you can find out the FP from the SP.
> 
> Maybe not dedicated, in the sense that you can also use it for other stuff, but
> the EBP register is intended to be used as FP:
> 
> "3. Stack-Frame Base Pointer (EBP) Register: The EBP register typically is used
> to access data structures passed on the stack. [...] If the stack pointer is
> copied into the base pointer before anything is pushed on the stack, the base
> pointer can be used to reference data structures with fixed offsets. [...]
> Instructions, such as ENTER and LEAVE instructions, are provided which
> automatically set up the EBP register for convenient access to variables."
> 
> intel 386DX Microprocessor Programmer's Reference Manual 1990
> 
> Andrew.
> 
> P.S. If you have a gcc targeted for x86 you can see for yourself by comparing
> the output of "gcc -S" with "gcc -fomit-frame-pointer -S".

Re: [9fans] which register is used as FP on the x86

[Charles Forsyth]

>>intel 386DX Microprocessor Programmer's Reference Manual 1990

``it is a mistake to use the manufacturer's special call instruction''
(or conventions, especially on a processor with so few `general-purpose' registers that
dedicating one to hold a value that is simply an offset from another
is downright wasteful)

Re: [9fans] which register is used as FP on the x86

[Latchesar Ionkov]

This approach doesn't work if the compiler supports variable length
arrays. Fortunately (or unfortunately, depending on your preferences)
the Plan9 compiler doesn't suport them.

Thanks,
    Lucho

On Fri, 25 Jun 2004 18:53:48 +0100, rog@vitanuova.com <rog@vitanuova.com> wrote:
> 
> no register is dedicated as a frame pointer.
> 
> if you know the PC, you can find out the FP from the SP.
> 
>

Re: [9fans] which register is used as FP on the x86

[Charles Forsyth]

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

the function that owns them knows it creates them,
and can modify its behaviour accordingly, rather
than pushing the requirement everywhere.

[-- Attachment #2: Type: message/rfc822, Size: 2864 bytes --]

From: Latchesar Ionkov <lionkov@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] which register is used as FP on the x86
Date: Sat, 26 Jun 2004 10:27:53 -0400
Message-ID: <f158dc6704062607275e56ba4e@mail.gmail.com>

This approach doesn't work if the compiler supports variable length
arrays. Fortunately (or unfortunately, depending on your preferences)
the Plan9 compiler doesn't suport them.

Thanks,
    Lucho

On Fri, 25 Jun 2004 18:53:48 +0100, rog@vitanuova.com <rog@vitanuova.com> wrote:
> 
> no register is dedicated as a frame pointer.
> 
> if you know the PC, you can find out the FP from the SP.
> 
>

[9fans] cpuserver: dhcp for authsrv, rio, users, ssh, factotum, pull

[Stephen Wynne]

I'm attempting to setup both a cpuserver and an authserver on
one system. I'd like it to be a terminal, too.

First, I more or less followed the advice on it at
http://www.cs.bell-labs.com/wiki/plan9/Configuring_a_Standalone_CPU_Server
while also looking at
http://pages.cpsc.ucalgary.ca/~mirtchov/lanlp9/4e/cpuauth.html

This may sound funny, but can I setup a CPU server, auth server,
and terminal all on the same system and have it all configure
itself dynamically based on a DHCP IP address?

Although my system worked just fine from the gnot install defaults,
after converting to a cpuserver,  I got this:

    RIO says: aux/vga: mga2164w: can't set mga type
    rio: can't open display: initdisplpay: /dev/draw/new: no framebuffer
    init: rc exit status: rc 12: rio 13: display open

Adding lines of display setup logic from from termrc didn't help.

I am unclear what passwords to assign to secstore and
bootes as I'm setting up the authserver for the first time.
I'm also unclear what the difference is between bootes
and other users I might create after this.

Also, SSH fails to connect now that I've rebooted and
setup bootes as the terminal "owner" (if that's the right term,
pardon my pun). I figure something must be haywire
in my authentication (Factotum?). Following instructions at
http://pages.cpsc.ucalgary.ca/~mirtchov/lanlp9/tips.html
I figured I should combine both authserver and terminal
instructions. I get:

    cpu% auth/secstore -p /tmp/factotum
    can't dial tcp!$auth!5356
    secstore authentication failed

Out of curiosity, I tried to do a pull to update my system.
That didn't work, either. I was running as bootes connected
through drawterm:

cpu% /usr/glenda/bin/rc/pull
post...
srv tcp!sources.cs.bell-labs.com!9fs: mount failed: authentication failed
bind: /n/sources/plan9: '/n/sources/plan9' does not exist
servermount: bind 363: bind
cpu% 9fs sources
srv tcp!sources.cs.bell-labs.com: mount failed: authentication failed

I apologize for asking so many questions at once, but there
doesn't seem to be a true cookbook recipe posted on just
how to do this with all the obvious steps included for mortals
like me.

One problem I hit was trying to setup fossil by default on this
system. There were exceptions to the flow of the normal KFS
setup that threw me off and I was in a hurry.

I have something else I want to do that I was almost able to do
with a plain KFS gnot install, so I'm tempted to just do it
over again and get back to that...

By the way, can I reboot a system from drawterm and how would I
do that?

My cpurc is at http://www.place.org/~stevemw/junk/cpurc
The ftpfs command is really handy!

Re: [9fans]

[andrey mirtchovski]

that's a long one! let's try step by step :)

> This may sound funny, but can I setup a CPU server, auth server,
> and terminal all on the same system and have it all configure
> itself dynamically based on a DHCP IP address?

there's no reason why not.  the only trick you'll need to take care of
is to configure the ndb properly in case the IP address of the machine
is constantly changing.  it won't be, would it?

so, by following the instructions on the wiki you should do something
like:

	- compile 9pcauth

	- edit /rc/bin/cpurc to dhcp an ip address, start auth/keyfs
	and start rio for the terminal part.

>
> Although my system worked just fine from the gnot install defaults,
> after converting to a cpuserver,  I got this:
>
>     RIO says: aux/vga: mga2164w: can't set mga type
>     rio: can't open display: initdisplpay: /dev/draw/new: no framebuffer
>     init: rc exit status: rc 12: rio 13: display open

copy the 'vga*' lines from /sys/src/9/pc/pcf to the kernel you're
compiling (/sys/src/9/pc/pcauth)

cpu server kernels by default have very few graphics cards compiled in.

> I am unclear what passwords to assign to secstore and
> bootes as I'm setting up the authserver for the first time.
> I'm also unclear what the difference is between bootes
> and other users I might create after this.
>

bootes (or any other user you dedicate as the cpu owner) will control
the resources on a particular machine.  bootes is just a conventional
(?) name bell-labs have adopted -- people in other places have chosen
other names for the cpu owners, and i myself used to boot under my own
user when i had a setup identical to yours (a single machine for
everything).  if you choose a diffferent name and want users to login
edit /lib/ndb/auth appropriately :)

when users log in to a Plan 9 installation their passwords are
verified by an 'auth/keyfs' on the AUTH server of that particular
installation.  those are the 'plan9' passwords.  on the other hand
when a user logs in they may decide to initialize their factotum with
passwords from the secstore.  secstore is just a convenient storage
for secrets (an encrypted file system if you wish) and has no role in
the interaction between machines in an installation.  you won't need a
secstore for your installation to work.

check the /sys/doc/auth.ps paper (also on Bell-Labs' site) for more
detailed information on the secstore/factotum pair.

> Also, SSH fails to connect now that I've rebooted and
> setup bootes as the terminal "owner" (if that's the right term,
> pardon my pun). I figure something must be haywire
> in my authentication (Factotum?). Following instructions at
> http://pages.cpsc.ucalgary.ca/~mirtchov/lanlp9/tips.html
> I figured I should combine both authserver and terminal
> instructions. I get:
>
>     cpu% auth/secstore -p /tmp/factotum
>     can't dial tcp!$auth!5356
>     secstore authentication failed

you'll need to have both auth/secstored and auth/factotum started.
secstored should be started from /rc/bin/cpurc, you can put
'auth/factotum' in your profile or just start it by hand.

also make sure your /lib/ndb/local has an 'auth=' entry for the subnet
you're in, here's an example:

	ipnet=hidden ip=192.168.0.0 ipmask=255.255.0.0
		proto=tcp
		cpu=plan9.ucalgary.ca
		fs=plan9.ucalgary.ca
		auth=plan9.ucalgary.ca
		authdom=plan9.ucalgary.ca
		dns=136.159.5.14
		dns=136.159.5.15

>
> Out of curiosity, I tried to do a pull to update my system.
> That didn't work, either. I was running as bootes connected
> through drawterm:
>
> cpu% /usr/glenda/bin/rc/pull
> post...
> srv tcp!sources.cs.bell-labs.com!9fs: mount failed: authentication failed
> bind: /n/sources/plan9: '/n/sources/plan9' does not exist
> servermount: bind 363: bind
> cpu% 9fs sources
> srv tcp!sources.cs.bell-labs.com: mount failed: authentication failed

that would indicate you have no auth/factotum started.


>
> I apologize for asking so many questions at once, but there
> doesn't seem to be a true cookbook recipe posted on just
> how to do this with all the obvious steps included for mortals
> like me.

it's like riding a bycicle -- once you do it you'll always know how
it's done :)

you're welcome to write a howto from your perspective (once everything
is done) and we'll put it on the wiki :)


> By the way, can I reboot a system from drawterm and how would I
> do that?

echo reboot > /dev/reboot

good luck: andrey

Re: [9fans]

[Stephen Wynne]

andrey mirtchovski wrote:

 > you won't need a secstore for your installation to work.

OK, I guess I don't need it for connecting with drawterm,
either. But apparently I need it for SSH and pulling
updates. I may also need it for other stuff. I'm running
an app that makes a call to auth_getuserpasswd() and it
fails now that I've tried to setup securestore; it used to
get past that point before.

 > check the /sys/doc/auth.ps paper (also on Bell-Labs'
 > site) secstore/factotum pair

Well, . Here's where I am now:

On my terminal via a drawterm connection (I haven't
recompiled for more GUI support yet), I'm following
http://pages.cpsc.ucalgary.ca/~mirtchov/lanlp9/tips.html
on setting up secstore.

The mkdirs were done before.  One small issue, factotum
wanted /adm/secstore/store/bootes/factotum/ (I think it
was).

 > on auth server:
 >
 >     auth/secstored
 >     mkdir /adm/secstore
 >     mkdir /adm/secstore/store
 >     mkdir /adm/secstore/who
 >     auth/secuser dpx
 >
 > on terminal:
 >
 >     touch /tmp/factotum
 >     auth/secstore -p /tmp/factotum
 >       ramfs -p; cd /tmp
 >     auth/secstore -g factotum
 >     secstore password:
 >     echo 'key proto=apop dom=x.com user=dpx \
 >             !password=y~1' >> factotum
 >     auth/secstore -p factotum
 >     secstore password:
 >     cat factotum > /mnt/factotum/ctl

This is where I'm still stuck.

 > you'll need to have both auth/secstored and
 > auth/factotum started.

I do, but there must be something else wrong. I found one
thing: my lib/ndb/local file still had localhost and
127.0.0.1 as the sys'name from my initial fumbling around
to get it online.

Now I get to the ramfs stage! However, secstore -g complains
about /tmp/factotum not existing. If I skip the
ramfs step, I see this:

    cpu% auth/secstore -g factotum
    secstore password:
    secstore
    implausible filesize for factotum
    secstore cmd failed

On the console of the PC, I see "implausible filesize -1
for factotum," but no information about which file is too
small.

This is what I have in /mnt/factotum:

    cpu% pwd
    /mnt/factotum
    cpu% cat ctl
    key proto=p9sk1 user=bootes dom=9net !hex? !password?
    cpu% ls -l
    -lrw------- M 48 bootes bootes 0 Jul  4 23:46 confirm
    --rw-r--r-- M 48 bootes bootes 0 Jul  4 23:46 ctl
    -lr-------- M 48 bootes bootes 0 Jul  4 23:46 log
    -lrw------- M 48 bootes bootes 0 Jul  4 23:46 needkey
    --r--r--r-- M 48 bootes bootes 0 Jul  4 23:46 proto
    --rw-rw-rw- M 48 bootes bootes 0 Jul  4 23:46 rpc

 > it's like riding a bycicle -- once you do it you'll
 > always know how it's done :)

I'm still trying to bolt on my training wheels, I think.
But thanks for your patience!

Re: [9fans]

[andrey mirtchovski]

> andrey mirtchovski wrote:
>
>  > you won't need a secstore for your installation to work.
>
> OK, I guess I don't need it for connecting with drawterm,
> either. But apparently I need it for SSH and pulling
> updates. I may also need it for other stuff. I'm running
> an app that makes a call to auth_getuserpasswd() and it
> fails now that I've tried to setup securestore; it used to
> get past that point before.

you don't need secstore for pulling from sources.  you don't need it
to ssh out from Plan 9, you don't even (necessarily) need it to ssh to
the Plan 9 machine (though you'll get a warning for the changed key
every time you reinitialize with auth/rsagen, i.e.  after a reboot).

in fact, secstore can be left as the last thing you setup, after
having made sure everything else works -- it's just a (very useful!)
convenience.

> The mkdirs were done before.  One small issue, factotum
> wanted /adm/secstore/store/bootes/factotum/ (I think it
> was).
>
>  > on auth server:
>  >
>  >     auth/secstored
>  >     mkdir /adm/secstore
>  >     mkdir /adm/secstore/store
>  >     mkdir /adm/secstore/who
>  >     auth/secuser dpx
>  >

did this succeed?

you've read the secstore(1) man page, i presume?  it basically
explains why the above steps should be taken (and why there should be
a chmod 770 somewhere in there too):

          Secuser is an administrative command that runs on the sec-
          store machine, normally the authserver, to create new
          accounts and to change status on existing accounts.  It
          prompts for account information such as password and expira-
          tion date, writing to /adm/secstore/who/$uid.  The
          /adm/secstore directory should be created mode 770 for the
          userid or groupid of the secstored process.

	[...]

          /adm/secstore/who/$uid secstore account name, expiration
          date, verifier
          /adm/secstore/store/$uid/ users' files

>  > on terminal:
>  >
>  >     touch /tmp/factotum
>  >     auth/secstore -p /tmp/factotum
>  >       ramfs -p; cd /tmp
>  >     auth/secstore -g factotum
>  >     secstore password:
>  >     echo 'key proto=apop dom=x.com user=dpx \
>  >             !password=y~1' >> factotum
>  >     auth/secstore -p factotum
>  >     secstore password:
>  >     cat factotum > /mnt/factotum/ctl
>
> This is where I'm still stuck.

so, what do you see (as the user who started secstored) in
/adm/secstore?  here's a sample from our machines:

	plan9# ls -l /adm/secstore/store/andrey
	--rw-rw---- M 4951 bootes bootes 696 Sep 15  2003 /adm/secstore/store/andrey/factotum
	plan9#

you should see a single file (factotum) if you've put it properly.
from what you gave above it looks like you're looking for a file named
'factotum' already existing in secstore, however when you initialize a
user's secstore there's absolutely nothing in it -- you need to put
the files there first.

>
> Now I get to the ramfs stage! However, secstore -g complains
> about /tmp/factotum not existing. If I skip the
> ramfs step, I see this:
>
>     cpu% auth/secstore -g factotum
>     secstore password:
>     secstore
>     implausible filesize for factotum
>     secstore cmd failed
>
> On the console of the PC, I see "implausible filesize -1
> for factotum," but no information about which file is too
> small.
>

secstore doesn't have any files in it by default, it just encrypts
whatever you decide to store in it.  usually that is a file suitable
for initializing your factotum.

it looks like you have a bad file in it, so all you need to do is
remove it and store it anew.  here's how to do it:

	% auth/factotum # hit enter on the 'secstore password' prompt
	% ramfs -p
	# you may wish to log in to a few places before the next step,
	# just to make sure you have as many passwords as you can
	# from the beginning. ssh to one or two machines, just for fun
	% cat /mnt/factotum/ctl > /tmp/factotum
	% cd /tmp
	# edit /tmp/factotum and change all question marks to the actual
	# passwords you use, for example if /mnt/factotum/ctl has:
	#	key proto=p9sk1 dom=plan9.ca user=somebody !password?
	# in /tmp/factotum it should appear as:
	#	key proto=p9sk1 dom=plan9.ca user=somebody !password=mypassword
	%
	# now simply add this file to the secstore:
	% auth/secstore -p factotum
	# and kill the ramfs session (^D)

and verify that the new password works by starting a new factotum and
attempting to login to one of the machines whose passwords you've
added to the factotum file in secstore.  if doing it for bootes you
may want to add the ssh server key there too (follow the ssh(1)
instructions)

andrey

Re: [9fans]

[Eric Grosse]

> From stevemw@place.org Mon Jul  5 00:08:24 EDT 2004
>    /adm/secstore/store/bootes/factotum/
>    "implausible filesize -1 for factotum"

Updated secstored.c on sources now logs the more useful message
   "/adm/secstore/store/bootes/factotum should be a plain file, not a directory"

The right fix would be for me to automate the initial configuration
of secstored, but this small code change will have to do for now.

Eric