Re: "Perfect" or "Provable" security both crypto and non-crypto?

From: Bryan Olson (bryanjugglercryptographer_at_yahoo.com)
Date: 09/15/04 

Date: 15 Sep 2004 10:43:33 -0700

Lassi Hippeläinen wrote:
> But it is possible to provide some help at the hardware level.
>
> New processor designs from Intel and AMD implement a hardware sandbox
> that separates executable code from non-executable data. (I haven't
> checked the details, but this sounds like an age-old idea from the days
> of segmented memories...) The sandbox traps the attacks that put evil
> code in the input buffer and then smash the stack. The new Windows XP
> SP2 includes support for the feature.

Truth is stranger than fiction. The Intel X86 series has, from
its beginning with the 8086/8088, addressed it's stack and code
from a from separate segments based on CPU registers. When they
went 32-bit with the 386, they added a more modern paged memory
management unit, while also keeping and extending the segmented
model.

Programmers hate segmented memory. The modern operating systems
keep all the segments based at zero and extending over the
entire address space. The processor then acts exactly as if it
had a flat memory model. The operating systems do all memory
management using the paging facility.

The page descriptors, which are kept in tables in ordinary
memory, have the usual flags to support supervisor privilege and
demand-paged virtual memory. Intel did not include an
executable flag, even though this was an old idea at the time.

Intel reserved flags in the page descriptors, requiring that
systems set them to zero and ignore them. I think no-execute
takes the last of the reserved flags. Since existing systems
set reserved flags to zero and legacy X86 processors allow
execution from any page, backwards compatibly requires that the
default value for the flag be zero, and zero must mean that the
page is executable. Thus where other processors have an
"execute" bit, Intel now has a "no execute" bit.

> But it is only a band-aid to sanitize faulty software.

Yep. Stack-smashers won't be able to run their code directly
from their overflowed stack buffer. They might even have to
settle for being able to branch to any existing code, with any
arguments of their choice on the stack. Enjoy the safety. 

-- 
--Bryan

Relevant Pages

  • Re: simple assembler question
    ... My assembly language knowledge is a bit outdated ... I just digged in the "Intel Assembler For Intel XScale Microarchitecture ... telling it to disassemble a bunch of empty memory. ... How the CPU interprets the memory when you try to execute it has nothing ...
    (comp.sys.mac.programmer.help)
  • [opensuse] Ricoh 5in1 Card reader problem!!
    ... Opensuse 10.3 detect the hardware but if you slot sandisk memory stick duo or sd card, it will not able to detect the card at all. ... oss.card_id = 'HDA Intel' ... linux.subsystem = 'pci' ...
    (SuSE)
  • Re: Delphi 2008 native?
    ... Microsoft is in bed with Intel and AMD.. ... An important difference between .NET and Pascal is that ..NET potentially can move objects to new memory locations *during* execution, so that memory fragmentation is avoided. ...
    (borland.public.delphi.non-technical)
  • Re: AMD vs Intel - Ghz & performance question
    ... Intel is phasing out the Pentium 4 because increasing the ... >>>philosophy to the AMD processors, i.e. do more work per clock cycle. ... > Hypertransport is not used for memory, ... > performance when going to SLI with AMD systems. ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: Canadian OpenVMS Seminar (07.02.20)
    ... appropriate answer to the question of "What specific RAS-related features ... Re: Solaris x86: Neil wrote about "running Solaris or LINUX on x86 to see ... support for DDR2 memory and support for online spare memory chips, ... relationship with Intel)? ...
    (comp.os.vms)
Quantcast