llvm dev - Dec 2012 - [LLVMdev] Proposal: Adding aligned instruction bundle support to MC

On Thu, Dec 6, 2012 at 11:59 AM, Greg Fitzgerald <garious at gmail.com>
wrote:
> Maybe I'm jumping the gun, but some initial thoughts after browsing the
MC
> layer changes:
>
Greg, it's great to have early comments on this.
> * .bundle_align_start  -> .bundle_align_mode N  ?
> * .bundle_align_end -> .bundle_align_mode 0  ?
The initial proposal does not cover .bundle_align{start|end} on
purpose, to keep things simple. We do plan to add them, eventually,
probably as attributes on .bundle_lock.
> * Add unit test showing .bundle_lock/unlock can be nested.
Yes.
>
> I like the way you modified the existing ARM tests to show how the existing
> instructions are predicated.
Thanks. When upstreaming, I should remember using the new FileCheck
feature I recently added (variable references on the same line that
define them) which should make matching BICs more elegant.
> Overall, I think the concept of Native Client
> is well-documented and easy to follow.  Has anyone done work to show that
> assembly in this form can be disassembled to a memory-safe assembly
language
> like TAL?
>
>
>> groups of instructions between .bundle_lock and
>> .bundle_unlock directives cannot cross a bundle boundary
>
> Can this be relaxed to:  A data instruction cannot fall on a bundle
> boundary.  ?
I'm not sure what you mean, can you elaborate?

Eli

>>> groups of instructions between .bundle_lock and
>>> .bundle_unlock directives cannot cross a bundle boundary
>>
>> Can this be relaxed to:  A data instruction cannot fall on a bundle
>> boundary.  ?
>
> I'm not sure what you mean, can you elaborate?
Nevermind, what I suggested was not strict enough.  I see now that the
purpose of unlock/lock is to prevent particular instructions from landing
on the bundle boundary.  For example, around a 'bic' and an indirect
branch, where the compiler inserted the bic to make the branch safe.

-Greg



On Thu, Dec 6, 2012 at 12:25 PM, Eli Bendersky <eliben at google.com>
wrote:
> On Thu, Dec 6, 2012 at 11:59 AM, Greg Fitzgerald <garious at
gmail.com>
> wrote:
> > Maybe I'm jumping the gun, but some initial thoughts after
browsing the
> MC
> > layer changes:
> >
>
> Greg, it's great to have early comments on this.
>
> > * .bundle_align_start  -> .bundle_align_mode N  ?
> > * .bundle_align_end -> .bundle_align_mode 0  ?
>
> The initial proposal does not cover .bundle_align{start|end} on
> purpose, to keep things simple. We do plan to add them, eventually,
> probably as attributes on .bundle_lock.
>
> > * Add unit test showing .bundle_lock/unlock can be nested.
>
> Yes.
>
> >
> > I like the way you modified the existing ARM tests to show how the
> existing
> > instructions are predicated.
>
> Thanks. When upstreaming, I should remember using the new FileCheck
> feature I recently added (variable references on the same line that
> define them) which should make matching BICs more elegant.
>
> > Overall, I think the concept of Native Client
> > is well-documented and easy to follow.  Has anyone done work to show
that
> > assembly in this form can be disassembled to a memory-safe assembly
> language
> > like TAL?
> >
> >
> >> groups of instructions between .bundle_lock and
> >> .bundle_unlock directives cannot cross a bundle boundary
> >
> > Can this be relaxed to:  A data instruction cannot fall on a bundle
> > boundary.  ?
>
> I'm not sure what you mean, can you elaborate?
>
> Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121206/64b1048e/attachment.html>

On Thu, Dec 6, 2012 at 3:04 PM, Greg Fitzgerald <garious at gmail.com>
wrote:
>>>> groups of instructions between .bundle_lock and
>>>> .bundle_unlock directives cannot cross a bundle boundary
>>>
>>> Can this be relaxed to:  A data instruction cannot fall on a bundle
>>> boundary.  ?
>>
>> I'm not sure what you mean, can you elaborate?
>
> Nevermind, what I suggested was not strict enough.  I see now that the
> purpose of unlock/lock is to prevent particular instructions from landing
on
> the bundle boundary.  For example, around a 'bic' and an indirect
branch,
> where the compiler inserted the bic to make the branch safe.
Correct. Having a load and the bic protecting it separated by a bundle
boundary is not safe because malicious code can arrange to jump to the
load without the bic being executed and thus access arbitrary memory,
escaping the sandbox. For x86 bundle locking is also important to make
sure jumps into the middle of instructions are not allowed.

Eli