Wczoraj natknęliśmy się w naszej aplikacji na problem odwołania do nieprawidłowego segmentu pamięci przy obsłudze sygnału. Początkowo wyglądało to jak próba wykonywania kodu ze stosu. Jak się okazało jest to standardowe rozwiązanie stosowane w celu powrotu wywołania do Kernela po zakończeniu procedury obsługi sygnału. Problem polegał na niedeterministycznym wykonaniu takiego samomodyfikującego się kodu.
Jak narazie nie mam pełnego statusu tego problemu. Opisze problem jak tylko będę w stanie bez wątpliwych założeń go wytłumaczyć ;)
Więcej na temat wstrzykiwania kodu na stos przy powrocie z procedury obsługi sygnału, można przeczytać tutaj
A tutaj zamieszczam link do małego kursu wstawek asemblerowych z wykorzystaniem GCC.
2011/04/01
2011/03/22
Bionic - Android C like library
Bionic to implementacja libC (lub przynajmniej tak powinna być kojarzona) w Android. Głównymi powodami stworzenia niezależnej implementacji były:
- pozbycie się licencji GNU z libC
- uszczuplenie i przyśpieszenie implementacji
Bardzo przypadły mi do gustu rozwiązania użyte w Bionic, jako że zajmuję się rozwiązaniami embedded. Z krótkim opisem można się zapoznać tutaj
Ciekawe jest że autorzy uznali np międzyprocesowe semafory i zmienne warunkowe za zbyt "ciężkie" i postanowili nie implementować ich obsługi w wywołaniach POSIX-like.
Ciekawe są również następujące stwierdzenia "Note that Posix mandates a minimum of 128 (thread local storage) slots, but we do not claim to be Posix-compliant"
Jeszcze innym ciekawym rozwiązaniem są tzw property, coś co starałem się wprowadzić w naszej firmie. "Android provides a simple shared value/key space to all processes on the system. It stores a liberal number of 'properties', each of them being a simple size-limited string that can be associated to a size-limited string value".
Najciekawsze jest jednak poniższe stwierdzenie "Bionic intentionally does not provide support for System-V IPCs mechanisms, like the ones provided by semget(), shmget(), msgget(). The reason for this is to avoid denial-of-service.". Ciekawe podejście do problemu :)
- pozbycie się licencji GNU z libC
- uszczuplenie i przyśpieszenie implementacji
Bardzo przypadły mi do gustu rozwiązania użyte w Bionic, jako że zajmuję się rozwiązaniami embedded. Z krótkim opisem można się zapoznać tutaj
Ciekawe jest że autorzy uznali np międzyprocesowe semafory i zmienne warunkowe za zbyt "ciężkie" i postanowili nie implementować ich obsługi w wywołaniach POSIX-like.
Ciekawe są również następujące stwierdzenia "Note that Posix mandates a minimum of 128 (thread local storage) slots, but we do not claim to be Posix-compliant"
Jeszcze innym ciekawym rozwiązaniem są tzw property, coś co starałem się wprowadzić w naszej firmie. "Android provides a simple shared value/key space to all processes on the system. It stores a liberal number of 'properties', each of them being a simple size-limited string that can be associated to a size-limited string value".
Najciekawsze jest jednak poniższe stwierdzenie "Bionic intentionally does not provide support for System-V IPCs mechanisms, like the ones provided by semget(), shmget(), msgget(). The reason for this is to avoid denial-of-service.". Ciekawe podejście do problemu :)
2011/03/21
2011/03/18
Skimming numerów PIN możliwy na kartach chipowych
Skimming numerów PIN możliwy na kartach chipowych: "Czwórka ekspertów zademonstrowała praktyczne możliwości zastosowania skimmingu wymierzonego w karty chipowe – i to zarówno w przypadku układów niechronionej klasy, jak też klasy DDA.
"
 |  |
"
2011/03/10
Sygnaly
Przyszedł czas na odświeżenie wiedzy o sygnałach.
http://www.kernel.org/doc/man-pages/online/pages/man7/signal.7.html
Streszczenie:
Sygnały dostarczane do procesu traktujemy jak przerwania w systemie z bezpośrednim dostepem do procesora.
W Linuxie występują 2 rodzaje sygnałów, Standardowe i RealTime. Cytujac zródło:
"Real-time signals are distinguished by the following:
1. Multiple instances of real-time signals can be queued. By contrast, if multiple instances of a standard signal are delivered while that signal is currently blocked, then only one instance is queued.
2. If the signal is sent using sigqueue(2), an accompanying value (either an integer or a pointer) can be sent with the signal. If the receiving process establishes a handler for this signal using the SA_SIGINFO flag to sigaction(2) then it can obtain this data via the si_value field of the siginfo_t structure passed as the second argument to the handler. Furthermore, the si_pid and si_uid fields of this structure can be used to obtain the PID and real user ID of the process sending the signal.
3. Real-time signals are delivered in a guaranteed order. Multiple real-time signals of the same type are delivered in the order they were sent. If different real-time signals are sent to a process, they are delivered starting with the lowest-numbered signal. (I.e., low-numbered signals have highest priority.) By contrast, if multiple standard signals are pending for a process, the order in which they are delivered is unspecified.
If both standard and real-time signals are pending for a process, POSIX leaves it unspecified which is delivered first. Linux, like many other implementations, gives priority to standard signals in this case."
Sygnały mogą zostać wysłane do procesu lub wątku. Zazwyczaj funkcje pozwalające wysłać sygnał do wątku posiadają przedrostek pthread- . Sygnał wysłany do procesu zostanie dostarczony do dowolnego z wątków który w danym momencie go nie blokuje. Jeśli wszystkie wątki blokują sygnał skierowany do procesu, pozostanie on nieobsłużony do czasu aż przynajmniej jeden z wątków zezwoli na jego przetwarzanie.
Nalezy pamietać że istnieja 2 pojęcia dotyczące sygnałów, dyspozycje oraz maska. Dyspozycja sygnałów określa czy sygnał ma wykonać domyślna akcje (zależna od sygnału np zakończyć proces lub wykonać core dump), czy należny go zignorować czy przechwycić/dostarczyć. Natomiast maska pozwala na tymczasowe skolejkowanie sygnału w przypadku dyspozycji dostarczenia, do czasu kiedy nie zostanie wyczyszczona (maska). Sygnał skolejowany nazwany jest sygnałem w stanie "pending".
Dyspozycja jest peer aplikacja, natomiast maski sygnałów są peer watek.
Inną ważną informacją jest to że biblioteka pthread używa 2 lub 3 pierwsze sygnały typu real time, do implementacji jej wewnętrznych usług. Dlatego też należy bezwzględnie używać makra SIGRTMIN aby w aplikacji nie użyć przypadkiem numerów sygnałów wykorzystywanych w bibliotece pthread. Inna rzeczą o której trzeba pamiętać jest to że kernel ogranicza też maksymalna ilość kolejkowanie sygnałów (w zależności od wersji jest do ograniczenie typu system-wide (do 2.6.7) lub user-wide (od 2.6.8)).
Należy pamiętać ze w funkcji obsługi sygnału nie wolno wykonywać dowolnie zdefiniowanego kodu. POSIX wprowadza w tym celu pojęcie Async-"signal-safe" functions.
Następna sprawa są wywołania funkcji systemowych przerwane sygnałami. Wywołania systemowe przerwane sygnałami mogą być automatycznie wznawiane (bez powiadamiania aplikacji o błędzie wywołania) w niektórych przypadkach o ile użyto flagi SA_RESTART w wywoływaniu sigaction lub podobnym.
Następujące funkcje klasyfikują się do wymienionego przypadku:
- read(2), readv(2), write(2), writev(2), and ioctl(2) calls on "slow" devices. A "slow" device is one where the I/O call may block for an indefinite time, for example, a terminal, pipe, or socket. (A disk is not a slow device according to this definition.) If an I/O call on a slow device has already transferred some data by the time it is interrupted by a signal handler, then the call will return a success status (normally, the number of bytes transferred)
- open(2), if it can block (e.g., when opening a FIFO; see fifo(7)).
- wait(2), wait3(2), wait4(2), waitid(2), and waitpid(2).
- Socket interfaces: accept(2), connect(2), recv(2), recvfrom(2), recvmsg(2), send(2), sendto(2), and sendmsg(2), unless a timeout has been set on the socket (see below).
- File locking interfaces: flock(2) and fcntl(2) F_SETLKW.
- POSIX message queue interfaces: mq_receive(3), mq_timedreceive(3), mq_send(3), and mq_timedsend(3).
- futex(2) FUTEX_WAIT (since Linux 2.6.22; beforehand, always failed with EINTR).
- POSIX semaphore interfaces: sem_wait(3) and sem_timedwait(3) (since Linux 2.6.22; beforehand, always failed with EINTR).
Ważne zaznaczenia jest to ze dysk nie jest uznany za "wolne" urządzenie, dlatego przy pisaniu lub czytaniu z pliku zawsze należny sprawdzać kod powrotu oznaczający ilość wpisanych lub odczytanych danych. 0 nie jest kodem błędu! ale informacja ze żadne dane nie zostały zapisane w momencie przyjęcia sygnału.
http://www.kernel.org/doc/man-pages/online/pages/man7/signal.7.html
Streszczenie:
Sygnały dostarczane do procesu traktujemy jak przerwania w systemie z bezpośrednim dostepem do procesora.
W Linuxie występują 2 rodzaje sygnałów, Standardowe i RealTime. Cytujac zródło:
"Real-time signals are distinguished by the following:
1. Multiple instances of real-time signals can be queued. By contrast, if multiple instances of a standard signal are delivered while that signal is currently blocked, then only one instance is queued.
2. If the signal is sent using sigqueue(2), an accompanying value (either an integer or a pointer) can be sent with the signal. If the receiving process establishes a handler for this signal using the SA_SIGINFO flag to sigaction(2) then it can obtain this data via the si_value field of the siginfo_t structure passed as the second argument to the handler. Furthermore, the si_pid and si_uid fields of this structure can be used to obtain the PID and real user ID of the process sending the signal.
3. Real-time signals are delivered in a guaranteed order. Multiple real-time signals of the same type are delivered in the order they were sent. If different real-time signals are sent to a process, they are delivered starting with the lowest-numbered signal. (I.e., low-numbered signals have highest priority.) By contrast, if multiple standard signals are pending for a process, the order in which they are delivered is unspecified.
If both standard and real-time signals are pending for a process, POSIX leaves it unspecified which is delivered first. Linux, like many other implementations, gives priority to standard signals in this case."
Sygnały mogą zostać wysłane do procesu lub wątku. Zazwyczaj funkcje pozwalające wysłać sygnał do wątku posiadają przedrostek pthread- . Sygnał wysłany do procesu zostanie dostarczony do dowolnego z wątków który w danym momencie go nie blokuje. Jeśli wszystkie wątki blokują sygnał skierowany do procesu, pozostanie on nieobsłużony do czasu aż przynajmniej jeden z wątków zezwoli na jego przetwarzanie.
Nalezy pamietać że istnieja 2 pojęcia dotyczące sygnałów, dyspozycje oraz maska. Dyspozycja sygnałów określa czy sygnał ma wykonać domyślna akcje (zależna od sygnału np zakończyć proces lub wykonać core dump), czy należny go zignorować czy przechwycić/dostarczyć. Natomiast maska pozwala na tymczasowe skolejkowanie sygnału w przypadku dyspozycji dostarczenia, do czasu kiedy nie zostanie wyczyszczona (maska). Sygnał skolejowany nazwany jest sygnałem w stanie "pending".
Dyspozycja jest peer aplikacja, natomiast maski sygnałów są peer watek.
Inną ważną informacją jest to że biblioteka pthread używa 2 lub 3 pierwsze sygnały typu real time, do implementacji jej wewnętrznych usług. Dlatego też należy bezwzględnie używać makra SIGRTMIN aby w aplikacji nie użyć przypadkiem numerów sygnałów wykorzystywanych w bibliotece pthread. Inna rzeczą o której trzeba pamiętać jest to że kernel ogranicza też maksymalna ilość kolejkowanie sygnałów (w zależności od wersji jest do ograniczenie typu system-wide (do 2.6.7) lub user-wide (od 2.6.8)).
Należy pamiętać ze w funkcji obsługi sygnału nie wolno wykonywać dowolnie zdefiniowanego kodu. POSIX wprowadza w tym celu pojęcie Async-"signal-safe" functions.
Następna sprawa są wywołania funkcji systemowych przerwane sygnałami. Wywołania systemowe przerwane sygnałami mogą być automatycznie wznawiane (bez powiadamiania aplikacji o błędzie wywołania) w niektórych przypadkach o ile użyto flagi SA_RESTART w wywoływaniu sigaction lub podobnym.
Następujące funkcje klasyfikują się do wymienionego przypadku:
- read(2), readv(2), write(2), writev(2), and ioctl(2) calls on "slow" devices. A "slow" device is one where the I/O call may block for an indefinite time, for example, a terminal, pipe, or socket. (A disk is not a slow device according to this definition.) If an I/O call on a slow device has already transferred some data by the time it is interrupted by a signal handler, then the call will return a success status (normally, the number of bytes transferred)
- open(2), if it can block (e.g., when opening a FIFO; see fifo(7)).
- wait(2), wait3(2), wait4(2), waitid(2), and waitpid(2).
- Socket interfaces: accept(2), connect(2), recv(2), recvfrom(2), recvmsg(2), send(2), sendto(2), and sendmsg(2), unless a timeout has been set on the socket (see below).
- File locking interfaces: flock(2) and fcntl(2) F_SETLKW.
- POSIX message queue interfaces: mq_receive(3), mq_timedreceive(3), mq_send(3), and mq_timedsend(3).
- futex(2) FUTEX_WAIT (since Linux 2.6.22; beforehand, always failed with EINTR).
- POSIX semaphore interfaces: sem_wait(3) and sem_timedwait(3) (since Linux 2.6.22; beforehand, always failed with EINTR).
Ważne zaznaczenia jest to ze dysk nie jest uznany za "wolne" urządzenie, dlatego przy pisaniu lub czytaniu z pliku zawsze należny sprawdzać kod powrotu oznaczający ilość wpisanych lub odczytanych danych. 0 nie jest kodem błędu! ale informacja ze żadne dane nie zostały zapisane w momencie przyjęcia sygnału.
2011/02/14
Sojusz przegranych, jak błyskawica ...
Jeśli śledzicie rynek urządzeń mobilnych, zapewne wiecie ze Windows 7 Mobile jest postrzegany jako produkt spóźniony i niedopracowany. W internecie można znaleźć informacje o brakach i błędach tego systemu. To nie przeszkadza jednak M$ w promowaniu W7 jako "niszczyciela iOS" . Wg mnie to hipokryzja choćby ze względu braku kompatybilności wstecz z linia Windows Mobile (żegnaj Automapo). Jest też inny przegrany, Nokia. Firma ta w segmencie smartphone postawiła na system Symbian, który jak się okazało nie jest lubiany przez użytkowników i programistów (chyba nie bez powodu, ręka w górę kto ma to badziewie ;). Efektem tego jest spadek sprzedaży produktów Noki opartych o ten system, co negatywnie odbiło się na kondycji finansowej fińskiego producenta (m.in ze stanowisk polecieli szefowie sektora). Szybko jednak okazało się że Nokia nie załamuje rąk i podpisała umowę o współpracy, zgadnijcie z kim :).
Moim zdaniem będzie to ciekawe widowisko, ostatni okrzyk gigantów przed katastrofą, jednak czas pokaże jaki będzie wynik tej batalii z Androidem. Tymczasem szefowie obu firma maja bardzo podnoszące na duchu hasło:
"Istnieją inne ekosystemy mobilne. My je zniszczymy. Stoją przed nami wyzwania. My im sprostamy. Sukces wymaga szybkości. Będziemy jak błyskawica. Obydwaj widzimy szanse; mamy wolę, środki i motywację, aby odnieść sukces"
Moim zdaniem będzie to dosłownie jak błyskawica (dużo huku - czyli wielka kampania reklamowa), delikatny wzrost sprzedaży i wielka feta ala M$ ... i ... no właśnie ... wielkie nic, następne miliony użytkowników zostawione bez wsparcia technicznego i aplikacji użytkowych.
Balmer, sprzedawaj szybciej te akcje!!!!
Moim zdaniem będzie to ciekawe widowisko, ostatni okrzyk gigantów przed katastrofą, jednak czas pokaże jaki będzie wynik tej batalii z Androidem. Tymczasem szefowie obu firma maja bardzo podnoszące na duchu hasło:
"Istnieją inne ekosystemy mobilne. My je zniszczymy. Stoją przed nami wyzwania. My im sprostamy. Sukces wymaga szybkości. Będziemy jak błyskawica. Obydwaj widzimy szanse; mamy wolę, środki i motywację, aby odnieść sukces"
Moim zdaniem będzie to dosłownie jak błyskawica (dużo huku - czyli wielka kampania reklamowa), delikatny wzrost sprzedaży i wielka feta ala M$ ... i ... no właśnie ... wielkie nic, następne miliony użytkowników zostawione bez wsparcia technicznego i aplikacji użytkowych.
Balmer, sprzedawaj szybciej te akcje!!!!
Subskrybuj:
Posty (Atom)