bgiles@dimensional.com (Bear Giles):
> > > 1) it greatly simplifies some types of embedded system development.
> > > The embedded system is designed to use a SCSI disk, but during
> > > development the internal disk is replaced with an external host,
> > > typically a developer's workstation. This totally eliminates
> > > hassles downloading new files, uploading log files, etc.
> >
> > It's a lot of extra work... I think that could be done with a dual attached
> > SCSI - when updates are to be made the disk is synced/unmounted from the
> > test system, mounted/fscked and mounted by the development, update made
> > dismounted, test system booted. Most of this could be automated via scripts.
>
> But that approach doesn't allow the embedded software to write to a
> log file, with the programmer watching that log with "tail -f". I
> actually used a system like this in 1990 or so, under Interactive Unix
> with a driver another employee wrote (I think), and it was pretty nice.
> I definitely recall pressing buttons on the embedded device and seeing
> the log events immediately appear.
true - but the disk caching that is needed to do even minimal optimization
of buffers will prevent that. Now if the log is done like syslog, then
it is more like a network connection and less of a SCSI connection.
> BTW, I believe that the approach he used was far closer to NFS than an
> attempt to faithfully emulate a hard disk. But I don't know enough of
> the details of his design, or UFS(?) file systems, to be sure. As a
> developer I simply knew that the embedded device acted like my home
> directory was local to it in every way... and we attached the device
> via the SCSI port (with the embedded device acting as master).
>
> > > 2) the same approach can be used for stealth monitoring of extremely
> > > sensitive systems. An attacker would only see a SCSI hard disk -
> > > there is absolutely no way to know that this "disk" is actually
> > > physically located and controlled by another system. The standard
> > > driver would allow the monitoring system to continually cross-check
> > > active and reference files. A somewhat more adventurous driver
> > > could implement a type of data logging - the attacker may think
> > > he's deleting files, but it monitoring system will retain a complete
> > > record.
> >
> > This shoulds possible, but there might be a tremendous amount of overhead.
> > The monitoring system would have to know about the file system (obvious),
> > but it would be duplicating the activity of the real host:
> >
> > [elided]
>
> See above. Also, I think you're overstating the problems with this
> approach. The embedded system has to know how to maintain a file system,
> but it can be something pretty standard like Minix, UFS, or (ugh) DOS.
> The host can map the SCSI requests to an existing partition or file,
> and still allow the host access via either regular mounts or the loopback
> modules.
>
> The only real problem is caching. If neither system caches the FS
> metainformation both should be able to write to it. If only one
> doesn't cache, it can still mount it read-only.
Nope - not all the meta data would be updated at the same time - neither
is the other system fully aware of the updates - some optimization allows
the data buffers to remain in memory (both meta data bitmap and real data)
while muliple updates to metadata is completed. Then the meta data is
written out, but not the real data blocks. Some time later the real
data gets flushed.
Again this was the approach for emulating a disk.
>
> > 2. To maintain an audit (and recoverable...) the modifications would
> > have to be saved in a journal.
>
> You're thinking in terms of a FS. Don't. All you really need is
> something that listens to the SCSI device and accepts "write" and
> "read" requests associated with an index. The "journaling" could
> be nothing more than a huge circular queue with the following
> information:
>
> time, block, old block, new block
>
> This structure isn't practical for FS journaling applications because
> it provides no guarantee that the FS structure is uncorrupted - or even
> that you'll be able to back out an arbitrary number of changes. However
> it is enough that you can rollback the disk image to an arbitrary time
> within the last N hours (N depending on usage, of course). You could
> even set up a modified reader that gives you access to the FS as it
> appeared at any time, although there will be obvious performance problems.
You're right - I was thinking of emulating a disk. If you think of it as
just a communications path then this doesn't apply. I had done something
similar using a parallel interface to pass program loads into an embeded
system once.
> This would be a performance nightmare on a heavily used system, but
> I'm thinking this might be a good solution on systems with high profile
> but relatively few writes - firewalls, KDCs, etc.
>
> Finally, let me emphasize that I'm not suggesting this is THE solution
> to any problem, or even A solution to most. It's much more an advanced
> trick that might allow you to perform the impossible in certain highly
> unusual circumstances - something akin to the unusual wiretap arrangement
> mentioned in _Cookoo's Egg_.
But that would go back to the "emulating a disk" since this is tapping
into the host <-> disk communications.
I had though of it as a possible foundation for a cluster server -
Several Linux systems, each acting as a RAID 5 + controller with the
ability to fan out disk blocks to multiple real disks or over fibre
channel connections; and still provide the appearance of a simple SCSI
disk to a computational host.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:16 EST