search for: sjcrane

On 26 August 2013 11:39, Stephen Crane <sjcrane at uci.edu> wrote: > Greetings LLVM Devs! > > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of binaries. This diversity prevents > code-reuse attacks suc...

Greetings LLVM Devs! I am a PhD student in the Secure Systems and Software Lab at UC Irvine. We have been working on adding randomness into code generation to create a diverse population of binaries. This diversity prevents code-reuse attacks such as return-oriented-programming (ROP) by denying the attacker information about the exact code layout. ROP has been used is several high-profile recent

Nick, Thanks so much for such a detailed review. I definitely missed a few of the details of the LLVM standards. Sorry. Here's a new patch that should resolve the issues you pointed out. I've also included a few comments below -- anything I haven't replied to has been fixed. In particular, I'd like to discuss RNG seeding with the list. I currently use a static singleton to make

On 8/28/13 4:37 PM, Nick Lewycky wrote: > On 26 August 2013 11:39, Stephen Crane <sjcrane at uci.edu > <mailto:sjcrane at uci.edu>> wrote: > > Greetings LLVM Devs! > > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of b...

On Aug 26, 2013, at 11:39 AM, Stephen Crane <sjcrane at uci.edu> wrote: > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of binaries. This diversity prevents > code-reuse attacks such as return-oriented-programming...

On 08/28/2013 12:01 PM, Stephen Checkoway wrote: > 2. Local attacker who cannot read the contents of the binary. (This is a pretty strange one, but it's possible.) The attacker is forced to rely on side channel information such as timing channels in an attempt to discover the length of the inserted NOP sleds. This sounds like an extraordinarily difficult task, but possibly doable. With a

On Aug 26, 2013, at 2:39 PM, Stephen Crane <sjcrane at uci.edu> wrote: > We have been working on adding randomness into code generation > to create a diverse population of binaries. This diversity prevents > code-reuse attacks such as return-oriented-programming (ROP) by > denying the attacker information about the exact code layout....

On Sep 3, 2013, at 17:21 , Manuel Jacob <me at manueljacob.de> wrote: > The problem is to safe registers that contain gc pointers to the stack > before a call and reload them after the call. Is there an Analysis Pass > that computes information about which registers are live during a > specific instruction? I looked at LiveIntervals and LiveVariables, but > they seem to be for

On 08/28/2013 02:37 PM, Nick Lewycky wrote: > 1. I'm concerned about the deployment problem. I realize that being in > the compiler means you can transform the program in more exciting > ways, but it gives you a much worse deployment story than something > which modifies the program on disk like "prelink". Yes, definitely. Deployment is an issue which users will need

Hi, I'm trying to implement my ideas about better garbage collection support [1]. The hardest problem seems to be to find all registers that are live at safe points (for example, during a call) and spilling them. Since nobody responded on the original thread, I decided to start a new thread specifically for this question. The problem is to safe registers that contain gc pointers to the stack

On Aug 28, 2013, at 1:50 PM, Paul Robinson <pogo.work at gmail.com> wrote: > On Mon, Aug 26, 2013 at 9:14 PM, Todd Jackson <quantum.skyline at gmail.com>wrote: > >> Personally, I think it is necessary to go for the strongest random number >> generator possible. Cryptographically secure pseudorandom number >> generators have good properties that make them

On 29 August 2013 15:29, Stephen Crane <sjcrane at uci.edu> wrote: > On 08/28/2013 02:37 PM, Nick Lewycky wrote: > >> 1. I'm concerned about the deployment problem. I realize that being in >> the compiler means you can transform the program in more exciting ways, but >> it gives you a much worse deployment story t...

While looking at adding a TargetOption, I saw that there is significant overlap between the options listed in llvm/CodeGen/CommandFlags.h (which are used to set TargetOptions in llc and opt) and the options in LTOModule.cpp. There are only a few extra options in CommandFlags.h, and all target options used by LTO are there. Would it make sense to use CommandFlags.h in LTOModule as well? - Stephen

While looking at adding a new TargetOption, I saw that there is significant overlap between the options listed in llvm/CodeGen/CommandFlags.h (which are used to set TargetOptions in llc and opt) and the options in LTOModule.cpp. There are only a few extra options in CommandFlags.h, and all target options used by LTO are there. Would it make sense to use CommandFlags.h in LTOModule as well? -

I'm trying to use the Support/ThreadLocal class, and I'm having some trouble because ThreadLocalImpl::getInstance returns a const void*, which I would like to be able to modify. Is there any particular reason this returns a const pointer rather than simply a void pointer? Pthreads and the Windows TLS API both seem to return plain void*. If there's no particular reason for this,

Thanks for all the feedback! It seems there is some interest, so I thought I'd try to summarize discussions so far, and provide patches for closer inspection. I'm not sure if patches should end up here or on a different list in this instance, so if I should instead send this to a different list, I'm happy to do so. - Is diversity needed, or are existing protections sufficient? As