Re: [MirageOS-devel] OCaml-TLS directly on Xen

[Thomas Leonard <talex5@xxxxxxxxx>]

On 17 September 2014 15:20, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 17 Sep 2014, at 11:53, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA384
>>
>> Hey,
>>
>> I demonstrated that OCaml-TLS runs directly on Xen at the OCaml
>> workshop. The port is still a bit hackish, thus I hope to get some
>> feedback (esp. regarding what features (such as FORTIFY_SOURCE stack
>> protection, and/or assert (should minios provide an assert_fail
>> symbol?)) we want to compile our C code with, and how to upstream
>> these changes properly).
>>
>> I develop on a cubieboard2, where I pinned mirage
>> (44bd28f862549aa1f149421c1e515bb3703e40d7), mirage-xen
>> (0251870f14030315b00ffdd0cd0112d8788270a1) and tcpip
>> (05148f900352eabaa615b60d5b2fb518f5518edd) to git HEAD (as well as
>> x509/asn1-combinators/nocrypto/tls).
>>
>
> Very nice indeed!
>
>> Several libraries needed to be modified to run in the Xen environment:
>>
>> minios
>> - ------
>>
>> https://github.com/hannesm/xen/tree/tls-fixes
>> some symbols are required for the various C libraries below, namely:
>> abort (calling do_exit)
>
> Adding this to MiniOS should be fine (waiting for Thomas Leonard to
> return from vacation).

Another possible place for these would be mirage-platform's
mini_libc.c file. The main advantage is: there's less code review
needed to get things in mirage ;-) Otherwise, you'll need to argue for
these on xen-devel (and add a signed-off-by line to the Git commit).

>> __stack_chk_guard (being NULL)
>
> Is this really essential -- it's inserted by the gcc stack smash
> checker isn't it?  Should be no harm in putting it into MiniOS, but
> I'd prefer understanding if it'll cause problems if (e.g.) clang is
> used to build the toolchain as well.
>
>> fprintf/printf/stdout/stderr/fflush (for gmp and zarith)
>
> I'd definitely prefer to have these in a separate 'nanolibc'
> separate from MiniOS itself.  I believe James Bielman could also
> use such a shim library to compile libselinux as well.

Sounds good.

>> gmp (the GNU multi-precision arithmetic library)
>> - ------------------------------------------------
>>
>> Configure (esp. config.guess) gets confused by an arm dualcore:
>> http://berlin.ccc.de/~hannes/gmp-6a.diff fixes this.
>>
>> I used the following CFLAGS:
>> export CFLAGS="-marm -O2 -pedantic -fomit-frame-pointer -fno-builtin
>> - -D_FORTIFY_SOURCE=0"
>> ./configure
>> make
>
> This is possibly worth folding in to be compiled statically
> (as a separate library) in the mirage-minios-xen repository
> (which is turning into our aggregation-of-libraries-repo).
>
>>
>> zarith
>> - ------
>>
>> Due to subtle differences of GNU libm and openlibm (esp isinf/isnan is
>> rewritten in the GNU version to __isinf/__isnan), I modified caml_z.c
>> to #include <openlibm.h> instead of <math.h> (should openlibm instead
>> install its header file as math.h!?)
>>
>> Patch at http://berlin.ccc.de/~hannes/zarith.diff
>>
>> I additionally pointed zarith to my custom gmp library:
>> export CPPFLAGS="-I/home/mirage/gmp-6.0.0.orig
>> - -I/home/mirage/.opam/system/include"
>> export LDFLAGS="-L/home/mirage/gmp-6.0.0.orig/.libs"
>>
>> (the previously mentioned CFLAGS are also still active!)
>
> Deferring to Thomas on this one...

I wonder if we should use a separate OPAM switch when targeting Xen?
It does mean compiling some things twice, but would allow compiling
with different options, etc. It might also allow some extra
optimisations (e.g. dropping relocation support), and might make
cross-compiling easier one day.

>> ctypes (0.3.3)
>> - --------------
>>
>> nocrypto (from git) depends on ctypes, which needed some CFLAGS (to
>> avoid assert_fail being called (-DNDEBUG), sscanf being translated to
>> __isoc99_sscanf (-D_GNU_SOURCE)), patch
>> http://berlin.ccc.de/~hannes/ctypes.diff
>>
>
> This definition of GNU_SOURCE worries me -- is it happening because
> of a mismatch of header files somewhere in the compilation of the C
> library?  It shouldn't be necessary to define it in the normal course
> of operation of ctypes.
>
>> nocrypto
>> - --------
>>
>> https://github.com/mirleft/ocaml-nocrypto/tree/xen-fixes (adds -DNDEBUG)
>
> Likewise, we should be able to define assert_fail in MiniOS I think,
> as this is a fairly widely used header defined in SUS.
>
>> tls
>> - ---
>>
>> https://github.com/mirleft/ocaml-tls/tree/xen-fixes (use Io_page
>> aligned cstructs before transmitting)
>
> Misaligned Cstructs strike again... :-)
>
>>
>>
>> Once these libraries are patched, the minimum TLS server
>> https://github.com/mirleft/tls-mvp-server/tree/fixes works (with
>> export NET="direct" and s/-unix/-xen/ (mirage-clock-xen,
>> mirage-entropy-xen) in config.ml), and some minor modifications to the
>> Makefile to link in the right gmp/minios/...
>
> Awesome!  Thomas Gazagnaire is looking at the Conduit patches right
> now, which should provide the right place to hook the TLS stack into
> Cohttp and friends.


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel