2009/2/27 Steve Marquess <marqu...@oss-institute.org>: > Kyle Hamilton wrote: >> The answer to your question is: there might be, but this is FAR >> beyond the level where anyone other than a specialist will be able to >> help you. > > How true. I've hesitated to weigh in on this thread because of the > complications that make my head hurt.
I'm glad I'm not the only one who had to pull out the ibuprofen. :P >> More notably, the security policy does NOT state that you must use >> the provided fipsld script to link. As long as all the steps >> performed by the fipsld script are performed, then you will be able >> to use FIPS_mode_set() from within your monolithic kernel. > > Yes, the fipsld script proper is not required (for the Windows platform > it isn't used at all). However, the two step linking operation that > fipsld performs is required. In this sense the cryptographic module > boundary at the point where fipscanister.o has been created consists not > only of that file but also the ancillary files fipscanister.o.sha1, > fips_premain.c, and fips_premain.c.sha1 files. Er... my biggest question actually wasn't answered here. The two-step linking process involves the creation of the library memory image/memory segment (which is the entire reason for the fips_premain.c requirement, I think?), but is it required that the premain function actually be called before the entry point into the program itself? If the answer to this is "yes", then it's not possible -- the kernel needs to initialize itself and its data structures before it can run any other code. If it's simply a requirement that the premain code be executed before the library has any opportunity to run any other initialization code, then it might be possible. It *would*, however, be a lot easier if it were a kernel module. Aside from getting around the licensing issues (it'd taint the kernel, but it wouldn't require GPL compatibility), it would also be possible to run the premain code on load. > So, can the v1.2 fipscanister.o be legitimately used in a linux kernel > module? Theoretically I think it *may* be possible in a technical > sense, though I haven't written any kernel modules myself. Start with > fipscanister.o and the ancillary files, and roll your own fipsld > equivalent that performs the two step link. However, the kernel > contains other crypto that isn't validated (and isn't even from > openssl), so it's an interesting philosophical question to say under > what circumstances what parts of that Linux system can claim to be FIPS > validated. The usual block diagrams included in FIPS validations show > the operating system as one monolithic block, and kernel modules could > legitimately be considered to be part of the core O/S and hence not part > of any userspace application at all. Legally speaking (and this is primarily coming from the Free Software Foundation's pages), the license of OpenSSL prevents the distribution of a GPL'd software that links directly to it (in a monolithic sense), unless the copyright owner of the GPL-licensed software adds an explicit exemption for OpenSSL's "obnoxious BSD advertising clause" requirement. This legal issue essentially makes it a non-starter in the monolithic kernel concept currently discussed. > So, if the reason for adding the crypto to a kernel module was to > support a userspace application one could speculate that the application > could be FIPS validated independently of that kernel and hence that > kernel module. If the reason was to claim FIPS validation for the > entire kernel then you have a much bigger problem because of the other > existing crypto in the kernel. This would be a VERY interesting mechanism to bring into the mainline Linux kernel -- the ability to set a sysparm so that any call to any of the crypto implementations will be redirected to the FIPS module imported from OpenSSL. However, there's an additional quandary in this concept: the FIPS validation for OpenSSL is explicitly for a "single-user system". This specifically means that any system with multiple users is in violation of the security policy, and thus not running in a validated mode. > At any rate I think that's a scripture question that would have to be > interpreted by the priesthood (the CMVP). It's certainly above my pay > grade. > > -Steve M. The CMVP was never set up to handle people wanting to do weird stuff with cryptographic modules for which the source code is available. Then again, it was never set up to handle open source in any manner anyway. The simplest answer I can come up with is: ugh. No. Just... no. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
