Re: [9fans] Diskless cpu servers

Re: [9fans] Diskless cpu servers

[jmk]

Is there a security/crypto expert out there who knows
if there's a way for a server to hand out a chunk of
executable code then, when the code runs and calls back,
it can verify the code is running unchanged (i.e. no
local storage on the client system at all)? I'm very
naïve about security and my gut tells me no.

Some motherboards we bought recently were without
any reasonable places to put any non-rotating local
storage and ID/function to another machine would be a
pain.

The place where you want this (booting
a cluster) it's not really necessary as you can isolate
all the clients on their own physical net (he said
naïvely, not knowing much about that either).

--jim

Re: [9fans] Diskless cpu servers

[Dave Lukes]

jmk@plan9.bell-labs.com wrote:
>  Is there a security/crypto expert out there who knows if there's a
>  way for a server to hand out a chunk of executable code then, when
>  the code runs and calls back, it can verify the code is running
>  unchanged (i.e. no local storage on the client system at all)? I'm
>  very naïve about security and my gut tells me no.

In general, no.

If you have specific constraints, you may be able to,
but in the general case, your problem is the converse of another problem
I've just been looking at:
can you do serious crypto on a machine without _some_ form of permanent 
storage?
Ferguson and Schneier's "Practical Cryptography" says "no",
with reasoning, and I tend to believe them.

D.

[9fans] Diskless cpu servers

[Adriano Verardo]

Hi, all.

My i386 CPU servers have no magnetic/flash storage. The only solution I 
found to boot them
without human intervention has been to add the driver of a "fake" nvram.
It works but I'm not sure it's a good idea, because it entails to modify 
libauth
to insert the new device in the list searched by factotum, wrkey etc.
Instead,  I think it would be better to get the result only by adding 
files, without modifying the distribution.
A more elegant solution with no consequences on the normal update 
activity by replica/pull.

Did  anyone face the same boot problem in the past ?
Any suggestion ?

Thanks in advance

Adriano

Re: [9fans] Diskless cpu servers

[andrey mirtchovski]

i've modified libauth to add a cmos device as nvram in the past... you
can just go with it and not worry about sending a patch, unless you
think it's valuable :)

Re: [9fans] Diskless cpu servers

[Adriano Verardo]

andrey mirtchovski wrote:

> i've modified libauth to add a cmos device as nvram in the past... you
> can just go with it and not worry about sending a patch, unless you
> think it's valuable :)
>
>
The solution I found its really trivial. Instead, the problem I'm dealig 
with could be interesting
for the community.

I think that Plan9 could be effectively used in industrial automation 
systems
to coordinate leaf nodes devotes, for example, to data acquisition.
There are many situations in which real time is not a true constraint.
Thanks to the Plan9 design  it  should be  easier  to share  
information  among
graphical monitoring stations etc etc etc.

The typical scenario is: many very small (486/P100) acq. (leaf) nodes, 
mix of
new and obsolete HW, strict constraint about budget, ....

So I built a cluster of very small (chep and old) CPUs (motherboards+acq 
dev+eth)
and I'm trying to have them up and running just turning them on without 
human intervention
(they could be a lot and distributed in a large area) and downloading a 
small Plan9.

I would like not to have many customized kernels. Probably to have the
nvram info embedded in the kernel, in such a particular scenario, could be
a good solution.

I'm also looking at Plan9 as a platform for distributed computing on
a company network. Really some of my clients have networks of
hundreds of modern PCs that don't work in the night ...

But this is another story

Adriano

Re: [9fans] Diskless cpu servers

[Ronald G Minnich]

Adriano Verardo wrote:
> Hi, all.
> 
> My i386 CPU servers have no magnetic/flash storage. The only solution I 
> found to boot them
> without human intervention has been to add the driver of a "fake" nvram.
> It works but I'm not sure it's a good idea, because it entails to modify 
> libauth
> to insert the new device in the list searched by factotum, wrkey etc.
> Instead,  I think it would be better to get the result only by adding 
> files, without modifying the distribution.
> A more elegant solution with no consequences on the normal update 
> activity by replica/pull.
> 
> Did  anyone face the same boot problem in the past ?
> Any suggestion ?
> 
> Thanks in advance
> 
> Adriano
> 

on the geodes I just added the entry to have it look at #r/nvram. Worked 
fine. I lost the patch, but it was trivial.

You may not have room in your CMOS, depending on what your fuctory bios 
does with it.

ron

Re: [9fans] Diskless cpu servers

["Nils O. Selåsdal"]

Ronald G Minnich wrote:
> Adriano Verardo wrote:
>> Hi, all.
>>
>> My i386 CPU servers have no magnetic/flash storage. The only solution 
>> I found to boot them
>> without human intervention has been to add the driver of a "fake" nvram.
>> It works but I'm not sure it's a good idea, because it entails to 
>> modify libauth
>> to insert the new device in the list searched by factotum, wrkey etc.
>> Instead,  I think it would be better to get the result only by adding 
>> files, without modifying the distribution.
>> A more elegant solution with no consequences on the normal update 
>> activity by replica/pull.

Would this be of any help ?

cpu% man plan9.ini|grep nvram
         nvram=file
           This is used to specify an nvram device and optionally the

Re: [9fans] Diskless cpu servers

[Ronald G Minnich]

Nils O. Selåsdal wrote:
> Ronald G Minnich wrote:
> 
>> Adriano Verardo wrote:
>>
>>> Hi, all.
>>>
>>> My i386 CPU servers have no magnetic/flash storage. The only solution 
>>> I found to boot them
>>> without human intervention has been to add the driver of a "fake" nvram.
>>> It works but I'm not sure it's a good idea, because it entails to 
>>> modify libauth
>>> to insert the new device in the list searched by factotum, wrkey etc.
>>> Instead,  I think it would be better to get the result only by adding 
>>> files, without modifying the distribution.
>>> A more elegant solution with no consequences on the normal update 
>>> activity by replica/pull.
> 
> 
> Would this be of any help ?
> 
> cpu% man plan9.ini|grep nvram
>         nvram=file
>           This is used to specify an nvram device and optionally the

yes, but the issue we hit here was that you can't really use all of 
CMOS.  The first <xy> bits are used for other things. So you have to 
fiddle a bit.

ron

Re: [9fans] Diskless cpu servers

[Charles Forsyth]

> yes, but the issue we hit here was that you can't really use all of 
> CMOS.  The first <xy> bits are used for other things. So you have to 
> fiddle a bit.

there are several other environment variables:

        nvram=file
        nvrlen=length
        nvroff=offset
          This is used to specify an nvram device and optionally the
          length of the ram and read/write offset to use.  These val-
          ues are consulted by readnvram (see authsrv(2)). The most
          common use of the nvram is to hold a secstore(1) password
          for use by factotum(4).

Re: [9fans] Diskless cpu servers

[Ronald G Minnich]

Charles Forsyth wrote:
>>yes, but the issue we hit here was that you can't really use all of 
>>CMOS.  The first <xy> bits are used for other things. So you have to 
>>fiddle a bit.
> 
> 
> there are several other environment variables:
> 
>         nvram=file
>         nvrlen=length
>         nvroff=offset
>           This is used to specify an nvram device and optionally the
>           length of the ram and read/write offset to use.  These val-
>           ues are consulted by readnvram (see authsrv(2)). The most
>           common use of the nvram is to hold a secstore(1) password
>           for use by factotum(4).
> 

yes, these did not ever work terrifically well for me IIRC. I ended up 
just changing the driver ...

ron

Re: [9fans] Diskless cpu servers

[Charles Forsyth]

> yes, these did not ever work terrifically well for me IIRC.

if you're trying to use bits and pieces of existing cmos
(ie, the apparently available bits are scattered), they won't help

Re: [9fans] Diskless cpu servers

[Ronald G Minnich]

Charles Forsyth wrote:
>>yes, these did not ever work terrifically well for me IIRC.
> 
> 
> if you're trying to use bits and pieces of existing cmos
> (ie, the apparently available bits are scattered), they won't help
> 

you have to look and look, and build a contiguous bit string from the 
pieces. Easier on linuxbios machines; we use very little cmos. fuctory 
bios machines are all over the place in CMOS.

ron

Re: [9fans] Diskless cpu servers

[Adriano Verardo]

Nils O. Selåsdal wrote:

> Ronald G Minnich wrote:
>
>> Adriano Verardo wrote:
>>
>>> Hi, all.
>>>
>>> My i386 CPU servers have no magnetic/flash storage. The only 
>>> solution I found to boot them
>>> without human intervention has been to add the driver of a "fake" 
>>> nvram.
>>> It works but I'm not sure it's a good idea, because it entails to 
>>> modify libauth
>>> to insert the new device in the list searched by factotum, wrkey etc.
>>> Instead,  I think it would be better to get the result only by 
>>> adding files, without modifying the distribution.
>>> A more elegant solution with no consequences on the normal update 
>>> activity by replica/pull.
>>
>
> Would this be of any help ?
>
> cpu% man plan9.ini|grep nvram
>         nvram=file
>           This is used to specify an nvram device and optionally the
>
>
The .ini file is downloaded by  9pxeload (/cfg/<macaddr>) .

I could add

     nvram= #Z/fknvram
     nvrlen=...
     nvroff=...

in the ini files and choose a driver letter not used for i386 (instead 
of 'Z').
This way I could restore the original libauth etc

Correct ?

Adriano

Re: [9fans] Diskless cpu servers

[Federico G. Benavento]

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

I just remembered about this:
http://rs-rlab.narod.ru/9nvram.html

Federico G. Benavento

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

From: Adriano Verardo <a.verardo@tecmav.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Diskless cpu servers
Date: Fri, 09 Jun 2006 15:42:16 +0200
Message-ID: <44897AB8.1070304@tecmav.com>

Nils O. Selåsdal wrote:

> Ronald G Minnich wrote:
>
>> Adriano Verardo wrote:
>>
>>> Hi, all.
>>>
>>> My i386 CPU servers have no magnetic/flash storage. The only 
>>> solution I found to boot them
>>> without human intervention has been to add the driver of a "fake" 
>>> nvram.
>>> It works but I'm not sure it's a good idea, because it entails to 
>>> modify libauth
>>> to insert the new device in the list searched by factotum, wrkey etc.
>>> Instead,  I think it would be better to get the result only by 
>>> adding files, without modifying the distribution.
>>> A more elegant solution with no consequences on the normal update 
>>> activity by replica/pull.
>>
>
> Would this be of any help ?
>
> cpu% man plan9.ini|grep nvram
>         nvram=file
>           This is used to specify an nvram device and optionally the
>
>
The .ini file is downloaded by  9pxeload (/cfg/<macaddr>) .

I could add

     nvram= #Z/fknvram
     nvrlen=...
     nvroff=...

in the ini files and choose a driver letter not used for i386 (instead 
of 'Z').
This way I could restore the original libauth etc

Correct ?

Adriano

Re: [9fans] Diskless cpu servers

[Steve Simon]

Some people have used IDE flash cards in CPU/auth nodes 
to make them at least rotating disk less if not actually
network booting. You could keep the net boot and just store
an nvram partition on the flash card.

For part numbers check the 9fans archives.

-Steve

Re: [9fans] Diskless cpu servers

[Charles Forsyth]

you can set the nvram environment variable (eg, in plan9.ini) to the
name of the nvram file, so you don't need to change libauthsrv source

it wasn't clear where your system got its plan9.ini file though.
presumably you haven't got even a diskette drive.
are you booting over ether?

Re: [9fans] Diskless cpu servers

[Adriano Verardo]

Charles Forsyth wrote:

>you can set the nvram environment variable (eg, in plan9.ini) to the
>name of the nvram file, so you don't need to change libauthsrv source
>
>it wasn't clear where your system got its plan9.ini file though.
>presumably you haven't got even a diskette drive.
>are you booting over ether?
>
>
>
>  
>
Yes. I use Etherboot burned on the NICs EPROMS and a patched version
of 9pxeload. The CPUs boot from the file server as usual.
The "nvram" is just a statically initialized char[] in the downloaded 
kernel.

Adriano

Re: [9fans] Diskless cpu servers

[Ronald G Minnich]

Steve Simon wrote:
> Some people have used IDE flash cards in CPU/auth nodes 
> to make them at least rotating disk less if not actually
> network booting. You could keep the net boot and just store
> an nvram partition on the flash card.
> 
> For part numbers check the 9fans archives.

we've had good luck here with magicram IDE-FLASH parts.

ron

Re: [9fans] Diskless cpu servers

[Adriano Verardo]

Thank you very much for all suggestions.
Specifying nvram/nvrlen/nvroff in the .ini files
I can use use my nvram emulator driver
with the original distribution.

Adriano

>
>
>