[Solved] Fix hardening-no-pie with fpc > 3.0.4

[Fred vS]

Hello.

Following the instruction to make a debian compatible package: https://wiki.freepascal.org/Debian_package_structure

Checking the archive

Once you've created the package, you can check it follows the guidelines with the command lintian:

lintian "${PACKAGE_NAME}.deb" --info

Here is the list of potential problems: https://lintian.debian.org/tags.html

With Lazarus, you will get by default the hardening-no-pie (and hardening-no-bindnow warnings in mentors). To avoid such warnings, add the following compiler options in the project options:

-Cg
-k-pie
-k-znow

So I did in console:

Code: Pascal  [Select][+][-]

1. lintian "${PACKAGE_NAME}.deb" --info

And get this:

W: myprog: hardening-no-pie usr/bin/myprog

In wiki, it said:

With Lazarus, you will get by default the hardening-no-pie (and hardening-no-bindnow warnings in mentors). To avoid such warnings, add the following compiler options in the project options:

-Cg
-k-pie
-k-znow

OK, I added those -Cg -k-pie -k-znow options for compilation.

All ok using fpc 3.0.4 and 3.0.5, compilation is ok, run too.

But with fpc >= 3.2.0 there is that error at linking:

9015) Linking myprog
/usr/bin/ld: /home/fred/fpc3.2.2/units/x86_64-linux/rtl/si_c.o: warning: relocation in read-only section `.text.n_si_c_$$__fpc_libc_start'
/usr/bin/ld: /home/fred/fpc3.2.2/units/x86_64-linux/rtl/si_c.o: relocation R_X86_64_PC32 against symbol `__libc_start_main@@GLIBC_2.2.5'
 can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: final link failed: bad value
Error: (9013) Error while linking
Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted

I did try recompile with -fPIE like said in message but this is not accepted by the compiler.
Maybe it will say to recompile with -fPIC, I did try but it does not help.

How to fix that error at linking using fpc >= 3.2.0 ?

Thanks.

Fre;D

[winni]

Dear Fre;D

Debian is a good and stable sysem for servers.
But it is horrible for the desktop.

There are so many linux distros.

Leave Debian

Winni

[Fred vS]

Dear Fre;D

Debian is a good and stable sysem for servers.
But it is horrible for the desktop.

There are so many linux distros.

Leave Debian

Winni

Dear Winni.

Debian is the Original and many others are forks of him ( Ubuntu and friends ).
But here the problem concern the debian packages ( used by all the forks ) not the Debian OS .

There is a check-progam named "lintian" https://en.wikipedia.org/wiki/Lintian that analyses the content of the package deb and if something fails, it will not be accepted in the Debian deb-repository (used by all the forks).
And the problem with fpc binaries is that by default you will have that warning : hardening-no-pie

And the solution, like explained in first post, will work only with fpc <= 3.0.5.

So, back to the initial question: how to make work -Cg -k-pie -k-znow options with fpc > 3.0.5 ?

Fre;D

[Fred vS]

For example, with LazPaint last deb release, I get this:

fred@fredvs ~> lintian --info lazpaint7.1.6_linux64.deb
W: lazpaint: hardening-no-pie usr/bin/lazpaint
N:
W: hardening-no-pie
N:
N:   This package provides an ELF executable that was not compiled as a
N:   position independent executable (PIE).
N:   
N:   In Debian, since version 6.2.0-7 of the gcc-6 package GCC will compile
N:   ELF binaries with PIE by default. In most cases a simple rebuild will
N:   be sufficient to remove this tag.
N:   
N:   PIE is required for fully enabling Address Space Layout Randomization
N:   (ASLR), which makes "Return-oriented" attacks more difficult.
N:   
N:   Historically, PIE has been associated with noticeable performance
N:   overhead on i386. However, GCC >= 5 has implemented an optimization
N:   that can reduce the overhead significantly.
N:   
N:   If you use dpkg-buildflags with hardening=+all,-pie in
N:   DEB_BUILD_MAINT_OPTIONS, remove the -pie.
N:   
N:   Refer to https://wiki.debian.org/Hardening,
N:   https://gcc.gnu.org/gcc-5/changes.html, and
N:   https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode
N:   for details.
N:   
N:   Severity: warning
N:   
N:   Check: binaries
N:

But re-compiling lazpaint with option -Cg -k-pie -k-znow fails.

[EDIT] Maybe interesting for Lazarus deb package: try to do a lintian-check and see the result:

Code: Bash  [Select][+][-]

1. $>  lintian --info lazarus-project_2.2.0RC1-0_amd64.deb

[dbannon]

Fred, I use

Code: [Select]

" -Cg  -k-pie -k-znow "
with my app and it compiles fine with FPC320, I manage to get the  lintian test  down to one or two unimportant warnings, this is the lintian command that 'mentors' like you to use -

Code: [Select]

lintian -IiE --pedantic *.changes
Running that command on most non-repository deb packages can be quite scary !  My build script does not do anything else to make those compiler switches acceptable, so, I suspect maybe there is something in your code that does not want to be relocated ? I really cannot imagine what ....

Davo 

[marcov]

If I look at that linking error, it sounds like the startup code was not compiled with -Cg (which is probably FPC's equivalent for -fPIE)

If this is a very new install, it might also have to do something with the glibc changes that Fedora users complain about.

[Fred vS]

Fred, I use

Code: [Select]

" -Cg  -k-pie -k-znow "
with my app and it compiles fine with FPC320, I manage to get the  lintian test  down to one or two unimportant warnings, this is the lintian command that 'mentors' like you to use -

Code: [Select]

lintian -IiE --pedantic *.changes
Running that command on most non-repository deb packages can be quite scary !  My build script does not do anything else to make those compiler switches acceptable, so, I suspect maybe there is something in your code that does not want to be relocated ? I really cannot imagine what ....

Davo

Hello Davo.

Thanks to answer.

Fred, I use

Code: [Select]

" -Cg  -k-pie -k-znow "

Ha, so with fpc 3.2.0 it is possible, good news.

Sadly all the programs that I tested fail to compile-link with fpc 3.2.0 (even LazPaint ) and with those compiler options.
And there are no help from the debugger, only that error message:

9015) Linking myprog
/usr/bin/ld: /home/fred/fpc3.2.2/units/x86_64-linux/rtl/si_c.o: warning: relocation in read-only section `.text.n_si_c_$$__fpc_libc_start'
/usr/bin/ld: /home/fred/fpc3.2.2/units/x86_64-linux/rtl/si_c.o: relocation R_X86_64_PC32 against symbol `__libc_start_main@@GLIBC_2.2.5'
 can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: final link failed: bad value
Error: (9013) Error while linking
Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted

Also, why to say in that message to recompile with -fPIE if that parameter is not ok for fpc ?

Fred

[Fred vS]

If I look at that linking error, it sounds like the startup code was not compiled with -Cg (which is probably FPC's equivalent for -fPIE)

If this is a very new install, it might also have to do something with the glibc changes that Fedora users complain about.

Hello Marcov.

I did add those compiler options:
-Cg  -k-pie -k-znow

I tested it on last Debian 11 OS.

Fre;D

[Fred vS]

Note that compiling with fpc 3.0.4 or 3.0.5 and -Cg  -k-pie -k-znow  is ok, no error.
But with fpc 3.2.0 it does not link.

[dbannon]

Hmm, Fred, these are my notes on building tomboy-ng, https://github.com/tomboy-notes/tomboy-ng/blob/master/prepare.md

If you have FPC and Lazarus installed (and I am sure you do) you should be able to do the the "Building just a tomboy-ng Binary" down the bottom of those notes. It won't make the deb src (unless you add the full build env stuff) but if it makes the binary, then that frees the OS from being the problem.

I have not done anything special with "startup code" that Marcov mentions.

edit: from memory, the -k says pass this to the linker ?? Is that right ?

Davo

[marcov]

Note that compiling with fpc 3.0.4 or 3.0.5 and -Cg  -k-pie -k-znow  is ok, no error.
But with fpc 3.2.0 it does not link.

The startup code is part of the compiler distribution. Again, when compiling FPC make sure the startup code is compiled with -Cg. It might not be that (it could be that there is an assembler section in that file that doesn't support PIE), but it is worth double checking. Anyway, surprising that x86_64 are not PIE in the first place, I thought that was a given

[Fred vS]

Hello Davo.

Hum, I downloaded your last release and this is the result I get with lintian:

Code: Pascal  [Select][+][-]

1. fred@fredvs ~> lintian --info /home/fred/Downloads/tomboy-ng_0.33a-0_amd64.deb

Result:

W: tomboy-ng: hardening-no-pie usr/bin/tomboy-ng
N:
W: hardening-no-pie
N:
N:   This package provides an ELF executable that was not compiled as a
N:   position independent executable (PIE).
N:   
N:   In Debian, since version 6.2.0-7 of the gcc-6 package GCC will compile
N:   ELF binaries with PIE by default. In most cases a simple rebuild will
N:   be sufficient to remove this tag.
N:   
N:   PIE is required for fully enabling Address Space Layout Randomization
N:   (ASLR), which makes "Return-oriented" attacks more difficult.
N:   
N:   Historically, PIE has been associated with noticeable performance
N:   overhead on i386. However, GCC >= 5 has implemented an optimization
N:   that can reduce the overhead significantly.
N:   
N:   If you use dpkg-buildflags with hardening=+all,-pie in
N:   DEB_BUILD_MAINT_OPTIONS, remove the -pie.
N:   
N:   Refer to https://wiki.debian.org/Hardening,
N:   https://gcc.gnu.org/gcc-5/changes.html, and
N:   https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode
N:   for details.
N:   
N:   Severity: warning
N:   
N:   Check: binaries
N:
W: tomboy-ng: synopsis-too-long
N:
W: synopsis-too-long
N:
N:   The first line of the "Description:" must be less than 80 characters
N:   long.
N:   
N:   Refer to Debian Policy Manual section 3.4.1 (The single line synopsis)
N:   for details.
N:   
N:   Severity: warning
N:   
N:   Check: fields/description
N:   
N:   Renamed from: description-too-long
N:

W: tomboy-ng: syntax-error-in-debian-changelog line 3 "badly formatted heading line"
N:
W: syntax-error-in-debian-changelog
N:
N:   While parsing the Debian changelog, a syntax error was found. If you
N:   have old changelog entries that don't follow the current syntax but
N:   that you want to keep as-is for the historical record, add the line:
N:   
N:     Old Changelog:
N:   
N:   with no leading whitespace before the legacy entries. This line and
N:   everything after it will be ignored.
N:   
N:   Refer to Debian Policy Manual section 4.4 (Debian changelog:
N:   debian/changelog) for details.
N:   
N:   Severity: warning
N:   
N:   Check: debian/changelog
N:
W: tomboy-ng: syntax-error-in-debian-changelog line 3 "found eof where expected more change data or trailer"

[Fred vS]

Note that compiling with fpc 3.0.4 or 3.0.5 and -Cg  -k-pie -k-znow  is ok, no error.
But with fpc 3.2.0 it does not link.

The startup code is part of the compiler distribution. Again, when compiling FPC make sure the startup code is compiled with -Cg. It might not be that (it could be that there is an assembler section in that file that doesn't support PIE), but it is worth double checking. Anyway, surprising that x86_64 are not PIE in the first place, I thought that was a given

Hello Marcov.

Sorry but I dont understand The startup code is part of the compiler distribution.

What is the startup code?

[marcov]

Sorry but I dont understand The startup code is part of the compiler distribution.

What is the startup code?

si_c is the startup code for x86_64, iow the piece of code that starts executing when the binary is loaded. Under Linux it is pascal unit (rtl/linux/si_c.pp), but with some assembler parts.

[Fred vS]

Sorry but I dont understand The startup code is part of the compiler distribution.

What is the startup code?

si_c is the startup code for x86_64, iow the piece of code that starts executing when the binary is loaded. Under Linux it is pascal unit (rtl/linux/si_c.pp), but with some assembler parts.

Ha, ok, thanks for the info.
But then, could it be possible that rtl/linux/si_c.pp from fpc 3.2.0 has problems?

Was there change in that unit in fpc 3.2.0 vs fpc 3.0.4 ?