[PATCH] Adding diversity for security

[Per Larsen]

hi joe,

thanks for chiming in. let me first put to rest your concern that we're
submitting this to offload tedious merges. we genuinely think this is
beneficial to the llvm community at large and think many people would use
this feature. think of this as the next step after putting in aslr to stop
malicious code execution. nobody who understands the purpose of aslr would
argue that it is not of interest of the broader community; basically
everybody who writes c/c++ (and does formally prove its absence of memory
errors) should care. nop insertion is basically fine-grained code layout
randomization so the relevance of aslr readily extends to our patch.

your work seems to protect against tampering and unauthorized copying. in
that respect, i'm sure your product is much more powerful than what we're
contributing. thus when focusing on drm applications, you may be right that
our patch is of limited interest to the community, however, in the context
of arbitrary code execution, our patch is broadly relevant imo.

cheers,
per


On Fri, Jan 24, 2014 at 7:39 AM, Joe Abbey <jabbey at arxan.com> wrote:

> Sean et al,
>
> Thanks for pinging me to join the conversation.
>
> I'm adding a few of my colleagues to the group as well.  Aaron Lint has
> been using LLVM's disassembler for one of our products.  He and Gordon
> Keiser have upstreamed a few backend fixes over the years.  So this touches
> on an area where they have more expertise. I will briefly comment on the
> security side of things.
>
> There is value in randomization of instruction layout, and we have built a
> successful product offering which goes beyond instruction randomization.
>  At Arxan, we believe in defense in depth and randomization of program
> appearance and behavior.  Our product's are based on Dr. Chang's research
> [1].   And of course, we've patented it [2].
>
> This patch doesn't seem to add value to the broad LLVM community, and it
> feels more like offloading the tedious merges with an internal branch.  I
> feel this pain on a weekly basis, but as of yet there's no clear way to
> "plugin" add-ons to the compiler framework. Though with the modular
> codebase, I suspect it would be trivial to write a framework which
> decouples internals and allows registration of machine code functions and
> the like.
>
> I'd suggest the patch not go in, only because there isn't sufficient value
> in adding this code.  The precedent of course makes it difficult for me and
> my team(s) to upstream similar patches.  We try to keep our patches focused
> on broadly applicable code areas. This patch is not benefiting any x86
> users, and at the same time not directly affecting them.  However, there is
> a real cost in maintaining it, and it would be a shame if after 2015 it
> were ultimately reverted.  Thus since the value seems to be limited, and
> the cost appears to exceed value, I suggest we err on the side of omission.
>
> Sincerely,
>
> Joe
>     *______________________________*
> *Joe Abbey*
> Senior Director of Product Development
> Arxan Technologies
> jabbey at arxan.com www.arxan.com
>  Protecting the App Economy™
>
> [1] http://dl.acm.org/citation.cfm?id=734775
> [2] http://pimg-fpiw.uspto.gov/fdd/97/570/077/0.pdf
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140124/e006dea8/attachment.html>