🚀 go-pugleaf

>        Any time later, I can generate a new list and compare.  It is
> then up to me to decide whether any differences that show up are
> legitimate - but I have the absolute assurance that I WILL get an
> indication of any changes.

Sure, and that's certainly a good first step.  But I still claim that
it isn't by any means a universal virus detector, and would not solve
the virus problem, because the thing that is "up to you" is just too
hard.  The system can tell you that only files that you expect to have
changed have changed, but it *can't* tell you that they've changed
only in innocent ways.  That's one of the largest problems of virus
protection; the system can't in general tell, and certainly can't tell
down below the "which file was changed" level, which modifications to
the executable-set were intended by the user, and which were not.  A
system like this might catch any viruses that we know of today; on the
other hand, if it became widespread, viruses that it would not catch
(or, more accurately, that a human using it would not catch) would
shortly appear.

> Another alternative is to add another bit, the "may create
> executables" bit.  Only code running from a block marked with this bit
> may turn on the "executable" bit for another block.  Normally, only
> the linker and an image copier would have this bit set.  A virus could
> still be written - but it couldn't modify existing code directly, it
> would have to produce object code and pass it through the linker.

Or it could create the object that it wanted, and call the copy
utility.  Or is it impossible for a program to copy a non-executable
thing to an executable thing?  That would help a little, but would
also make the system less convenient to use.  How do you get a new
copy of the linker?  How do you write a patch program?

Don't get me wrong: I think these are all good ideas for future,
more virus-hardened systems.   I just want to point out that,
even if implemented perfectly, they don't make the problem go
away...

DC