Suggestions for C++ or DLL code
Locked
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 _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
|
|
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 ======================================================================== === _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
RE: Suggestions for C++ or DLL code
|
|
John,
Thank you very much for your response, it appears that you support DLL's to wrap and simplify Api's. This is doable but I wonder about maintainability and prefer not to push code outside of Smalltalk if possible for that reason. Although, I'm sure that it is the easier way to go, and probably the path I will take. Also given the cryptographic nature of the code that I'm writing and the need eventually to have the code certified, adding another level of code between the MS API and Squeak leaves another layer to protect. Thanks again for giving me more to consider, 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 > ======================================================================== > === > _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
RE: Suggestions for C++ or DLL code
|
|
In reply to this post by Ron Teitelbaum
Andreas,
I'm supporting the certificate store of windows. I will be reading and writing certificates to be used for SSL/TLS. The reason for this is to simplify some of the tasks needed to support SSL and to support what is already perceived to be a safe storage method in windows. (I am also thinking about supporting LDAP for storage instead but that is down the road, first things first) As for the VW dll/c connect code. I found the ability to set up libs and header files and automatically generate code very useful. Looking at the FFI kernel it appears that the pieces are there for me to assemble manually, which I why I asked the question if it is possible. What concerns me most is having to dissect the 5 or 6 very large header files that are needed to support the few api calls that are made. Are there some good examples of more complex FFI calls and structures, or easier ways to support many different required header files? I haven't downloaded the VMMaker or looked at slang, do you suggest I look at that first before deciding on which path to take? Thanks for you help, Ron Teitelbaum > -----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 > _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
Re: Suggestions for C++ or DLL code
|
|
In reply to this post by Ron Teitelbaum
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 - _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
Securing the VM and Image (was: Suggestions for C++ or DLL code)
|
|
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). 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 input would be very much appreciated. 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 - > > _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
Re: Securing the VM and Image (was: Suggestions for C++ or DLL code)
|
|
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 _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
Re: Securing the VM and Image
|
|
In reply to this post by Ron Teitelbaum
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?) > > 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 _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
|
|
Hans-Martin,
Thank you for your thoughts! I'm not sure the separation of code to isolate read only classes would be of much help since most of the problem lives in the memory model not in the stored code on disk. I would think that placing a certificate on the image file would be good enough "IF" we could prevent changes to the object structure and code in memory. #become is a real problem since it is a very necessary part of proxy handling for almost all db interfaces I've worked with (including GLORP). I wonder how much of this could be solved by on the fly checksums for everything. A few years ago this would have been impossible but with today performance is it really out of the question? I agree with the need to remove the development tools. As for the appeasing the security hacks: It's a nice challenge and I can tell you that "good enough security" is all anyone can ask for. If we set the bar too high we prevent advances in security that will do nothing but help to make a bad situation better. Ron Teitelbaum > 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 _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
|
|
In reply to this post by Hans-Martin Mosner
On 31-Jul-06, at 1:50 PM, Hans-Martin Mosner wrote: > 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. Ah, I'll note that the squeak VM really hasn't been hardened against attack, it's much less paranoid than the VW VM. In many places we might pass a ByteArray and a length, where the length is calculated from the ByteArray in Smalltalk however nothing prevents someone from making that VM call with a bogus ByteArray and length and see if something interesting will happen. Of course if the host operating system API provides some interesting side effect ,when passing correctly constructed information from our viewpoint, the VM won't prevent attack. Really *all* VM entry point would need to be looked at in a proper audit to avoid buffer overflow issues, even perhaps accidents which generally are fatal. Yes yes, someday I promised making a list of the entry points, however workload seems to be stalling that event. Perhaps someone would be interested? That also needs to be done in order to create a set of SUnits so we can enable some degree of cross platform testing and help people who want to build a VM on a new platform. -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
|
|
Hi-- John writes: > Yes yes, someday I promised making a list of the entry points, however > workload seems to be stalling that event. Perhaps someone would be > interested? I also intend to do this eventually. I would do it now if it were paid. -C -- Craig Latta http://netjam.org/resume _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
|
|
In reply to this post by Ron Teitelbaum
Hi Ron-- > I would think that placing a certificate on the image file would be > good enough "IF" we could prevent changes to the object structure and > code in memory. Doesn't that go out the window the first time you allocate and/or do a GC? -C -- Craig Latta http://netjam.org/resume _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
RE: re: Securing the VM and Image
|
|
Craig,
I would say that generally it is the responsibility of the developer (or company) to ensure that what is in the image and what can be created by the image is secure enough for the purpose that it is created. Obviously no company can protect itself from a government (especially ours) but a lot can be done to protect the system from well defined threats scenarios. Adding cryptography to the system communications, and protecting the image so that it performs only as the developer intends without change, plus using standard test to verify implementations of critical algorithms does make things better. I would think that the best possible way to make a secure image is to build from the bottom up, with something like spoon, to add only the code that is necessary. To perform extensive automated code coverage tests. To harden the image and the VM to check code before it is executed against a release certificate. To add proper intrusion detection to disable the software if tampering is detected and to encrypt everything stored to disk including the image and the VM. That along with securing the communications should make the system good enough. (Using the proper algorithms like suite B and having observed NIST common criteria or having NIST certification of the software also helps). What really gets me is that I've been programming in Smalltalk for 10 years now. I've written programs for a 2 billion dollar company. I know that Sprint uses Smalltalk for switching, and there are some very large insurance companies that use Smalltalk. It just can not be possible that Smalltalk is only appropriate for corporate intranet applications and can not be secured for the internet. Either I'm missing something or this is something that this group can add to the value of the language. Ron Teitelbaum > From: Craig Latta > Sent: Tuesday, August 01, 2006 12:17 AM > > > Hi Ron-- > > > I would think that placing a certificate on the image file would be > > good enough "IF" we could prevent changes to the object structure and > > code in memory. > > Doesn't that go out the window the first time you allocate and/or > do a GC? > > > -C > > -- > Craig Latta > http://netjam.org/resume > > > _______________________________________________ > Cryptography mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography _______________________________________________ Cryptography mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography |
«
Return to Squeak - Cryptography
|
1 view|%1 views
| Free forum by Nabble | Edit this page |