On 7/18/2012 9:14 PM, John Nilsson wrote:
Random as in where it's applied or random in what's applied?
I was thinking that the viral part was a means to counter the seeming
randomness in an otherwise chaotic system. Similar in spirit in how
gardening creates some amount of order and predictability, a gardener
who can apply DNA tweaks as well as pruning.
As I understand it CFEngine does something like this wile limited to
"simple" configuration.
it is not clear to me what the exact intention of this use of randomness
is for, but security comes to mind as a partial application.
there is a lot that could probably be done already regarding the use of
randomization and recombination to increase the security of software,
yet it is not widely used for whatever reason.
for example, if both the address space and image layouts were
randomized, traditional buffer-overflow exploits would become largely
ineffective.
another issue though is that, very often, it is high-level aspects of
the software which are being exploited.
for example, I recently read some about security exploits which had been
going on in the login servers for a game, where a minor issue
(apparently involving operator precedence or similar) had resulted in
people being able to do a hacked login by using a valid (but different)
login to connect initially, and then swapping out for a different
user-account name (the server didn't notice that the user-name was being
substituted, and so would act as if this other user had logged in to the
server).
now, could randomization help with this? this is much less certain.
similar also goes for cases where the software technically works
as-written (or designed), but this design is itself flawed (and so can
be exploited).
now, potentially, someone could try combining genetic programming with
unit tests, say, there are servers off somewhere basically grinding
against the code, randomly mutating it in various ways, but still
accepting whatever variants manage to still pass the unit test.
maybe elsewhere, there could be servers (probably running on the same
physical hardware) designed mostly to run "assault tests", essentially
off feeding the first servers bad data, basically trying to find ways to
"crack" or otherwise compromise the first sets of programs.
say:
server A, mutates program, favoring options which:
still pass unit tests;
successfully resists attacks by server B (other causing crashes, or
gaining unauthorized access).
server B, tries to breed up attack programs to use against server A,
favoring options which are successful.
this is partly based on the observation that genetic programs are are
least moderately good at breaking things and finding ways to cheat at
tests (a lot of testing is often needed trying to fiddle with and
"harden" the test itself).
I guess this is basically analogous to a more advanced case of
"randomized adaptive stress testing" (or "hardening"), where basically
the stress-tester logic feeds garbage loads at the code in question, and
may involve limited feedback logic (such as trying to adapt parameters
in the direction of worse performance, or maybe just to weed out cases
where crashing is likely).
I have done testing of this sort to some extent in the past, but, sadly,
my codebase is far to large and complicated to be reasonably tested in
this way (far more often, I use hands-on interactive testing, often
aided somewhat by interactive use of my scripting language).
most of my past tests had involved basically specialized bytecode or
string-code formats, though a possibility could be to attempt to use a
(functionally limited) abstraction over HLL syntax (maybe or maybe not
token based, possibly also operator based), which could (potentially)
result in more readable and/or usable output (for example, the output
could be spit out as C or JS code or similar).
some of this sort of stuff could potentially be applied to game AIs
(such as behavioral adaptation for NPCs), but thus far I have not
personally done anything like this (others have done things like this
though IIRC), partly as there isn't really any clear gain (gameplay
wise) from doing so (at best, it would probably just make them harder to
kill, as there is no good way to tune them for something like "player is
having the most fun"). likewise this, in turn, leads mostly to
interactive tuning
I make a lot of use of randomness for smaller things though.
BR,
John
On Thu, Jul 19, 2012 at 3:55 AM, Pascal J. Bourguignon
<[email protected]> wrote:
Joke apart, people are still resiting a lot to stochastic software.
One problem with random spreading of updates is that its random.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
