what exactly does it mean when a processor advertises enhanced virus protection?

Discussion in 'OT Technology' started by dorkultra, May 6, 2008.

  1. dorkultra

    dorkultra OT's resident crohns dude OT Supporter

    Joined:
    Oct 14, 2005
    Messages:
    22,736
    Likes Received:
    27
    Location:
    yinzer / nilbog, trollhio
  2. trouphaz

    trouphaz New Member

    Joined:
    Sep 22, 2003
    Messages:
    2,666
    Likes Received:
    0
    i think it means that it is now supported by OSX. :p
     
  3. dissonance

    dissonance reset OT Supporter

    Joined:
    May 23, 2006
    Messages:
    5,652
    Likes Received:
    1
    Location:
    KS
    aka "Execute Disable Bit" -- Provides enhanced virus protection when deployed with a supported operating system and prevents the code from infecting the system. Memory can be marked as executable or non-executable, allowing the processor to raise an error to the operating system if malicious code attempts to run in non-executable memory.

    AMD advetised it to a bit ago and said theirs would "be enabled with Windows XP SP2"
     
  4. Doomsday

    Doomsday XXX

    Joined:
    Mar 14, 2000
    Messages:
    14,902
    Likes Received:
    0
    Location:
    Minnesota
    .

    Intel calls it XD bit, AMD calls is NX bit
    same shit
     
  5. solarian

    solarian ya heard

    Joined:
    Jan 12, 2006
    Messages:
    4,897
    Likes Received:
    0
    Location:
    Bay Area, CA
    OSX isn't Virus/hack proof you fool.

    if OSX was on every computer like Microsoft it would have the same problems.
     
  6. trouphaz

    trouphaz New Member

    Joined:
    Sep 22, 2003
    Messages:
    2,666
    Likes Received:
    0
    oh shut the hell up. i was making a joke.
     
  7. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    The funny thing is, the only reason viruses can infect computers via cheap tricks like buffer-overflow exploits in the first place is because Someone von Neumann said it would be cool if data and executable instructions were stored in the same memory in the same format. So now we have to use special codes to distinguish data and instructions from each other, which pretty much is the really really really long way around to get the same thing as what a non-von-Neumann computer is to start with.
     
  8. Ameter

    Ameter Active Member

    Joined:
    Mar 31, 2005
    Messages:
    97,795
    Likes Received:
    1
    Location:
    Calgary, AB
    umm... It's far, far better to use the same RAM for data and code. Why? Because it would suck to have separate RAM banks for code and data, and have unused RAM in your code when you need more for data, or vice-versa
     
  9. Ameter

    Ameter Active Member

    Joined:
    Mar 31, 2005
    Messages:
    97,795
    Likes Received:
    1
    Location:
    Calgary, AB
    oh, and as for format, what format? 1s and 0s? You mean we can have a different format for data as we do code?
     
  10. GOGZILLA

    GOGZILLA Double-Uranium Member

    Joined:
    Jan 16, 2003
    Messages:
    10,760
    Likes Received:
    3
    Location:
    Plantation, FL
    this reply should be good
     
  11. deusexaethera

    deusexaethera OT Supporter

    Joined:
    Jan 27, 2005
    Messages:
    19,712
    Likes Received:
    0
    I'm not saying there aren't advantages to von Neumann computer systems, I'm saying security isn't one of them.

    1. Yes, it's space-efficient to use the same RAM for code and data. I'm not arguing that point.

    2. By "format" I meant the method used for allocating memory (and recording those allocations for future reference), specifically the use of a starting location and a length, without any markers to indicate what the memory is being used for to any process other than the memory allocator itself.

    By itself, neither of those is a security risk; it's the combination of the two that poses the problem, as evidenced by any number of thousands of buffer-overflow exploits that intentionally request memory arrays right next to executable code, and then write data into (and past the end of) those arrays to disguise the replacement of legitimate code with malicious code as being a simple memory leak. There are two solutions to this problem:

    1. Segregate the RAM used for code and data, which as you pointed out is space-inefficient;

    2. Mark blocks of allocated RAM according to their usage (i.e. "change the format", as I ineptly described it before), which is time-inefficient instead, due to the extra processing needed to check each block of RAM to make sure it's supposed to be executable before executing it.

    Now that one of those two methods has been implemented on a wide scale, the von Neumann self-mutating-machine problem is solved, to a certain extent at least. I was just marveling how the whole point of using the von Neumann architecture was to get away from restrictive memory-allocation protocols, and necessity has nonetheless forced us to come full-circle and implement them all over again.
     

Share This Page