Støtte for NX-bit i Linux

[int20h]

Støtte for NX-bit i Linux

Red Hat og Intel har lagt ut en prototype på software for Linux som gjør at operativsystemet støtter sikkerhetsfunksjonen "No Execute". NX gir blant annet beskyttelse mot en del vanlige sikkerhetshull på applikasjonslaget.

 

Les artikkelen her

[snorreh]

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."

[Kimble]

"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..?

[ØysteinI]

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 ...

[MailMan13]

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.

[ØysteinI]

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.