search for: dslab

Hi Andreas, Cloud9 is a project that has an extensive POSIX environment model which also lets you symbolically execute multithreaded programs. It is based on KLEE. http://dslab.epfl.ch/pubs/cloud9.pdf Portend builds on top of Cloud9 to perform race detection/classification: http://dslab.epfl.ch/pubs/portend.pdf Cloud9 code base is also public, it might be of interest to you: http://cloud9.epfl.ch/ Best, On Thu, Oct 25, 2012 at 3:49 PM, Andreas Wilhelm <andreas.wi...

...nd tools, both for code and temporal debugging of core RTOS components, drivers and real-time applications, * Real-time related extensions to development environments. Further information: EN: http://www.realtimelinuxfoundation.org/events/rtlws-2006/ws.html CN: http://dslab.lzu.edu.cn/rtlws8/index.html Awarded papers The Programme Committee will award a best paper in the category Real- Time Systems Theory. This best paper will be invited for publication to the Real-Time Systems Journal, RTSJ. The Programme Committee will award a best paper in th...

On 01/21/2016 01:51 PM, Sean Silva wrote: > > > On Thu, Jan 21, 2016 at 1:33 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > > > On 01/19/2016 09:04 PM, Sean Silva via llvm-dev wrote: >> >> AFAIK, the cost of a well-predicted, not-taken branch is the same >> as a nop on every x86

...icant, too. I guess this would hold for branches and sanitizer checks as well. Best, Jonas On Thu, Jan 21, 2016 at 11:52 PM Jonas Wagner <jonas.wagner at epfl.ch> wrote: > Hello, > > There is some data on this, e.g, in “High System-Code Security with Low > Overhead” <http://dslab.epfl.ch/proj/asap/#publications>. In this work we > found that, for ASan as well as other instrumentation tools, most overhead > comes from the checks. Especially for CPU-intensive applications, the cost > of maintaining shadow memory is small. > > How did you measure this? If it...

On Thu, Jan 21, 2016 at 2:52 PM, Jonas Wagner <jonas.wagner at epfl.ch> wrote: > Hello, > > There is some data on this, e.g, in “High System-Code Security with Low > Overhead” <http://dslab.epfl.ch/proj/asap/#publications>. In this work we > found that, for ASan as well as other instrumentation tools, most overhead > comes from the checks. Especially for CPU-intensive applications, the cost > of maintaining shadow memory is small. > > How did you measure this? If it...

¿Qué tal? El próximo *miércoles* (30 de octubre), volvemos con una nueva reunión del "Grupo de R de Madrid". Contaremos con Carmen Lancho y Emilio L. Cano (Presidente de la Asociación de R-Hispano y habitual en esta lista) que nos detallarán como usan R en el Grupo "DSLAB" de la Universidad Rey Juan Carlos de Madrid. El detalle de la agenda lo podéis encontrar aquí: - https://www.meetup.com/es-ES/grupo-de-usuarios-de-r-de-madrid/events/304169568/?eventorigin=group_upcoming_events Este evento será tanto presencial como online (Zoom). Os esperamos!. Gr...

Hi All, Is this possible to generate LLVM IR from any static/dynamic link library? I have some static and dynamic link library and I want to generate LLVM IR as I want to obfuscate these libraries. Is there any way to do the same. Please give me some pointers on this. Thanks, Deep -------------- next part -------------- An HTML attachment was scrubbed... URL:

Thanks for the information. This has been very useful! Patch points indeed *almost* do what I need. I will try to build a similar solution. Self-modifying code for truly zero-overhead (when not enabled) > instrumentation is a real thing (look at e.g. DTrace pid provider) but > unless the number of instrumentation point is very large (100's of > thousands? millions?) or not known

Hi, I am newbie for LLVM. I need some help, I want to disassemble ARM binaries and perform some operation on LLVM IR and again back to generate ARM binary from modified ARM LLVM IR. How I can proceed for the same. Any tool or document will be highly appreciated. Thanks and Regards, Deep -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 4 Nov 2014, at 00:36, Kostya Serebryany <kcc at google.com> wrote: > You at least increase the memory footprint by doubling the stack sizes. Not quite. The space overhead is constant for each stack frame - you just need to keep track of the top of two stacks, rather than one. The important overhead is that you reduce locality of reference. You will need a minimum of two cache

...rything else. Such separation makes it much harder for an attacker to corrupt objects on the safe stack, including function pointers stored in spilled registers and return addresses. A detailed description of the individual components is available in our OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf). The overhead of our implementation of the safe stack is very close to zero (0.01% on the Phoronix benchmarks and 0.03% on SPEC2006 CPU on average). This is lower than the overhead of stack cookies, which are supported by LLVM and are commonly used today, yet the security gua...