Re: Cross-Compiling w/ FIPS Support from Linux to Windows

2021-03-11 Thread Bradley Gannon
I'm still struggling with this problem, but I have a little more
information. I learned from a close reading of `INSTALL.W32` and `.W64`
that support for 64-bit Windows is not stable, but support for 32-bit
Windows is okay, and that cross-compilation from Linux is possible. An
example given in `INSTALL.W32` seems to confirm that my environment
variables are close to correct, except for the 32/64-bit differences.

I made another attempt, this time targetting 32-bit Windows. Everything
is the same as my first message, except the environment variables:

```
export MACHINE="MINGW"
export SYSTEM="mingw"
export CROSS_COMPILE="i686-w64-mingw32-"
export HOSTCC="gcc"
export FIPS_SIG="${FIPS_HOME}/src/util/msincore"
```

The FOM build completes as expected, but I encountered [this
problem][0] having to do with multiple definitions. I applied the fix
that the OP describes there (i.e. renaming the offending symbols), and
the build continued. Unfortunately, it seems like nothing has changed,
because I still get the same error as before:

```
no fipstx section at ${FIPS_HOME}/src/util/msincore line 132.
```

If anyone has any information at all about this problem, I would
appreciate it if you sent it along.

Thank you,

Bradley

[0]: 
http://openssl.6102.n7.nabble.com/OpenSSL-1-0-1e-build-failure-using-MinGW-multiple-definition-of-OPENSSL-Uplink-td46492.html


signature.asc
Description: This is a digitally signed message part


Cross-Compiling w/ FIPS Support from Linux to Windows

2021-03-08 Thread Bradley Gannon
Hi there:

I'm trying to cross-compile FIPS-capable OpenSSL from Linux to Windows.
I already have a working native Linux build system, and I want to
extend it to support Windows targets without standing up a new host.

My cross-compile process follows the FOM User Guide to the best of my
understanding:

```
export MACHINE="MINGW64"
export SYSTEM="mingw64"
export CROSS_COMPILE="x86_64-w64-mingw32-"
export HOSTCC="gcc"
export FIPS_SIG="${FIPS_HOME}/src/util/msincore"

# build FIPS Object Module
cd ${FIPS_HOME}/src
./config
make
make install

# build OpenSSL
cd ${OPENSSL_HOME}/src
./config fips --prefix=${OPENSSL_FIPS} --with-fipsdir=${OPENSSL_FIPS}
make depend
make
make install
```

`FIPS_HOME`, `OPENSSL_HOME`, and `OPENSSL_FIPS` are the locations of
the FOM source tree, the OpenSSL source tree, and the output directory,
respectively.

The first failure occurs during the FOM `make install` step. The error
is:

```
cp: cannot stat 'fips_standalone_sha1': No such file or directory
```

It turns out that the build steps I've written above produce
`fips_standalone_sha1.exe`, which `make install` can't find. That's a
problem for me, because I know it's against the FIPS certification to
modify anything in the work area, but I can't seem to proceed without
changing that file name.

Just to expose another issue let me violate the certification
temporarily to bypass the problem. When I insert this command before
`make install`:

```
mv ./fips/fips_standalone_sha1.exe ./fips/fips_standalone_sha1
```

the build continues through the FOM and into OpenSSL. In fact, it seems
to get either nearly or completely through `make` before failing at the
incore digest step:

```
no fipstx section at ${FIPS_HOME}/src/util/msincore line 132.
```

This seems to indicate that `msincore` is not getting the kind of
executable it expects, but I'm not sure how to resolve that. I can't
turn up anything interesting on the Web, since most cross-compilation
discussions seem to target Android or iOS. If anyone has any guidance,
I'd appreciate it.

Thank you,

Bradley


signature.asc
Description: This is a digitally signed message part