Re: Enabling PIE by default for Stretch

[Bálint Réczey]

Hi Maximiliano,

2016-10-10 14:21 GMT+02:00 Maximiliano Curia :
> ¡Hola Niels!
>
> El 2016-10-10 a las 05:44 +, Niels Thykier escribió:
>>
>> Niels Thykier:
>>>
>>> As brought up on the meeting last night, I think we should try to go for
>>> PIE by default in Stretch on all release architectures!  * It is a
>>> substantial hardening feature  * Upstream has vastly reduced the performance
>>> penalty for x86  * The majority of all porters believe their release
>>> architecture isready for it.  * We have sufficient time to solve any
>>> issues or revert if it turns outto be too problematic.
>
>
>>> [...]
>
>
>>>  * Deadline for major concerns:  Fri, 7th of October 2016.
>
>
>> It appears that there were no major concerns.  I will follow up #835148
>> and request PIE by default for the following architectures.
>
>
>> * amd64 * arm64 * armel * armhf * i386 * mips * mips64el * mipsel *
>> ppc64el * s390x
>
>
> Such a change will produce unneeded FTBFS's in libraries using -fPIC (such
> as qt5 and all it's dependencies).
>
> Afaik, -fPIC is stronger than -fPIE, at the same time, -fPIE is incompatible
> with -fPIC and -fPIE makes little sense in shared libraries.
>
> And while a single patch should be trivial, I fear they would be many
> specific ones.

Have you seen the results of the test-rebuild performed with the
changed defaults?

I have put together a page with related links and information where
you can find the rebuild results, too:

 https://wiki.debian.org/Hardening/PIEByDefaultTransition

Cheers,
Balint

Re: Any armhf/armel Kodi users?

[Bálint Réczey]

Hi,

2016-10-07 2:08 GMT+02:00 [ftp83plus] :
> Hello,
>
> I have a Qnap TS109II, armel architecture. It has no HDMI port, but do you 
> think it would be possible to test it there?

I think it would be possible, but would be interested in seeing if HW accel
is working on armhf/armel, thus redirected X does not help here.

Cheers,
Balint

>
> Pat
>
> El 2016-10-06, a las 11:39, Wookey escribió:
>
>> On 2016-10-06 16:13 +0200, Balint Reczey wrote:
>>> Hi,
>>>
>>> I'm wondering if there is anyone using the armhf/armel kodi packages on
>>> Debian testing/unstable.
>>
>> I have a plan to, (on a cubietruck) but I don't actually use them at the 
>> moment.
>>
>>> The last update broke the build for armhf/armel in experimental and I'm
>>> about to fix it but report from someone actually using the built
>>> packages would be nice.
>>>
>>> I have no HW for testing the builds apart from amd64 VMs.
>>
>> I guess I could try and test it if no-one else with a working set-up 
>> volunteers.
>>
>>> PS: Please CC me, I'm not on the list.
>>
>>
>>
>> Wookey
>> --
>> Principal hats:  Linaro, Debian, Wookware, ARM
>> http://wookware.org/
>

Re: Porter roll call for Debian Stretch

[Bálint Réczey]

Hi,

2016-08-21 8:22 GMT+02:00 Niels Thykier :
> Kurt Roeckx:
>> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>>also apply to this port? [0]
>>
>> If -fPIE is the default will -fPIC override it?
>>
>> It will also default to tell the linker to use -pie, but then
>> don't do it when you want to create a shared library?
>>
>
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.
>
> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).
>
> Regardless, it seems to "just work(TM)" if you pass the proper flags
> when compiling your SOs.
>
>>>From what I understand, depending on what the .o file is going to
>> be used for you want different things:
>> - shared library: -fPIC
>> - executable: -fPIC or -fPIE both work, but prefer -fPIE
>> - static library: Same as executables
>>
>> For static libraries we now have a policy to not use -fPIC,
>> should that then get replaced by using -fPIE?
>>
>>
>>
>> Kurt
>>
>
> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for all
arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.

My assumption was that this set of architectures need the least amount of
additional work since they are tested already in Ubuntu, but I would be happy
if more ports would opt in for PIE.

I plan filing wishlist bugs against dpkg and gcc with the patches
after I rebuilt a
few packages with the defaults.

Cheers,
Balint

[2] https://people.debian.org/~rbalint/ppa/pie-bindnow/


>
> Thanks,
> ~Niels
>
> [1] Example spec files for this case seems to be something like:
>
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
>
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
>
> NB: I manually carved them out of a diff without testing them.
>