Kiedy i dlaczego kompilator zainicjuje pamięć na 0xCD, 0xDD itp. Na malloc / free / new / delete?

Wiem, że kompilator czasami inicjuje pamięć za pomocą pewnych wzorców, takich jak 0xCDi 0xDD. Chcę wiedzieć, kiedy i dlaczego tak się dzieje.

Kiedy

Czy jest to specyficzne dla używanego kompilatora?

Czy malloc/newi jak free/deletedziała w odniesieniu do tego w ten sam sposób?

Czy jest to specyficzne dla platformy?

Czy wystąpi w innych systemach operacyjnych, takich jak Linuxlub VxWorks?

Czemu

Rozumiem, że występuje to tylko w Win32konfiguracji debugowania i jest używane do wykrywania przepełnień pamięci i pomocy kompilatorowi w wychwytywaniu wyjątków.

Czy możesz podać praktyczne przykłady przydatności tej inicjalizacji?

Pamiętam, że czytałem coś (może w Code Complete 2), mówiąc, że dobrze jest zainicjować pamięć według znanego wzorca podczas jej przydzielania, a niektóre wzorce będą wyzwalać przerwania, w Win32których pojawią się wyjątki w debugerze.

Jak bardzo jest to przenośne?

Krótkie podsumowanie tego, czego kompilatory Microsoftu używają dla różnych bitów pamięci nieposiadanej / niezainicjowanej, gdy są kompilowane do trybu debugowania (obsługa może się różnić w zależności od wersji kompilatora):

Value     Name           Description 
------   --------        -------------------------
0xCD     Clean Memory    Allocated memory via malloc or new but never 
                         written by the application. 

0xDD     Dead Memory     Memory that has been released with delete or free. 
                         It is used to detect writing through dangling pointers. 

0xED or  Aligned Fence   'No man's land' for aligned allocations. Using a 
0xBD                     different value here than 0xFD allows the runtime
                         to detect not only writing outside the allocation,
                         but to also identify mixing alignment-specific
                         allocation/deallocation routines with the regular
                         ones.

0xFD     Fence Memory    Also known as "no mans land." This is used to wrap 
                         the allocated memory (surrounding it with a fence) 
                         and is used to detect indexing arrays out of 
                         bounds or other accesses (especially writes) past
                         the end (or start) of an allocated block.

0xFD or  Buffer slack    Used to fill slack space in some memory buffers 
0xFE                     (unused parts of `std::string` or the user buffer 
                         passed to `fread()`). 0xFD is used in VS 2005 (maybe 
                         some prior versions, too), 0xFE is used in VS 2008 
                         and later.

0xCC                     When the code is compiled with the /GZ option,
                         uninitialized variables are automatically assigned 
                         to this value (at byte level). 


// the following magic values are done by the OS, not the C runtime:

0xAB  (Allocated Block?) Memory allocated by LocalAlloc(). 

0xBAADF00D Bad Food      Memory allocated by LocalAlloc() with LMEM_FIXED,but 
                         not yet written to. 

0xFEEEFEEE               OS fill heap memory, which was marked for usage, 
                         but wasn't allocated by HeapAlloc() or LocalAlloc(). 
                         Or that memory just has been freed by HeapFree(). 

Zastrzeżenie: stół pochodzi z niektórych notatek, które leżę wokół - mogą nie być w 100% poprawne (lub spójne).

Wiele z tych wartości jest zdefiniowanych w vc / crt / src / dbgheap.c:

/*
 * The following values are non-zero, constant, odd, large, and atypical
 *      Non-zero values help find bugs assuming zero filled data.
 *      Constant values are good, so that memory filling is deterministic
 *          (to help make bugs reproducible).  Of course, it is bad if
 *          the constant filling of weird values masks a bug.
 *      Mathematically odd numbers are good for finding bugs assuming a cleared
 *          lower bit.
 *      Large numbers (byte values at least) are less typical and are good
 *          at finding bad addresses.
 *      Atypical values (i.e. not too often) are good since they typically
 *          cause early detection in code.
 *      For the case of no man's land and free blocks, if you store to any
 *          of these locations, the memory integrity checker will detect it.
 *
 *      _bAlignLandFill has been changed from 0xBD to 0xED, to ensure that
 *      4 bytes of that (0xEDEDEDED) would give an inaccessible address under 3gb.
 */

static unsigned char _bNoMansLandFill = 0xFD;   /* fill no-man's land with this */
static unsigned char _bAlignLandFill  = 0xED;   /* fill no-man's land for aligned routines */
static unsigned char _bDeadLandFill   = 0xDD;   /* fill free objects with this */
static unsigned char _bCleanLandFill  = 0xCD;   /* fill new objects with this */

Zdarza się również, że środowisko uruchomieniowe debugowania wypełni bufory (lub ich części) znaną wartością, na przykład „zapasem” miejsca w std::stringalokacji lub buforze przekazanym do fread(). Te przypadki używają wartości podanej w nazwie _SECURECRT_FILL_BUFFER_PATTERN(zdefiniowanej w crtdefs.h). Nie jestem pewien, kiedy został wprowadzony, ale znajdował się w środowisku uruchomieniowym debugowania co najmniej VS 2005 (VC ++ 8).

Początkowo wartością używaną do wypełnienia tych buforów była 0xFD- ta sama wartość, która była używana dla ziemi niczyjej. Jednak w VS 2008 (VC ++ 9) wartość została zmieniona na 0xFE. Zakładam, że dzieje się tak dlatego, że mogą wystąpić sytuacje, w których operacja wypełniania przebiegłaby poza końcem buforu, na przykład, jeśli obiekt wywołujący przeszedłby w rozmiarze buforu, który był zbyt duży fread(). W takim przypadku wartość 0xFDmoże nie wyzwolić wykrycia tego przekroczenia, ponieważ jeśli rozmiar bufora byłby zbyt duży tylko o jeden, wartość wypełnienia byłaby taka sama, jak wartość ziemi niczyjej użyta do zainicjowania tego kanarka. Brak zmian na ziemi niczyjej oznacza, że ​​przekroczenie nie zostanie zauważone.

Tak więc wartość wypełnienia została zmieniona w VS 2008, aby taki przypadek zmienił kanarka niczyjego, co spowodowało wykrycie problemu przez środowisko wykonawcze.

Jak zauważyli inni, jedną z kluczowych właściwości tych wartości jest to, że jeśli zmienna wskaźnikowa z jedną z tych wartości zostanie usunięta, spowoduje to naruszenie zasad dostępu, ponieważ w standardowej 32-bitowej konfiguracji systemu Windows adresy trybu użytkownika nie przekroczy 0x7fffffff.

Jedną z fajnych właściwości wartości fill 0xCCCCCCCC jest to, że w asemblerze x86 opcode 0xCC to int3 opcode, który jest przerwaniem programowym. Tak więc, jeśli kiedykolwiek spróbujesz wykonać kod w niezainicjowanej pamięci, która została wypełniona tą wartością wypełnienia, natychmiast trafisz w punkt przerwania, a system operacyjny pozwoli ci podłączyć debugger (lub zabić proces).

Jest specyficzny dla kompilatora i systemu operacyjnego, Visual studio ustawia różne rodzaje pamięci na różne wartości, dzięki czemu w debugerze można łatwo sprawdzić, czy przeszedłeś do pamięci malloced, stałej tablicy lub niezainicjowanego obiektu. Ktoś opublikuje szczegóły, gdy będę je wyszukiwał w Google ...

http://msdn.microsoft.com/en-us/library/974tc9t1.aspx

To nie jest system operacyjny - to kompilator. Możesz także zmodyfikować zachowanie - zobacz na dole tego posta.

Microsoft Visual Studio generuje (w trybie debugowania) plik binarny, który wstępnie wypełnia pamięć stosu wartością 0xCC. Wstawia również spację między każdą ramką stosu, aby wykryć przepełnienia bufora. Bardzo prosty przykład tego, gdzie jest to przydatne, znajduje się tutaj (w praktyce Visual Studio wykryje ten problem i wyświetli ostrzeżenie):

...
   bool error; // uninitialised value
   if(something)
   {
      error = true;
   }
   return error;

Jeśli program Visual Studio nie zainicjował wstępnie zmiennych do znanej wartości, ten błąd może być potencjalnie trudny do znalezienia. W przypadku wstępnie zainicjowanych zmiennych (a raczej wstępnie zainicjowanej pamięci stosu) problem jest powtarzalny w każdym przebiegu.

Jest jednak mały problem. Wartość używana przez program Visual Studio to TRUE - wszystko oprócz 0 będzie. W rzeczywistości jest całkiem prawdopodobne, że po uruchomieniu kodu w trybie wydania zjednolicone zmienne mogą zostać przydzielone do fragmentu pamięci stosu, który zawiera 0, co oznacza, że ​​możesz mieć usterkę ze zjednoliconą zmienną, która objawia się tylko w trybie wydania.

To mnie zirytowało, więc napisałem skrypt, aby zmodyfikować wartość wstępnego wypełnienia, bezpośrednio edytując plik binarny, co pozwoliło mi znaleźć problemy ze zmiennymi niezainicjowanymi, które pojawiają się tylko wtedy, gdy stos zawiera zero. Ten skrypt modyfikuje tylko wstępne wypełnienie stosu; Nigdy nie eksperymentowałem z wstępnym wypełnianiem sterty, chociaż powinno to być możliwe. Może wymagać edycji biblioteki DLL czasu wykonywania, może nie.

Czy jest to specyficzne dla używanego kompilatora?

W rzeczywistości jest to prawie zawsze funkcja biblioteki wykonawczej (podobnie jak biblioteka wykonawcza C). Środowisko wykonawcze jest zwykle silnie skorelowane z kompilatorem, ale istnieje kilka kombinacji, które można zamienić.

Uważam, że w systemie Windows sterta debugowania (HeapAlloc itp.) Również używa specjalnych wzorców wypełnienia, które są inne niż te, które pochodzą z malloc i bezpłatne implementacje w bibliotece wykonawczej C debugowania. Może to być również funkcja systemu operacyjnego, ale w większości przypadków jest to tylko biblioteka wykonawcza języka.

Czy malloc / new i free / delete działają w ten sam sposób w odniesieniu do tego?

Część zarządzania pamięcią new i delete jest zwykle implementowana za pomocą malloc i free, więc pamięć przydzielona za pomocą new i delete zwykle ma te same funkcje.

Czy jest to specyficzne dla platformy?

Szczegóły są specyficzne dla środowiska uruchomieniowego. Rzeczywiste używane wartości są często wybierane tak, aby nie tylko wyglądały nietypowo i wyraźnie, patrząc na zrzut szesnastkowy, ale zostały zaprojektowane tak, aby miały pewne właściwości, które mogą korzystać z funkcji procesora. Na przykład często używane są nieparzyste wartości, ponieważ mogą powodować błąd wyrównania. Używane są duże wartości (w przeciwieństwie do 0), ponieważ powodują one zaskakujące opóźnienia w przypadku pętli do niezainicjowanego licznika. Na x86, 0xCC jest int 3instrukcją, więc jeśli wykonasz niezainicjowaną pamięć, zostanie ona przechwycona.

Czy wystąpi w innych systemach operacyjnych, takich jak Linux lub VxWorks?

Zależy to głównie od używanej biblioteki wykonawczej.

Czy możesz podać jakieś praktyczne przykłady przydatności tej inicjalizacji?

Niektóre z nich wymieniłem powyżej. Wartości są zwykle wybierane w celu zwiększenia prawdopodobieństwa, że ​​stanie się coś niezwykłego, jeśli zrobisz coś z nieprawidłowymi częściami pamięci: duże opóźnienia, pułapki, błędy wyrównania itp. Menedżerowie stert również czasami używają specjalnych wartości wypełnienia dla luk między alokacjami. Jeśli te wzorce kiedykolwiek się zmienią, wie, że gdzieś wystąpił zły zapis (jak przepełnienie bufora).

Pamiętam, że czytałem coś (może w Code Complete 2), że dobrze jest zainicjować pamięć do znanego wzorca podczas jej przydzielania, a pewne wzorce będą wyzwalać przerwania w Win32, co spowoduje wyświetlenie wyjątków w debugerze.

Jak bardzo jest to przenośne?

Pisanie Solid Code (i być może Code Complete ) mówi o kwestiach, które należy wziąć pod uwagę przy wyborze wzorców wypełnienia. Wspomniałem tutaj o niektórych z nich, a artykuł w Wikipedii o Magic Number (programowanie) również je podsumowuje. Niektóre sztuczki zależą od specyfiki używanego procesora (np. Czy wymaga wyrównanych odczytów i zapisów oraz jakie wartości są odwzorowywane na instrukcje, które będą pułapki). Inne sztuczki, takie jak używanie dużych wartości i nietypowych wartości, które wyróżniają się na zrzucie pamięci, są bardziej przenośne.

W tym artykule opisano nietypowe wzorce bitów pamięci i różne techniki, których można użyć w przypadku napotkania tych wartości.

Oczywistym powodem „dlaczego” jest to, że załóżmy, że masz taką klasę:

class Foo
{
public:
    void SomeFunction()
    {
        cout << _obj->value << endl;
    }

private:
    SomeObject *_obj;
}

A następnie utworzysz jedną a Fooi wywołasz SomeFunction, spowoduje to naruszenie dostępu podczas próby odczytu 0xCDCDCDCD. Oznacza to, że zapomniałeś o czymś zainicjalizować. To jest „dlaczego część”. Jeśli nie, to wskaźnik mógł zrównać się z inną pamięcią i trudniej byłoby debugować. Po prostu informuje o przyczynie naruszenia zasad dostępu. Zauważ, że ten przypadek był dość prosty, ale w większej klasie łatwo popełnić ten błąd.

AFAIK, działa to tylko w kompilatorze Visual Studio w trybie debugowania (w przeciwieństwie do wydania)

Można łatwo zauważyć, że pamięć zmieniła się od jej początkowej wartości początkowej, zazwyczaj podczas debugowania, ale czasami także w przypadku kodu wydania, ponieważ można dołączyć debugery do procesu podczas jego działania.

Nie chodzi tylko o pamięć, wiele debugerów ustawi zawartość rejestru na wartość wartowniczą podczas uruchamiania procesu (niektóre wersje systemu AIX ustawiają niektóre rejestry, 0xdeadbeefktóre są nieco zabawne).

Kompilator IBM XLC ma opcję „initauto”, która przypisuje zmiennym automatycznym określoną przez użytkownika wartość. Użyłem następujących dla moich kompilacji debugowania:

-Wc,'initauto(deadbeef,word)'

Gdybym spojrzał na przechowywanie niezainicjowanej zmiennej, byłby ustawiony na 0xdeadbeef