Suggestions for C++ or DLL code

> Hello all,
>
>
>
> I’m currently working on a TLS / SSL implementation and on windows  
> I am planning to support the Certificate Store that is built in.  
> This requires me to use the CryptoAPI dlls.  The code is complex  
> and it uses a number of header files and many steps.  I built some C
> ++ code that does what I’m looking for so now I would like to  
> incorporate this into Squeak.
>
>
>
> I’d assumed that FFI was like DDL/C connect in VW but that’s not  
> what I’m seeing.  So my question is: What is the best way to get  
> this working?  Should I hack away at FFI and support the api  
> directly, and is that even possible?  Should I create DLL’s to call  
> and use them with FFI, or should I compile some sort of plugins?  
> My preference would be to call the api directly without having to  
> create dll’s, duplicating my C++ code in Smalltalk if possible.
>
>
>
> Some direction and comparisons of different options would be very  
> helpful.
>
>
>
> Thank you for your help!
>
>
>
> Ron Teitelbaum
>
>

> From: John M McIntosh
> Sent: Sunday, July 30, 2006 2:26 AM
>
> Well I've done all three, or is that four?
>
> a) FFI class via platform specific instances interfacing to generic
> classes that a squeak user interacts with.
> b) FFI class/subclasses that are modified on the fly depending on
> platform to get module name correct and or provide overrides by
> platform, lots of this in Croquet.
> c) wrapper classes that use plugin code that lightly wraps api,
> support work all done in Smalltalk, I did this for the extended
> serial support.
> d) Generic classes that wrap plugin code that interfaces to platform
> specific code, lots of this in the VM
>
>
> Issues.
> Generally getting folks to setup a development system, get VMMaker,
> understand plugins, build and test something is only done by a
> minority of squeakers.
>
> In using FFI, mapping the parms/return values to the correct
> Smalltalk external objects will at some point drive you crazy, it
> does all work, but sometimes late at night you
> wonder. For the most part we do this in Sophie, any one can do FFI,
> but debugging is hard.
>
> Using lightly wrap APIs, that provides a bit clearer, in my opinion,
> parameter specifications that then invoke the api. You usually can
> use the development system source debugger to halt and debug at the
> api inteface. It's a bit easy for folks to assemble features since
> they can code the steps in smalltalk and interface to the apis, new
> apis require someone to mangle plugin code and compile plugins.
> Technically it's very similar to FFI, but avoids FFI.
>
> Using fully abstracted plugin with platform specific code, well
> that's hard, and few folks want to participate. You can of course
> write all the code via plugin code, I believe I do this for the mac
> menu bar plugin since it's platform specific, there is no platform C
> code, everything is done in squeak slang then compiled into the VM as
> the mac menu bar plugin (used in Sophie btw).
>
>
> On 29-Jul-06, at 9:15 PM, Ron Teitelbaum wrote:
>
> > Hello all,
> >
> >
> >
> > I'm currently working on a TLS / SSL implementation and on windows
> > I am planning to support the Certificate Store that is built in.
> > This requires me to use the CryptoAPI dlls.  The code is complex
> > and it uses a number of header files and many steps.  I built some C
> > ++ code that does what I'm looking for so now I would like to
> > incorporate this into Squeak.
> >
> >
> >
> > I'd assumed that FFI was like DDL/C connect in VW but that's not
> > what I'm seeing.  So my question is: What is the best way to get
> > this working?  Should I hack away at FFI and support the api
> > directly, and is that even possible?  Should I create DLL's to call
> > and use them with FFI, or should I compile some sort of plugins?
> > My preference would be to call the api directly without having to
> > create dll's, duplicating my C++ code in Smalltalk if possible.
> >
> >
> >
> > Some direction and comparisons of different options would be very
> > helpful.
> >
> >
> >
> > Thank you for your help!
> >
> >
> >
> > Ron Teitelbaum
> >
> >
>
> --
> ========================================================================
> ===
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ========================================================================
> ===
>

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Andreas Raab
> Sent: Sunday, July 30, 2006 4:07 AM
> To: The general-purpose Squeak developers list
> Subject: Re: Suggestions for C++ or DLL code
>
> Ron Teitelbaum wrote:
> > I'd assumed that FFI was like DDL/C connect in VW but that's not what
> > I'm seeing.  So my question is: What is the best way to get this
> > working?
>
> My first question is: What is it that you're trying to get working? My
> second one: In which way is the FFI not like DLL/C connect in VW and why
> would that matter?
>
> Cheers,
>    - Andreas
>

> From: Andreas Raab
> Sent: Monday, July 31, 2006 3:22 AM
>
> Personally I only use the FFI for OpenGL and here we punt by
> implementing those functions that deal with complex data structures in
> primitives and only expose the ones with the trivial interfaces. If that
> is an option for you, it's a very useful one.
>
> Cheers,
>    - Andreas
>

> From: Bert Freudenberg
> Sent: Monday, July 31, 2006 12:37 PM
> Am 30.07.2006 um 06:15 schrieb Ron Teitelbaum:
> > Hello all,
> >
> > I'm currently working on a TLS / SSL implementation and on windows
> > I am planning to support the Certificate Store that is built in.
> > This requires me to use the CryptoAPI dlls.
> Well ... FFI is inherently unsafe - it allows to call any C function
> in any library. So depending on the area of application this might be
> a problem, since you're giving up the relative safety of a VM-based
> system. For example, if the VM's sandbox is enabled, FFI calls are
> disallowed, so you could not use crypto in a sandboxed environment.
>
> - Bert -
>
>

> From: tim Rowledge
> Sent: Monday, July 31, 2006 4:35 PM
>
> On 31-Jul-06, at 1:18 PM, Ron Teitelbaum wrote:
>
>
> > 2) Disable the compiler for accepting or performing new code, but
> > allow it
> > for already coded performs.  (I'm sure this is much easier said
> > then done).
> If you're using the same terminology that I'm used to, you don't need
> the compiler to execute #perform: type messages. All that does is
> tell the vm to pretend that the relevant message had been sent in the
> usual way. Similarly for blocks.
>
> Hmm, I should probably qualify that with a "unless someone has
> recently massively changed the system in a way that would render them
> a target of the 'Ninjas of Smalltalk Doom'".
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: SFA: Seek Financial Assistance
>
>
>

>...
>
>The thing that concerns me is changes to a live system that happen without
>needing to save the image.  Plenty can happen as the system is running so
>the question is: how can we secure the image while it is running?  
>
>Some things that would be needed off the top of my head are:
>
>1) Disable file in
>2) Disable the compiler for accepting or performing new code, but allow it
>for already coded performs.  (I'm sure this is much easier said then done).
>3) Disable interactive debugger.
>4) Enable some sort of class level MAC checking which can verify that no
>changes were made to code before it is executed.
>5) Prevent changes to compiled methods
>
>Plus more that I'm sure will also be needed.  If we can sign the image and
>VM and change the VM to check the signature before staring up and find a way
>to protect the live image then we will have gone a long way to having a more
>secure development platform.
>
>I've mentioned this before and got absolutely no comment from anyone.
>(Maybe the email was too long to read?)
>  
>

> From: Hans-Martin Mosner
> Sent: Monday, July 31, 2006 4:50 PM
>
> Ron Teitelbaum wrote:
>
> >...
> >
> >The thing that concerns me is changes to a live system that happen
> without
> >needing to save the image.  Plenty can happen as the system is running so
> >the question is: how can we secure the image while it is running?
> >
> >Some things that would be needed off the top of my head are:
> >
> >1) Disable file in
> >2) Disable the compiler for accepting or performing new code, but allow
> it
> >for already coded performs.  (I'm sure this is much easier said then
> done).
> >3) Disable interactive debugger.
> >4) Enable some sort of class level MAC checking which can verify that no
> >changes were made to code before it is executed.
> >5) Prevent changes to compiled methods
> >
> >Plus more that I'm sure will also be needed.  If we can sign the image
> and
> >VM and change the VM to check the signature before staring up and find a
> way
> >to protect the live image then we will have gone a long way to having a
> more
> >secure development platform.
> >
> >I've mentioned this before and got absolutely no comment from anyone.
> >(Maybe the email was too long to read?)
> >
> >
> Some unstructured ideas from the top of my head:
> Securing a Smalltalk image is pretty difficult. The VM protects the
> system against a number of security holes such as buffer overflows etc.
> which would allow external attackers to compromise security. Protecting
> against internal attacks is much more difficult. If I were a computer
> security expert, I'd probably prefer an architecture where there is
> absolutely no possibility of adding new code to a running application.
> The Smalltalk image is *designed* to be the exact opposite of that :-)
> A truly secure VM/image combo would perhaps need to be done differently:
> The image should be split up into a read-only part containing classes
> and methods, and a writable part where the more mundane objects reside.
> Ideally, the read-only part would be protected using the hardware and OS
> mechanisms, so its integrity does not depend on the correctness of the
> VM and all its primitives.
> Of course, none of the development tools are supposed to be present in
> such an image, and even the hooks which they use should be carefully
> removed. There are some primitives (such as #become: and class-changing
> primitives) which a secure VM should either not implement or implement
> in a safer way.
> Checking the code integrity with checksums etc. is certainly a necessity.
> Linking to and depending on external code without checking its integrity
> as well is probably a no-no. Static linking is probably ok.
>
> In any case, soothing the paranoia of security experts is going to be a
> difficult task. Once you know how many possibilities there are for
> tampering with software, you understand why...
>
> Cheers,
> Hans-Martin

> Am 30.07.2006 um 06:15 schrieb Ron Teitelbaum:
> > Hello all,
> >
> > I’m currently working on a TLS / SSL implementation and on windows
> > I am planning to support the Certificate Store that is built in.
> > This requires me to use the CryptoAPI dlls.
>
> Well ... FFI is inherently unsafe - it allows to call any C function
> in any library. So depending on the area of application this might be
> a problem, since you're giving up the relative safety of a VM-based
> system. For example, if the VM's sandbox is enabled, FFI calls are
> disallowed, so you could not use crypto in a sandboxed environment.
>
> - Bert -

> Bert,
>
> Thank you for your comments, I wasn't planning on using the sandbox since
> there are a number of external connections like Glorp-PostgreSQL needed
> where I plan to ultimately use this new functionality.  I was hoping to
> address this with a signed image and VM.  A signed image and VM could keep
> any changes out of the system.
>
> The thing that concerns me is changes to a live system that happen without
> needing to save the image.  Plenty can happen as the system is running so
> the question is: how can we secure the image while it is running?
>
> Some things that would be needed off the top of my head are:
>
> 1) Disable file in
> 2) Disable the compiler for accepting or performing new code, but allow it
> for already coded performs.  (I'm sure this is much easier said then done).

> Ron Teitelbaum
>
> > From: Bert Freudenberg
> > Sent: Monday, July 31, 2006 12:37 PM
> >
> > Am 30.07.2006 um 06:15 schrieb Ron Teitelbaum:
> > > Hello all,
> > >
> > > I'm currently working on a TLS / SSL implementation and on windows
> > > I am planning to support the Certificate Store that is built in.
> > > This requires me to use the CryptoAPI dlls.
> >
> > Well ... FFI is inherently unsafe - it allows to call any C function
> > in any library. So depending on the area of application this might be
> > a problem, since you're giving up the relative safety of a VM-based
> > system. For example, if the VM's sandbox is enabled, FFI calls are
> > disallowed, so you could not use crypto in a sandboxed environment.
> >
> > - Bert -

> From: nicolas cellier
> Sent: Monday, July 31, 2006 6:12 PM
>
> The main two questions are:
>
> 1) can you disable compiler ? (that means no doIt)
> 2) can you disable loading of compiled code and class by other means ?
>
> If you cannot remove compiler, then you must restrict its use.
>
> [snip]
>
> A restricted compiler must not have access to Smalltalk environment but
> only a
> restricted one.
> It must also have access to a restricted number of messages, expecially
> not
> the system reflexive ones like allOwners allInstances basicAt: subclasses
> become: etc...
> It is safer in this case to authorize a few than forbid a lot of messages.
>
> I did this kind of tricks in the days when ParcPlace runtime policy were
> really conservative. Maybe you will find more informations in commercial
> Smalltalk versions...

>
> > 3) Disable interactive debugger.
> > 4) Enable some sort of class level MAC checking which can verify that no
> > changes were made to code before it is executed.
>
> It is much simpler to close the system by reducing it's interface, than
> trying
> to secure the kernel.
>
> Anyway, what do mean before it is executed? Once image loaded does
> execution
> ever stop ? You mean at some strategic or random points of execution ?

>
> > 5) Prevent changes to compiled methods
> >
>
> You can try and lock MethodDictionary so that they do not accept to add
> remove
> or change any key/value, but for UndefinedObject doIt... (You just have to
> redefine few messages...). But you must make sure that there isn't a way
> to
> interpret some unbound CompiledMethod...
>
> Without restricted compiler, I can figure some attacks on such a lock,
> like
> creating a simple dictionary, copying compiled methods from here and there
> and changing class to that of MethodDictionary and then replacing
> MethodDictionary's MethodDictionary via a become:., all this in a single
> doIt...
>
> If you allow user relexive access to the Compiler, MethodDictionary or
> whatever you did protect, then your system is not closed enough.
>
> Then you can play the game to protect the protections, but untill you find
> a
> way to have a protection loop, that is just adding complexity to the
> system,
> and you might well add more weak points if your design is too complex...
>
> How to obtain a cyclic protection? That may be interesting...
>
> > Plus more that I'm sure will also be needed.  If we can sign the image
> and
> > VM and change the VM to check the signature before staring up and find a
> > way to protect the live image then we will have gone a long way to
> having a
> > more secure development platform.
> >
>
> And of course the plugins and DLL must be signed too.