Hi!
If I run an application which uses a library developed with FPC on a x86 plattform, the program gets killed by SELinux because of text relocations inside of the library.
A quick check which eu-findtextrels found a lot of those in the lib. Exactly the same code compiled for 64bit does not contain any text relocation.
How can this happen? (And should I file a bug report for it?) Regards
Matthias Klumpp

Matthias Klumpp wrote

A quick check which eu-findtextrels found a lot of those in the lib. Exactly the same code compiled for 64bit does not contain any text relocation. How can this happen?

It's because we don't generate PIC (position-independent code) by default on Linux-i386, because
a) PIC is fairly inefficient on i386 (it requires an extra register, and the i386 is already register-starved as it is -- on average, it results in a 10% performance degradation)
b) very few people use SELinux, and on non-SELinux systems dynamic libraries without PIC work fine (with a small memory usage penalty, because the code cannot be shared amongst multiple processes)

On x86-64, there is almost no penalty for PIC vs no PIC.

You have to recompile the entire RTL and your own code with the -Cg compiler option to get shared libraries that only contain PIC.

Jonas

According to SELinux, this is a security issue..

On x86-64, there is almost no penalty for PIC vs no PIC. You have to recompile the entire RTL and your own code with the -Cg compiler option to get shared libraries that only contain PIC.

Then it's up to red Hat to fix this in FPC or in SELinux.

Thanks!

In our previous episode, Matthias Klumpp said:

> On x86-64, there is almost no penalty for PIC vs no PIC. > You have to recompile the entire RTL and your own code with the -Cg > compiler option to get shared libraries that only contain PIC. Then it's up to red Hat to fix this in FPC or in SELinux.

Is it Fedora or RHEL ? IIRC Fedora doesn't install selinux in enforcing mode, but monitoring only?

I guess that it may prevent some address space randomization features. I very much doubt that it opens up security holes by itself though.

Jonas

> According to SELinux, this is a security issue.. I guess that it may prevent some address space randomization features. I very much doubt that it opens up security holes by itself though.

The .so should be still relocatable? The point about pic is that one page can be mapped on different virtual addresses in different processes, i.e. the page can be reused.

Florian Klaempfl wrote

>> According to SELinux, this is a security issue.. > I guess that it may prevent some address space randomization features. I very much doubt that it opens up security holes by itself though. The .so should be still relocatable? The point about pic is that one page can be mapped on different virtual addresses in different processes, i.e. the page can be reused.

You're right. Apparently, the reason is that the memory pages containing the code of the library cannot be marked as "read-only" by the kernel (because the dynamic linker still has to write to them, to fix up the relocations). But afaik the dynamic linker itself could still do it once it's finished with the relocations, so I don't really see what the issue is (and again, this by itself does not open up security holes, it can only make exploiting existing security holes a bit easier).

Jonas

Has anybody tried to compile the new VT port which requires lclextensions (Luipack) on Mac OS with target widget Carbon? I did and wasn't succesfull. Problem is, you can't compile lclextensions. Since I am pretty new to FPC my question is, is it the right way to generate a package (like lclextensions) which implements the missing Windows functions which are used by another package (here VirtualTreeview) for all widgets or should one change the later (VT) to use FCL/LCL functions so that it does not rely on Windows functions anymore?

CA Gorski wrote

Has anybody tried to compile the new VT port which requires lclextensions (Luipack) on Mac OS with target widget Carbon?

It's a know issue. See
http://forum.lazarus.freepascal.org/index.php/topic,8601.0.html

I don't have a mac, so i need patches.

Yes.

or should one change the later (VT) to use FCL/LCL functions so that it does not rely on Windows functions anymore?

Later

BTW: use lazarus mail list

Luiz

> or should one change the later (VT) to use FCL/LCL functions so that > it does not rely on Windows functions anymore? Later

Why later and not immediately?

BTW: use lazarus mail list

How to?

It's a lot of work.

It's easier to maintain sync with Delphi version

Lazarus/LCL has added most of the needed functions, but it's not released yet.

> > BTW: use lazarus mail list How to?

http://lists.lazarus.freepascal.org/mailman/listinfo

Luiz

Lazarus/LCL has added most of the needed functions, but it's not released yet.

I am using the daily snapshot anyway. Are they in there? And if so, what is to do? Remove the dependencies on lclextensions from your port?

Yes

And if so, what is to do? Remove the dependencies on lclextensions from your port?

Yes

Luiz

> And if so, what is to do? Remove the dependencies on lclextensions > from your port? Yes

Ok, I will try...

Meantime I tried to compile lclextensions against gtk2

<SearchPaths>
<IncludeFiles Value="include/$(LCLWidgetType)/"/>
<UnitOutputDirectory Value="lib/$(TargetCPU)-$(TargetOS)-$(LCLWidgetType)"/> <LCLWidgetType Value="gtk2"/>
</SearchPaths>

but the compiler still uses includes from include/carbon sub-folder. Why?

<file:///C:/Users/quark/Desktop/Leopard.lnk>

What messages do you get when compile lclextensions for carbon?

I ask that so i can add the missing function headers

What message do you get?

The config seems OK

I think is a good idea to move to
http://lists.lazarus.freepascal.org/mailman/listinfo or private mail

Luiz