<div dir="ltr"><span style="font-size:19.7999992370605px;line-height:23.7600002288818px">Hi - guess I'll weigh in; I've been lurking here to learn more about crypto, but my expertise is in language design.</span><br style="font-size:19.7999992370605px;line-height:23.7600002288818px"><br style="font-size:19.7999992370605px;line-height:23.7600002288818px"><span style="font-size:19.7999992370605px;line-height:23.7600002288818px">Surely, what you are describing is a lightweight tool that either generates LLVM bitcode, or hooks into the LLVM backends at a slightly lower level than that to output particular instructions when that's what you really, really want - but I suspect its hinting system already makes that unnecessary for this use-case.  LLVM bitcode is precisely this "mostly concrete assembly" concept that you're describing.</span><br style="font-size:19.7999992370605px;line-height:23.7600002288818px"><div style="font-size:19.7999992370605px;line-height:23.7600002288818px"><br></div><div style="font-size:19.7999992370605px;line-height:23.7600002288818px">There's unfortunately no textual syntax for it.  So, I feel like what you want is a straightforward C++ program that links against LLVM and consists almost entirely of a long list of calls to "append this opcode" methods.</div><div style="font-size:19.7999992370605px;line-height:23.7600002288818px"><br></div><div style="font-size:19.7999992370605px;line-height:23.7600002288818px">You'd want to set up your makefile or other build system to compile this program, run it, and the program would be written to generate a native .o, which the makefile would then link into the rest of the project as if it had just come from a conventional compiler.</div><div style="font-size:19.7999992370605px;line-height:23.7600002288818px"><br></div><div style="font-size:19.7999992370605px;line-height:23.7600002288818px">Irene</div></div><br><div class="gmail_quote">On Fri, Apr 3, 2015 at 11:11 AM Irene Knapp <<a href="mailto:ireneista@gmail.com">ireneista@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi - guess I'll weigh in; I've been lurking here to learn more about crypto, but my expertise is in language design.<br><br>Surely, what you are describing is a lightweight tool that either generates LLVM bitcode, or hooks into the LLVM backends at a slightly lower level than that to output particular instructions when that's what you really, really want - but I suspect its hinting system already makes that unnecessary for this use-case.  LLVM bitcode is precisely this "mostly concrete assembly" concept that you're describing.<br><div><br></div><div>There's unfortunately no textual syntax for it.  So, I feel like what you want is a straightforward C++ program that links against LLVM and consists almost entirely of a long list of calls to "append this opcode" methods.</div><div><br></div><div>You'd want to set up your makefile or other build system to compile this program, run it, and the program would be written to generate a native .o, which the makefile would then link into the rest of the project as if it had just come from a conventional compiler.</div></div><div dir="ltr"><div><br></div><div>Irene</div></div><br><div class="gmail_quote">On Fri, Apr 3, 2015 at 4:03 AM Andrew Moon <<a href="mailto:liquidsun@gmail.com" target="_blank">liquidsun@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OpenSSL's idea is interesting, but is a fairly horrible<br>
implementation. The 32 bit x86 stuff uses a 'psuedo' language by<br>
abusing perl while everything else (arm, x86-64, etc) is just parsing<br>
raw asm, and everything has random kludges for specific instructions.<br>
There's also no way to import/convert existing asm to their weird<br>
pseudo-x86 format, and the C compiler (as well as the perl script!)<br>
has no (easy) way to tell if the assembler even supports the<br>
instruction set(s) being compiled.<br>
<br>
I don't really like the "programmable assembler assembler" code being<br>
distributed as the sole file either, especially when it's trying to<br>
re-use bits of code while generating for multiple instruction sets<br>
(like OpenSSL does). It's difficult/impossible to tell what it is<br>
doing without seeing the generated output, and trying to fix an issue<br>
affecting one instruction set without stepping on the others would be<br>
error-prone.<br>
<br>
Ideally, I think I'd want two different steps: An easy to use<br>
"programmable assembler assembler" which handles boring stuff like<br>
register allocation, stack allocation, instruction set validation,<br>
constant data, stream interleaving (ARM), maybe a cycle/pipeline<br>
analyzer such as <a href="http://pulsar.webshaker.net/ccc/" target="_blank">http://pulsar.webshaker.net/<u></u>cc<u></u>c/</a> if I got greedy. I<br>
guess I'm mostly describing PeachPy, but parsing some kind of source<br>
file instead of the nasty python code; something that makes writing<br>
the exact instructions you want as painless/efficient as possible.<br>
Step 1 could also produce the annotations needed for verification<br>
(automatically generated based on instructions and/or hand annotated),<br>
metadata for Step 2 like # of arguments, xmm registers used for Win64,<br>
etc.<br>
<br>
Step 2 is what you would need to include in any project using the<br>
intermediate files, something to take the output from the first step<br>
and perform all the necessary platform specific stuff that is only<br>
known at compile time - ABI conversion, formatting for the assembler<br>
code if needed, proper keywords/metadata for the output format. Maybe<br>
just a static set of macros that are selected with ifdefs based on<br>
what ./configure finds, maybe a separate program/script which creates<br>
the final assembler file to compile.<br>
<br>
You'd then have the option of<br>
<br>
1. Distribute the intermediate file and use Step 2 to build<br>
2. Distribute the source and the intermediate and use Step 2 to build, or<br>
3. Distribute the source and use both Step 1 & 2 to build<br>
<br>
On Tue, Mar 31, 2015 at 8:51 PM, Trevor Perrin <<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>> wrote:<br>
> On Thu, Mar 19, 2015 at 11:36 AM, Samuel Neves <<a href="mailto:sneves@dei.uc.pt" target="_blank">sneves@dei.uc.pt</a>> wrote:<br>
>> On 03/19/2015 05:03 PM, Watson Ladd wrote:<br>
>>> What about mixed 1 and 4? Distribute asm a tool made.<br>
>><br>
>> This has the same problem as 1: you don't simply distribute one assembly dump, you have to distribute one for each<br>
>> toolchain/ABI/etc combo.<br>
> [...]<br>
>><br>
>> It's not really a major problem, but it is annoying enough that I would very much prefer if the tool came with the<br>
>> distribution. For that to happen, the tool must be portable, polished, etc. OpenSSL went with Perl, but I would prefer<br>
>> something better.<br>
><br>
><br>
> So the OpenSSL approach is to emit asm from scripts.  This allows<br>
> syntactic sugar (e.g. variable names for stack locations, loop<br>
> unrolling).  There's also support for translating to different<br>
> toolchain / ABI formats (e.g. it can convert AT&T syntax to Intel).<br>
><br>
> It seems like you're okay with this approach but want a higher-quality<br>
> tool that could be reused outside OpenSSL? (so asm source could be<br>
> written in "perlasm" or similar and be ingested by different<br>
> projects)?<br>
><br>
> This makes sense but I wonder if having the source file be a<br>
> string-processing script loses the ability to have code auditors or<br>
> formal-methods tools validate the code at a higher level?<br>
><br>
> I don't know that anyone's doing much formal validation of ECC<br>
> codebases yet, but it seems like a potential good idea.  If the input<br>
> source is a Perl script any formal validation tools would need to<br>
> understand Perl (not likely) or would need to understand asm, and be<br>
> re-run on every output flavor...<br>
><br>
><br>
> Trevor<br>
> ______________________________<u></u><u></u>_________________<br>
> Curves mailing list<br>
> <a href="mailto:Curves@moderncrypto.org" target="_blank">Curves@moderncrypto.org</a><br>
> <a href="https://moderncrypto.org/mailman/listinfo/curves" target="_blank">https://moderncrypto.org/<u></u>mailm<u></u>an/listinfo/curves</a><br>
______________________________<u></u><u></u>_________________<br>
Curves mailing list<br>
<a href="mailto:Curves@moderncrypto.org" target="_blank">Curves@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/curves" target="_blank">https://moderncrypto.org/<u></u>mailm<u></u>an/listinfo/curves</a><br>
</blockquote></div></blockquote></div>