On Tue, Feb 21, 2012 at 3:51 PM, Andy Polyakov wrote:
>> Another option (but shoot it down if its bogus :-): I noticed that if I
>> compile
>> fipscanister.o without "-fPIC", then the const variables do get placed in
>> the (really readonly) .rodata section as desired. I thought maybe if I did
>>
On Tue, Feb 21, 2012 at 3:51 PM, Andy Polyakov wrote:
>> Another option (but shoot it down if its bogus :-): I noticed that if I
>> compile
>> fipscanister.o without "-fPIC", then the const variables do get placed in
>> the (really readonly) .rodata section as desired. I thought maybe if I did
>>
> Another option (but shoot it down if its bogus :-): I noticed that if I
> compile
> fipscanister.o without "-fPIC", then the const variables do get placed in
> the (really readonly) .rodata section as desired. I thought maybe if I did
> that and went the static route - build libcrypto with no-sh
On Tue, Feb 21, 2012 at 1:11 PM, Andy Polyakov wrote:
>> Though in FIPS 2.0 there is new option that might work in this case.
>> Besides switching to another compiler that is. Introduced to rectify
>> situation with rodata segments not being position-independent on Win64,
>> defini
> Though in FIPS 2.0 there is new option that might work in this case.
> Besides switching to another compiler that is. Introduced to rectify
> situation with rodata segments not being position-independent on Win64,
> defining __fips_constseg might prove useful even in this situatio
On Mon, Feb 20, 2012 at 5:18 AM, Andy Polyakov wrote:
>
> >>> Though in FIPS 2.0 there is new option that might work in this case.
> >>> Besides switching to another compiler that is. Introduced to rectify
> >>> situation with rodata segments not being position-independent on Win64,
> >>> defining
>>> Though in FIPS 2.0 there is new option that might work in this case.
>>> Besides switching to another compiler that is. Introduced to rectify
>>> situation with rodata segments not being position-independent on Win64,
>>> defining __fips_constseg might prove useful even in this situation. See
>
On Sun, Feb 19, 2012 at 3:50 PM, Kevin Fowler wrote:
>
>
> On Sun, Feb 19, 2012 at 11:52 AM, Andy Polyakov wrote:
>
>> >>> After I had gotten the extra "-f" options from Harvey for this
>> platform
>> >>> (BSD-powerpc),
>> >> Using -f[data|function]-sections options is inappropriate as they
>> >
On Sun, Feb 19, 2012 at 11:52 AM, Andy Polyakov wrote:
> >>> After I had gotten the extra "-f" options from Harvey for this platform
> >>> (BSD-powerpc),
> >> Using -f[data|function]-sections options is inappropriate as they
> >> undermine the idea of "capturing" fipscanister code and rodata betw
>>> After I had gotten the extra "-f" options from Harvey for this platform
>>> (BSD-powerpc),
>> Using -f[data|function]-sections options is inappropriate as they
>> undermine the idea of "capturing" fipscanister code and rodata between
>> start/end symbols. It was bad advice/idea, do *not* use th
On Sat, Feb 18, 2012 at 6:13 PM, Andy Polyakov wrote:
> > The key thing I realized is that the incore script that comes with the
> FIPS
> > Object Module v2.0 tarball
> > handles both native AND cross-compile scenarios.
>
> Even though FIPS 2.0 util/incore is capable of handling arbitrary ELF
>
> The key thing I realized is that the incore script that comes with the FIPS
> Object Module v2.0 tarball
> handles both native AND cross-compile scenarios.
Even though FIPS 2.0 util/incore is capable of handling arbitrary ELF
binary (native or not), it's not used in non-cross-compile/native cas
On Fri, Feb 17, 2012 at 10:25 PM, Dr. Stephen Henson wrote:
> On Fri, Feb 17, 2012, Kevin Fowler wrote:
>
> > Thanks Harvey,
> > This seems to have worked as far as getting the .rodata section used.
> This
> > is what I see now:
> >
> > 001b5740 g O .rodata0010 FIPS_rodata_start
>
Thanks Harvey,
This seems to have worked as far as getting the .rodata section used. This
is what I see now:
001b5740 g O .rodata0010 FIPS_rodata_start
001b5750 l O .rodata0011 FIPS_hmac_key
001b57bc g O .rodata0036 FIPS_bn_version
001c1e08 g O .
Hi Kevin,
I encountered this problem when compiling the 1.2.3 FIPS object module some
time ago, with exactly the same compiler. After some experimentation I managed
to get it to embed the fingerprint correctly using the following compiler
options:
-fno-common -fdata-sections -ffunction-section
15 matches
Mail list logo
