guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Writing libraries for C programs using Guile Scheme


From: Mateusz Kowalczyk
Subject: Re: Writing libraries for C programs using Guile Scheme
Date: Fri, 07 Mar 2014 16:36:14 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

On 07/03/14 16:30, Mateusz Kowalczyk wrote:
> On 07/03/14 08:22, Peter TB Brett wrote:
>> Hi all,
>>
>> Recently, there have been some really horrible programming errors found in
>> widely-used and security-critical libraries (GnuTLS, for example).
>>
>> These libraries are usually written in C because C is a "lowest common
>> denominator": if a library is written in C, almost every language will be
>> able to access its functions somehow (for example, in Guile we can use the
>> dynamic FFI).
>>
>> I've now realised that it would be *really awesome* to be able to write
>> some code in Scheme, and automatically generate a .so file (or DLL) and a C
>> header file that I could then easily (and safely) use in other programs
>> without any special handling (including via Guile's FFI).  I think it would
>> be much easier to avoid some of these recent stupid "goto fail;" bugs if we
>> were writing in Scheme.
> 
> I doubt that going from a single inherently unsafe but bloody fast
> language to slightly less unsafe but much slower language is an
> advantage here…
> 
>>
>> It seems to me that most of the things needed for this are already in
>> place, although at some performance cost and probably some restrictions in
>> the sort of programs that can be written in this way:
>>
>> - Guile can already pack bytecode into ELF object files.
>> - Andy Wingo has demonstrated generation of simple native code from Guile
>> (compost!).
>> - libguile provides the infrastructure needed to load and run Guile
>> bytecode, and we can get the dynamic linker to pull it in.
>>
>> So what's needed?  I've had a few ideas for how this could work. Each
>> function exported by the library needs to have a native code stub in the
>> ELF .text section, which:
>>
>> a. Puts the thread into Guile mode
>> b. Marshals the corresponding Scheme function
>> c. Deals with uncaught exceptions - probably with SIGABRT.
>> d. Asserts that the return value from the Scheme function is a pure foreign
>> type
>> e. Leaves Guile mode
>> f. Returns
>>
>> Unfortunately I'm sure that I've missed some important bits (for example,
>> thread safety & reentrancy), and I *certainly* don't have enough low-level
>> Guile knowledge to make this work.  So I'd be very interested to hear what
>> people think about this idea.
>>
>> Best wishes,
>>
>> Peter
>>
> 
> Do you feel like you can provide correctness proofs for your
> implementations of such security critical libraries? Scheme isn't
> exactly the safest language.
> 

I should also add that you'd also have to show that the generated object
files reflect the behaviour properly.

I don't mean to sound as negative as I probably am but I'd hate to see a
broken security-critical library which offers nothing but ‘hey we get to
re-write the existing thing in our favourite dialect except slower,
clunkier to use and with new bugs!’.

-- 
Mateusz K.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]