Lazarus

Programming => Operating Systems => Linux => Topic started by: Fred vS on October 21, 2021, 11:37:38 pm

Title: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 21, 2021, 11:37:38 pm

Hello.

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

Quote

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:

Quote

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

In wiki, it said:

Quote

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:

Quote

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

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: winni on October 21, 2021, 11:50:15 pm

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

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 22, 2021, 12:29:02 am

Quote from: winni on October 21, 2021, 11:50:15 pm

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

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 22, 2021, 01:02:35 am

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

Quote

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

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: dbannon on October 22, 2021, 07:07:03 am

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 

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: marcov on October 22, 2021, 11:05:52 am

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.

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 22, 2021, 11:06:29 am

Quote from: dbannon on October 22, 2021, 07:07:03 am

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.

Quote

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:

Quote

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

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 22, 2021, 11:08:57 am

Quote from: marcov on October 22, 2021, 11:05:52 am

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

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 22, 2021, 11:13:49 am

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.

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: dbannon on October 22, 2021, 11:25:07 am

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

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: marcov on October 22, 2021, 11:35:22 am

Quote from: Fred vS on October 22, 2021, 11:13:49 am

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

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 22, 2021, 11:36:27 am

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:

Quote

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"

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 22, 2021, 11:39:15 am

Quote from: marcov on October 22, 2021, 11:35:22 am

Quote from: Fred vS on October 22, 2021, 11:13:49 am

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?

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: marcov on October 22, 2021, 11:41:43 am

Quote from: Fred vS on October 22, 2021, 11:39:15 am

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.

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 22, 2021, 11:49:45 am

Quote from: marcov on October 22, 2021, 11:41:43 am

Quote from: Fred vS on October 22, 2021, 11:39:15 am

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 ?

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: marcov on October 22, 2021, 12:24:04 pm

Quote from: Fred vS on October 22, 2021, 11:49:45 am

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

You are the git expert, not me :-)

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: dbannon on October 22, 2021, 12:52:15 pm

Quote from: Fred vS on October 22, 2021, 11:36:27 am

Hello Davo.

Hum, I downloaded your last release and this is the result I get with lintian:
...
W: hardening-no-pie

Damm, I must have dropped the hardening out of the DIY binary, its only there in the version I send to Debian. Sigh ...

I'll confirm that and let you know.

Davo

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: dbannon on October 22, 2021, 01:22:42 pm

Sorry Fred, I see the problem. You have downloaded one of my release binary packages and run lintian on that ?  No, I do not harden my normal release packages, hardening is reported to slow then down and IMHO its not necessary on a desktop. And tomboy-ng is a desktop application.

I only do the hardening on the src package I send to debian to put in their distribution.

I suggested you build tomboy-ng on your system. The build receipt I sent you DOES apply hardening. once you have made the binary (not downloaded it from my github) you can use the file command as in the attached image, note it mentions 'pie'.
Davo

Title: Re: Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 22, 2021, 06:59:09 pm

Hello.

I did try to compile + link my application using last trunk fpc 3.3.1. and -Cg -k-pie -k-znow

And ...

 ;D

Here the note of the compiler:

Quote

9015) Linking strumpract
/usr/bin/ld: /usr/lib/fpc/3.3.1/units/x86_64-linux/rtl/si_c.o: warning: relocation against `SI_C_$$_INI_DUMMY' in read-only section `.text.n_si_c_$$__fpc_libc_start'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
(1008) 568211 lines compiled, 13.9 sec, 4011360 bytes code, 2658232 bytes data
(1021) 175 warning(s) issued
(1022) 3111 hint(s) issued
(1023) 407 note(s) issued

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

1. fred@fredvs ~> file /home/fred/strumpract/src/strumpract

Quote

/home/fred/strumpract/src/strumpract: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, stripped

Conclusion: OK, but only with fpc 3.3.1 or fpc 3.0.4.

Fre;D

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: dbannon on October 23, 2021, 01:54:53 am

Sorry Fred, I have to disagree.  If you tried what I suggested, you would too ! This is on a current debian bullseye using the debian repo FPC320 and Lazarus that you must use to test a src package.

Note I do see an warning I have not seen before but it does build a pie executable and that executable, when popped into a deb does not generate an hardening warning.

See attached image.

I have also built a deb src and tested it, I get a few new spelling warnings that will have to be fixed, thats all.

Davo

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 23, 2021, 02:27:33 am

Quote from: dbannon on October 23, 2021, 01:54:53 am

Sorry Fred, I have to disagree.  If you tried what I suggested, you would too !
Davo

Hello Davo.

Huh, may I know what you have to disagree?

I did try to compile tomboy-ng like you suggested, using source from your github site but it fails to compile with this:

Quote

savenote.pas(476,9) Error: Identifier not found "BulletOne"
savenote.pas(476,21) Error: Constant Expression expected
savenote.pas(477,9) Error: Identifier not found "BulletTwo"
savenote.pas(477,21) Error: Constant Expression expected
savenote.pas(477,21) Error: duplicate case label
savenote.pas(478,9) Error: Identifier not found "BulletThree"
savenote.pas(478,21) Error: Constant Expression expected
savenote.pas(478,21) Error: duplicate case label
savenote.pas(479,9) Error: Identifier not found "BulletFour"
savenote.pas(479,21) Error: Constant Expression expected
savenote.pas(479,21) Error: duplicate case label
savenote.pas(480,9) Error: Identifier not found "BulletFive"
savenote.pas(480,21) Error: Constant Expression expected
savenote.pas(480,21) Error: duplicate case label
savenote.pas(481,9) Error: Identifier not found "BulletSix"
savenote.pas(481,21) Error: Constant Expression expected
savenote.pas(481,21) Error: duplicate case label
savenote.pas(482,9) Error: Identifier not found "BulletSeven"
savenote.pas(482,21) Error: Constant Expression expected
savenote.pas(482,21) Error: duplicate case label
savenote.pas(483,9) Error: Identifier not found "BulletEight"
savenote.pas(483,21) Error: Constant Expression expected
savenote.pas(483,21) Error: duplicate case label

I have quasi no experience with Lazarus or with LCL.

But I trust you if you was able to compile your program with -Cg parameter and fpc 3.2.0.

On my side, all the msegui programs that I did try to compile with -Cg fail with fpc 3.2.0. ( but ok with 3.0.4 ).

But the excellent news is that with fpc 3.3.1. the compilation is ok and linking too.

Anyway many thanks for your precious infos and sorry if I hurt you for something.

Fre;D

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: dbannon on October 23, 2021, 05:42:32 am

Certainly no hurt Fred.

It will not help you to compile with FPC3.3.1, if you submit your source package to Debian, it has to be compiled with the compiler on their build machine, right now, that appears to be Bullseye and Bullseye uses FPC3.2.0

So, you need to compile, without errors, on 3.2.0.

Please repeat that test with my code. Because I only build for Debian at release time, I had not checked it out before I sent you those instructions. And, sure enough, I had forgotten I have changed, temporary, where I get my kcontrols from. I fixed that some 12 hours ago, sorry I did not check first.

If you start again, bring down a new copy of prepare.ppa into a clean directory, it will (probably) all work. I have tried it here on two different VMs.

Anyway, the fact is, FPC3.2.0 will compile and link fine. Why its not for you is uncertain. I suspect that you build your own FPC ?  If that the case, Marcov's explanation may the the answer. However, to build for Debian, it must build using the Debian repo FPC.

Maybe it would be a good idea to install FPC from the debian repository ? After all, thats the one it has to work with.

Davo

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 23, 2021, 01:24:12 pm

Hello Dave.

I did:

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

1. sudo apt-get install fpc

OK, fpc from Debian 11 repository is installed.

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

1. @fredvs ~> fpc

Quote

Free Pascal Compiler version 3.2.0+dfsg-12 [2021/01/25] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others

So I try to compile with that fpc version ( before I did try with the official fpc 3.2.2 from fpc repository ).

Here the result with -Cg -k-znow -k-pie parameter:

Quote

Hint: (11030) Start of reading config file /etc/fpc.cfg
Hint: (11031) End of reading config file /etc/fpc.cfg
Free Pascal Compiler version 3.2.0+dfsg-12 [2021/01/25] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
(1002) Target OS: Linux for x86-64
(3104) Compiling strumpract.pas
...
/usr/bin/ld.bfd: units/filelistform.o: relocation R_X86_64_32S against symbol `TC_$MAIN_$$_HASINIT' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/msegui.o: relocation R_X86_64_32S against `.bss.n_u_$msegui_$$_appinst' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/main.o: relocation R_X86_64_32S against symbol `U_$RANDOMNOTE_$$_RANDOMNOTEFO' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/drums.o: relocation R_X86_64_32S against symbol `TC_$DRUMS_$$_WASCREATED' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/songplayer.o: relocation R_X86_64_32S against symbol `_$SONGPLAYER$_Ld1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/commander.o: relocation R_X86_64_32S against symbol `TC_$COMMANDER_$$_DOCALLBACK' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/config.o: relocation R_X86_64_32S against symbol `U_$UOS_FLAT_$$_UOSDEVICECOUNT' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/guitars.o: relocation R_X86_64_32S against symbol `U_$GUITARS_$$_AGUITAR' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/recorder.o: relocation R_X86_64_32S against symbol `U_$RECORDER_$$_XRECLIVE' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/imagedancer.o: relocation R_X86_64_32S against symbol `_$IMAGEDANCER$_Ld1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/status.o: relocation R_X86_64_32S against symbol `TC_$STATUS_$$_TYPSTAT' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/spectrum1.o: relocation R_X86_64_32S against symbol `U_$MAIN_$$_MAINFO' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/waveform.o: relocation R_X86_64_32S against symbol `U_$SONGPLAYER_$$_SONGPLAYERFO' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/randomnote.o: relocation R_X86_64_32S against symbol `_$RANDOMNOTE$_Ld1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/equalizer.o: relocation R_X86_64_32S against symbol `_$EQUALIZER$_Ld1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/findmessage.o: relocation R_X86_64_32S against symbol `TC_$FINDMESSAGE_$$_IMESSAGES' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/dialogfiles.o: relocation R_X86_64_32S against symbol `TC_$SYSUTILS_$$_DEFAULTFORMATSETTINGS' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/dockpanel1.o: relocation R_X86_64_32S against symbol `TC_$MSEGRAPHUTILS_$$_NULLPOINT' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/mseguiintf.o: relocation R_X86_64_32S against `.bss.n_u_$mseguiintf_$$_stringatom' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/msemenus.o: relocation R_X86_64_32S against symbol `RESSTR_$RTLCONSTS_$$_SLISTINDEXERROR' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/msefileutils.o: relocation R_X86_64_32S against symbol `TC_$MSEFILEUTILS_$$_SORTFLAGS' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/msegraphics.o: relocation R_X86_64_32S against symbol `U_$MSEGRAPHICS_$$_FLUSHGDI' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/msegraphutils.o: relocation R_X86_64_32S against symbol `TC_$MSEGRAPHUTILS_$$_DEFAULTNAMEDRGB' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/mseclasses.o: relocation R_X86_64_32S against `.bss.n_u_$mseclasses_$$_fmodules' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/mseforms.o: relocation R_X86_64_32S against `.data.n_TC_$MSEFORMS_$$_CONTAINERCOMMONFLAGS' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/msedock.o: relocation R_X86_64_32S against symbol `_$MSEDOCK$_Ld2' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/bgrapen.o: relocation R_X86_64_32S against symbol `_$BGRAPEN$_Ld3' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/bgrapath.o: relocation R_X86_64_32S against symbol `_$BGRAPATH$_Ld1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/bgrapolygon.o: relocation R_X86_64_32S against symbol `_$BGRAPOLYGON$_Ld1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/bgrapolygonaliased.o: relocation R_X86_64_32S against symbol `U_$BGRABITMAPTYPES_$$_GAMMAEXPANSIONTAB' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/bgrablend.o: relocation R_X86_64_32S against symbol `U_$BGRABITMAPTYPES_$$_GAMMAEXPANSIONTAB' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/bgraresample.o: relocation R_X86_64_32S against symbol `U_$BGRABITMAPTYPES_$$_BGRAPIXELTRANSPARENT' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/bgrafillinfo.o: relocation R_X86_64_32S against symbol `_$BGRAFILLINFO$_Ld1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/bgragradientscanner.o: relocation R_X86_64_32S against symbol `U_$BGRABITMAPTYPES_$$_GAMMAEXPANSIONTAB' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/bgrasse.o: relocation R_X86_64_32S against symbol `_$BGRASSE$_Ld1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/bgraarrow.o: relocation R_X86_64_32S against symbol `_$BGRAARROW$_Ld1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/msedatanodes.o: relocation R_X86_64_32S against symbol `TC_$MSEDATANODES_$$_STATSTATES' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/mseedit.o: relocation R_X86_64_32S against symbol
/usr/bin/ld.bfd: units/msefpreadpng.o: relocation R_X86_64_32S against symbol `TC_$MSEPNGCOMN_$$_CHUNKTYPES' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/mse_zstream.o: relocation R_X86_64_32S against symbol `RESSTR_$MSE_ZSTREAM_$$_SSEEK_FAILED' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: units/msefpimgcmn.o: relocation R_X86_64_32S against `.bss.n_u_$msefpimgcmn_$$_crctable' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld.bfd: /usr/lib/x86_64-linux-gnu/fpc/3.2.0/units/x86_64-linux/rtl/si_c.o: warning: relocation in read-only section `.text.n_si_c_$$__fpc_libc_start'
Error: (9013) Error while linking
Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted
Error: /usr/bin/ppcx64 returned an error exitcode

As you can see, many errors ( I removed lot of lines because too big for forum-site ) but not only from msegui, also from BGRABitmap and Zeos.

But compiling with fpc 3.3.1 or 3.0.4 = no error.

I dont have plan to give deb files for Debian repository, it is for testing the fpc feature and the possibility to create pie binary for msegui.

Fre;D

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: dbannon on October 24, 2021, 01:46:11 am

Quote from: Fred vS on October 23, 2021, 01:24:12 pm

....
I dont have plan to give deb files for Debian repository, it is for testing the fpc feature and the possibility to create pie binary for msegui.
....

Ah, I assumed, incorrectly, that you needed hardening to comply with Debian requirements. I should not guess.

Good luck with msegui, its a long way out of my limited experience space.

Davo

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on October 24, 2021, 02:33:36 am

Quote from: dbannon on October 24, 2021, 01:46:11 am

Quote from: Fred vS on October 23, 2021, 01:24:12 pm

....
I dont have plan to give deb files for Debian repository, it is for testing the fpc feature and the possibility to create pie binary for msegui.
....

Ah, I assumed, incorrectly, that you needed hardening to comply with Debian requirements. I should not guess.

Good luck with msegui, its a long way out of my limited experience space.

Davo

Yes, one of the goal of  hardening is also to comply with Debian requirements but for this, like you explained, I'm afraid I will have to wait until fpc 3.3.2 is released and in Debian repository.

And maybe it may take some time...  :-X

Fre;D

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: dbannon on October 29, 2021, 09:57:52 am

While noting that in another thread, Fred has raised and seen that this problem is fixed in FPC3.2.3, I'd like to just add one more postscript -

In my application, using FPC3.2.0, hardening does work on a debian platform but not an Ubuntu one ! I have not drilled down more than that, I suspect there may be differences between repo sourced packages and DIY ones but I am rapidly loosing interest. But just in case someone stumbles across this thread and is scratching their head (or, as we say in Tasmania, their heads).

Sounds like a good reason to update to FPC3.2.4 as soon as its ready, or 3.2.3 ...

Davo

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: han on November 06, 2021, 11:38:56 am

I have tried the compiler options  "-Cg  -k-pie -k-znow"  but it creates a  shared library rather then an executable. Does anybody know how to avoid that?

I have installed the latest trunk using Fpcupdeluxe but it also happens with Lazurus 2.0.12

Han

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on November 06, 2021, 03:07:28 pm

Quote from: han on November 06, 2021, 11:38:56 am

I have tried the compiler options  "-Cg  -k-pie -k-znow"  but it creates a  shared library rather then an executable. Does anybody know how to avoid that?

I have installed the latest trunk using Fpcupdeluxe but it also happens with Lazurus 2.0.12

Han

Hello.

No, it is not a shared library but a PIE executable that you can run only via a terminal or a symlink.
It will not run if you 2X click on the executable, just use a terminal with something like:

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

1. $ /path_of_your_pie/yourpieexecutable

You may check your executable with this:

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

1. $ file /path_of_your_pie/yourpieexecutable

Result:

Quote

  /path_of_your_pie/yourpieexecutablet: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, stripped

If there is a " pie" in the result, then ... it is a PIE executable.

Fre;D

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: han on November 07, 2021, 09:45:51 pm

Thanks for the info. Yes it is executable from the command  line.  :)

What is the reason to prevent execution by a file explorer? Security?


In Ubuntu I get this for file ./executable:
   ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, stripped

In Debian:
  ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, stripped

The explorer of Debian LXQt is also calling it a shared library. That doesn't help.


Han

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: Fred vS on November 07, 2021, 10:15:57 pm

Quote from: han on November 07, 2021, 09:45:51 pm

What is the reason to prevent execution by a file explorer? Security?

Yes, it is one of the reason.
You may take a look here, chapter Position-independent executables
https://en.wikipedia.org/wiki/Position-independent_code

Quote from: han on November 07, 2021, 09:45:51 pm

In Ubuntu I get this for file ./executable:
   ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, stripped
In Debian:
  ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, stripped

That is VERY strange, are you sure it is the same file?

Quote from: han on November 07, 2021, 09:45:51 pm

The explorer of Debian LXQt is also calling it a shared library.

Yes, I know, I find it strange too.
If you take a look into /usr/sbin/ directory, all the executables are called "Shared Library".
In fact they are PIE executables, not libraries (or maybe a PIE executable is called shared library by the purists).
See picture of my /usr/sbin/

Fre;D

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: PascalDragon on November 07, 2021, 10:30:04 pm

Quote from: Fred vS on November 07, 2021, 10:15:57 pm

Quote from: han on November 07, 2021, 09:45:51 pm

In Ubuntu I get this for file ./executable:
   ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, stripped
In Debian:
  ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, stripped

That is VERY strange, are you sure it is the same file?

Quote from: han on November 07, 2021, 09:45:51 pm

The explorer of Debian LXQt is also calling it a shared library.

Yes, I know, I find it strange too.
If you take a look into /usr/sbin/ directory, all the executables are called "Shared Library".
In fact they are PIE executables, not libraries (or maybe a PIE executable is called shared library by the purists).
See picture of my /usr/sbin/

Please note that for ELF binaries (e.g. Linux and the BSDs) Position Independant Executables are in fact shared libraries on the binary level. The dynamic linker does the necessary “magic” to turn the library into an executable upon launch.

Title: Re: [Solved] Fix hardening-no-pie with fpc > 3.0.4
Post by: dbannon on November 08, 2021, 12:19:55 am

I noted a few posts back that Ubuntu behaves differently from Debian, I suspected it was the binutils.  Using same recipe exactly, Ubuntu 20.40 does not make a PIE. But, as a seeming separate thing, Ubuntu does not report PIE using the file command, even on a binary that we know is PIE (made on Debian).

I test against Bullseye which is a newer release than U20.04, perhaps the newer ubuntu is more cooperative ?

Davo