, SteveRichter wrote

*snip*

well, then do a better job at it. I am not convinced you cannot have a virus free system.  for example, a system should always be talking to the OS producer, making sure that all of the binaries match what the producer installed on the system.

Viruses don't require a binary to run. They just require control of execution. The iPhone since iOS 2, for example, does exactly what you say, but even more so. Every page of executable code in memory must be digitally signed back to Apple (and dynamic code and JITs are verboten). And yet iPhone jailbreaks are not hard to come by, allowing people to run code that Apple didn't sign. (If you think that code != data, then I suggest you read up on ROP/ret-to-lib-c attacks, and if you think that your OS will verify all data, then you will have a very limited OS).

Also, writing security-bug free code is hard. The following, for example is a critical (i.e. an RCE) security bug if an attacker can control the data in either buffer:

HRESULT mergeBuffers(
  __in const void* buf1,
  __in DWORD cbBuf1,
  __in const void* buf2,
  __in DWORD cbBuf2,
  __out void** result,
  __out DWORD* cbResult)
{
  DWORD cbTotalSize;
  void* tmp;

  *cbResult = 0;
  *result = NULL;

  cbTotalSize = cbBuf1 + cbBuf2;
  tmp = malloc(cbTotalSize);
  if(tmp == NULL)
    return E_OUTOFMEMORY;
  memcpy(tmp, buf1, cbBuf1):
  memcpy( ((char*)tmp) + cbBuf1, buf2, cbBuf2);

  *result = tmp;
  *cbResult = cbTotalSize;
  return S_OK;
}

Even in non-native languages, writing secure code is hard. That's why it's possible to persuade so many websites to give you their inner-most secrets by just providing them with malformed data. A SQL injection, for example is a case-in-point where a managed language runs attacker controlled code without ever first requiring a "virus" to be installed on the website.