2011/11/18
Three 0-day bugfixes from M$
It seems that recent fixes from M$ are very interesting. (one for IP stack!)
2011/11/17
An Analysis of Underground Forums
If you wonder how officials sees the underground world of cyber crimes you may be interested for that document.
DARPA = Skynet ?
2011/11/16
2011/05/28
Lock-free vs Wait-free
Ostatnimi czasy interesuje się algorytmami lock-free i wait-free. Dla ciekawych podrzucam kilka artykułów oraz krótka notkę wprowadzająca.
To ensure consistency of a shared data object in a concurrent environment,
the most common method is mutual exclusion, i.e. some form of locking. Mutual
exclusion degrades the system’s overall performance as it causes blocking,
i.e. other concurrent operations can not make any progress while the access to
the shared resource is blocked by the lock. Mutual exclusion can also cause
deadlocks, priority inversion and even starvation.
In order to address these problems, researchers have proposed non-blocking
algorithms for shared data objects. Non-blocking algorithms do not involve mutual
exclusion, and therefore do not suffer from the problems that blocking could
generate. Lock-free implementations are non-blocking and guarantee that regardless
of the contention caused by concurrent operations and the interleaving of
their sub-operations, always at least one operation will progress. However, there
is a risk for starvation as the progress of some operations could cause some other
operations to never finish. Wait-free algorithms are lock-free and moreover
they avoid starvation as well, as all operations are then guaranteed to finish
in a limited number of their own steps. Recently, some researchers also include
obstruction-free [3] implementations to the non-blocking set of implementations.
These kinds of implementations are weaker than the lock-free ones and do not
guarantee progress of any concurrent operation.
http://www.cs.brown.edu/~mph/Herlihy93/herlihy93methodology.pdf
http://www2.research.att.com/~bs/lock-free-vector.pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.4693&rep=rep1&type=pdf
http://www.cse.chalmers.se/~tsigas/papers/NBMalloc-algorithmica.pdf
To ensure consistency of a shared data object in a concurrent environment,
the most common method is mutual exclusion, i.e. some form of locking. Mutual
exclusion degrades the system’s overall performance as it causes blocking,
i.e. other concurrent operations can not make any progress while the access to
the shared resource is blocked by the lock. Mutual exclusion can also cause
deadlocks, priority inversion and even starvation.
In order to address these problems, researchers have proposed non-blocking
algorithms for shared data objects. Non-blocking algorithms do not involve mutual
exclusion, and therefore do not suffer from the problems that blocking could
generate. Lock-free implementations are non-blocking and guarantee that regardless
of the contention caused by concurrent operations and the interleaving of
their sub-operations, always at least one operation will progress. However, there
is a risk for starvation as the progress of some operations could cause some other
operations to never finish. Wait-free algorithms are lock-free and moreover
they avoid starvation as well, as all operations are then guaranteed to finish
in a limited number of their own steps. Recently, some researchers also include
obstruction-free [3] implementations to the non-blocking set of implementations.
These kinds of implementations are weaker than the lock-free ones and do not
guarantee progress of any concurrent operation.
http://www.cs.brown.edu/~mph/Herlihy93/herlihy93methodology.pdf
http://www2.research.att.com/~bs/lock-free-vector.pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.4693&rep=rep1&type=pdf
http://www.cse.chalmers.se/~tsigas/papers/NBMalloc-algorithmica.pdf
2011/04/01
Kod powrotu z obsługi sygnału
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.
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.
Subskrybuj:
Posty (Atom)