Very Computer

I previously wrote an init program for advanced CD booting.  It was the
only file in initrd, it set up ramfs, found the boot CD, mounted the CD,
loaded a tar file into ramfs, and pivoted the ramfs to be the root fs.
This expanded the limits of what can be loaded in ram from a CD to the
lesser of your available ram or the CD space to put the tar file.  It
could have even used compression, though I didn't go that far this time.

What I am thinking about now is a similar thing for a hard drive based
system.  Part of the idea came from seeing how the Ascend GRF-400 router,
which was FreeBSD based, loaded everything from flash RAM.  My idea is
to have the partition which the kernel initially mounts read-only as
root contain /dev/console and /sbin/init which will have my init code.
My code will then set up the ramfs, find the files to be preloaded, then
pivot the ramfs to be the root fs and execve() to the loaded /sbin/init.
The source files to be loaded could come from a number of places, such
as the same partition or a different one, and as a tree of files or as a
tar file.

There are a couple of intentions that get me thinking about this.

One thought is that some things would just be faster if they are in ram,
and this is one sure way to get them in ram.  Given that many systems
have a lot of ram these days, loading 8 to 32 meg of stuff into ram
wouldn't be all that much of a hit.  It would depend on the judgement of
the administrator if they want to take advantage of it, and just how much.

Another thought is a simple layer of security aspect to it.  While it sure
won't be resistant to sophisticated attacks, many times the holes the
crackers do find somewhere aren't big enough for anything but very trivial
initial attacks.

And this could surely help prevent some disasterous accidents where critical
system startup files get clobbered.  If the ram preload alone can get the
system up, networked, and running sshd, then anything else that can be
repaired remotely, or possibly even automatically repaired.

What are you thoughts on this?

I was looking at how ramfs was implemented, and am left wondering if there
are any issues in doing things like memory mapping files from ramfs.  That
could have an impact on library usage if there are issues.  For example,
does CoW work right for files memory mapped from ramfs?  What would happen
if a CoW was needed for a library mapped from ramfs when swap was full?
Would it be a graceful process kill, or would the system seize up?

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------

I wouldn't expect much gain, I would expect the frequently used files
to reside in cache.

Quote:

> Another thought is a simple layer of security aspect to it.  While it sure
> won't be resistant to sophisticated attacks, many times the holes the
> crackers do find somewhere aren't big enough for anything but very trivial
> initial attacks.

I don't see how this would create any new security holes. Of course you
must use proper permitions, the image from which you fill the ramfs
must not be readable or writeable by anybody but root.

Quote:

> And this could surely help prevent some disasterous accidents where critical
> system startup files get clobbered.  If the ram preload alone can get the
> system up, networked, and running sshd, then anything else that can be
> repaired remotely, or possibly even automatically repaired.

That will surely minimize the risk of disasters. If in addition you
choose to keep your image on a partition that is usually only mounted
read only, you will be very good protected. Whether /boot or another
partition is most appropriate probably is a question about taste.

Quote:

> What are you thoughts on this?

> I was looking at how ramfs was implemented, and am left wondering if there
> are any issues in doing things like memory mapping files from ramfs.  That
> could have an impact on library usage if there are issues.  For example,
> does CoW work right for files memory mapped from ramfs?  What would happen
> if a CoW was needed for a library mapped from ramfs when swap was full?
> Would it be a graceful process kill, or would the system seize up?

Since ramfs does not stop you from writing when the system is out of
memory it can create holes for DoS attacks. Don't let anybody but
root write to ramfs. Can we expect this to get fixed some day? Ramfs
was mostly meant to be an example of how to write filesystems. OTOH
I don't think you would be able to crash the system by executing
programs from ramfs, anyway it wouldn't be hard to test that in a
nonproduction environment.

--
Kasper Dupont

|> One thought is that some things would just be faster if they are in ram,
|> and this is one sure way to get them in ram.  Given that many systems
|> have a lot of ram these days, loading 8 to 32 meg of stuff into ram
|> wouldn't be all that much of a hit.  It would depend on the judgement of
|> the administrator if they want to take advantage of it, and just how much.
|
| I wouldn't expect much gain, I would expect the frequently used files
| to reside in cache.

How does one go about setting up a means to keep them in ram?  They do get
swapped out a lot.

|> Another thought is a simple layer of security aspect to it.  While it sure
|> won't be resistant to sophisticated attacks, many times the holes the
|> crackers do find somewhere aren't big enough for anything but very trivial
|> initial attacks.
|
| I don't see how this would create any new security holes. Of course you
| must use proper permitions, the image from which you fill the ramfs
| must not be readable or writeable by anybody but root.

Or crackers who gain root.  But that's a more classic security issues.

|> And this could surely help prevent some disasterous accidents where critical
|> system startup files get clobbered.  If the ram preload alone can get the
|> system up, networked, and running sshd, then anything else that can be
|> repaired remotely, or possibly even automatically repaired.
|
| That will surely minimize the risk of disasters. If in addition you
| choose to keep your image on a partition that is usually only mounted
| read only, you will be very good protected. Whether /boot or another
| partition is most appropriate probably is a question about taste.

Or not even mounted, or over the network.

|> What are you thoughts on this?
|>
|> I was looking at how ramfs was implemented, and am left wondering if there
|> are any issues in doing things like memory mapping files from ramfs.  That
|> could have an impact on library usage if there are issues.  For example,
|> does CoW work right for files memory mapped from ramfs?  What would happen
|> if a CoW was needed for a library mapped from ramfs when swap was full?
|> Would it be a graceful process kill, or would the system seize up?
|
| Since ramfs does not stop you from writing when the system is out of
| memory it can create holes for DoS attacks. Don't let anybody but
| root write to ramfs. Can we expect this to get fixed some day? Ramfs
| was mostly meant to be an example of how to write filesystems. OTOH
| I don't think you would be able to crash the system by executing
| programs from ramfs, anyway it wouldn't be hard to test that in a
| nonproduction environment.

I'm thinking more along the lines of issues like mroe memory being needed
when some process modified a mapped page triggering CoW.  My understanding
of it is that when the modification occurs, the modifying process gets the
page that's in ram, and other processes sharing the data but nor sharing
changes, get "detached" from that copy, and effectively "see" their mapping
as being on backing store.  But what happens when memory mapping from ramfs
(or ramdisk)?  Is the memory mapping letting the process have literal access
(read only) to the ram that ramfs (or ramdisk) occupies?  I would hope so,
or else many advantages disappears.  But CoW would have to work different in
this case.  Instead of giving the modifying process the original page and
detaching other processes, it has to make a new copy for the modifying
process, which would become a swappable copy (right?).  Now what if all
the space is used up, including swap, right then?  Kill process?

--
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |

-----------------------------------------------------------------