Gå til innhold

Støtte for NX-bit i Linux


Anbefalte innlegg

Videoannonse
Annonse

Linux er igjen tidligere ute med støtte for ny teknologi før Windows, ganske interessant egentlig. Linus Torvalds er iallefall veldig positiv til NX-bit støtten i Linux, og er en finesse han ønsker skal være på som standard i kjernen:

http://news.com.com/Linux+gets+trial+%27NX...ml?tag=nefd.top

 

"In a discussion on the Linux kernel mailing list after Molnar posted the patch, Linux founder and leader Linus Torvalds asked how many programs wouldn't work using with NX enabled. On hearing the number was low, he then said, "It sounds like we should just have NX on by default."

 

NX support is important enough that it's worth risking problems with some applications, Torvalds said. "I think most people have seen the security disaster that causes most of the e-mails on the Net to be spam. So this should be trivial to explain to people when they complain about default behavior breaking their strange legacy app," Torvalds argued."

 

Red Hat har også røpet andre interessante detaljer om ytelsesforskjellene mellom AMD64 og EM64T i deres "Release Notes" for Red Hat Enterprise Linux 3 Update 2:

http://www.redhat.com/docs/manuals/enterpr...-x86_64-en.html

 

"Intel EM64T does not support an IOMMU in hardware while AMD64 processors do. This means that physical addresses above 4GB (32 bits) cannot reliably be the source or destination of DMA operations. Therefore, the Red Hat Enterprise Linux 3 Update 2 kernel "bounces" all DMA operations to or from physical addresses above 4GB to buffers that the kernel pre-allocated below 4GB at boot time. This is likely to result in lower performance for IO-intensive workloads for Intel EM64T as compared to AMD64 processors."

Lenke til kommentar
"No Execute" kontrollerer all kildekode som blir eksekvert og luker ut kjente sikkerhetshull som eksempelvis "buffer overflows".

 

Denne teknologien kan da umulig kontrollere kildekoden når den sitter i prosessoren? Ønsker meg en enkel forklaring på hvordan dette funker, men har det ikke noe med at den passer på at buffere i prosessoren's cache ikke blir overskrevet og på den måten hindrer binær kode å bli utført..?

Lenke til kommentar
Denne teknologien kan da umulig kontrollere kildekoden når den sitter i prosessoren? Ønsker meg en enkel forklaring på hvordan dette funker, men har det ikke noe med at den passer på at buffere i prosessoren's cache ikke blir overskrevet og på den måten hindrer binær kode å bli utført..?

NX fungerer ved at et flagg kan settes på alle dataene i cachene. Hvis NX er satt, kan ikke det som ligger på denne plassen i cachen utføres, med andre ord; det er ikke en instruksjon.

 

NX-teknologien ser selvfølgelig aldri noe kildekode. Kildekode er den koden du og jeg skriver når vi lager programmene og er ren tekst. Den kan aldri utføres, det må kompileres til et program først. Når programmet er kompilert, ser man aldri noe mer til kildekoden ...

Lenke til kommentar
Minnebeskyttelse i HW har Sun hatt en stund, så det er ikke akkurat ny teknologi generelt lenger.

 

Dog positivt at ikke-Solaris/Sparc systemer får det på plass, å eksekvere kode på stacken er jo det vanligste buffer-overflow angrepet.

Jepp, og det er egentlig ikke så veldig mange programmer eller situasjoner hvor man trenger å ha en eksekverbar stack. De snille programmene som bruker det, burde absolutt skrives om, og de "slemme" er vi bare glade for å bli kvitt.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...