Mailing List Archive

You made me curious, so I took a look at on this.

The eclass has a single function stating: "Set up CFLAGS for a debug
build" in its description. Although it is not conditional for debug
builds, so gets applied all the time, being called from the eclass'
src_configure function. The filter flags statements are conditional and
applied only in case of a static-libs build.
Appending lazy binding is also conditional for Xorg and drivers.

According to the Hardened/Toolchains wiki, one can find this section:
"The following packages have issues with BIND_NOW at the time of writing,
and it has to be relaxed somewhat for them:
X - some drivers consist of several libraries which are co-dependent,
and the modules frequently have references to modules that they load.
transcode - relies on lazy binding to be able to load its modules; the
issues are similar to the X issues."

The function does not check whether the build happens on a hardened system
or not.

If you are using a hardened toolchain, relro and now is specified by
default. I guess lazy takes precedence if present. Unless it would have no
effect. I'm not sure what you mean by adding relro and now to the filters.
Since these would be applied anyways by gcc specs. I'm also not sure what
happens if both lazy and relro+now are appended at the same time.

If I would try to test Xorg and its drivers with relro+now, I would
comment out the append lazy line. I can give that a try if it is
reasonable, but the statement in the wiki seems pretty clear. I don't know
when those experiences described came from.

Regards:
Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2013.Szeptember 30.(H) 14:41 időpontban Hinnerk van Bruinehsen ezt írta:
> Hi,
>
> If one builds Xorg it's build with only partial RELRO enabled (test e.g.
> with
> checksec.sh).
> This is caused by the xorg-2.eclass and affects seemingly all packages
> that use
> that eclass (It has a conditional that checks if hardened is used and
> filters
> some flags).
> Does anyone know why this is the case? Is it a legacy issue or are there
> valid
> reasons why Xorg is build with only partial RELRO?
> I've tried to build it on my systems with full RELRO (by adding
> -z,relro,-z,now
> to the filter inside the eclass) and it works without issues so far.
>
> WKR
> Hinnerk
>

On Tue, Oct 01, 2013 at 11:59:33AM +0200, "Tóth Attila" wrote:
> You made me curious, so I took a look at on this.
>
> The eclass has a single function stating: "Set up CFLAGS for a debug
> build" in its description. Although it is not conditional for debug
> builds, so gets applied all the time, being called from the eclass'
> src_configure function. The filter flags statements are conditional and
> applied only in case of a static-libs build.
> Appending lazy binding is also conditional for Xorg and drivers.
>
> According to the Hardened/Toolchains wiki, one can find this section:
> "The following packages have issues with BIND_NOW at the time of writing,
> and it has to be relaxed somewhat for them:
> X - some drivers consist of several libraries which are co-dependent,
> and the modules frequently have references to modules that they load.
> transcode - relies on lazy binding to be able to load its modules; the
> issues are similar to the X issues."
>
> The function does not check whether the build happens on a hardened system
> or not.
>
> If you are using a hardened toolchain, relro and now is specified by
> default. I guess lazy takes precedence if present. Unless it would have no
> effect. I'm not sure what you mean by adding relro and now to the filters.
> Since these would be applied anyways by gcc specs. I'm also not sure what
> happens if both lazy and relro+now are appended at the same time.
>
> If I would try to test Xorg and its drivers with relro+now, I would
> comment out the append lazy line. I can give that a try if it is
> reasonable, but the statement in the wiki seems pretty clear. I don't know
> when those experiences described came from.
>
I've got an answer from Zorry via irc yesterday:
It seems like full RELRO used to break some graphics drivers. There seems to be
no real recent testing though.
From my experience I can tell that intel seems to work fine for me (Zorry
explicitely stated that radeon tend to break).
I've had no time to create a hardened environment on my only nvidia machine to
test nouveau and nvidia (the proprietary one).
Since I have no radeon I've got no chance to test that at all (the failure
happens on loading the driver, not build time sadly).

Bug #339984 is a relatively old tracker bug that doesn't reflect the current
state.

WKR
Hinnerk

Hi!

On Tue, Oct 01, 2013 at 04:35:29PM +0200, Hinnerk van Bruinehsen wrote:
> I've had no time to create a hardened environment on my only nvidia machine to
> test nouveau and nvidia (the proprietary one).

I can test proprietary nvidia if someone provide me with modified ebuild
or patch or instructions what's to do.

--
WBR, Alex.

I have two systems using the radeon driver and I'm getting really curious.
I have to see it for myself how it fails to load with full relro. At least
on my laptop. There have been improvements regarding Xorg during the last
few years. It's no longer necessary to switch of some PaX options for
Xorg. So there might be some improvements regarding relro+now as well. I
don't know if the advent of the golden linker made its mark regarding the
way Xorg gets linked.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2013.Október 1.(K) 16:35 időpontban Hinnerk van Bruinehsen ezt írta:
> On Tue, Oct 01, 2013 at 11:59:33AM +0200, "Tóth Attila" wrote:
>> You made me curious, so I took a look at on this.
>>
>> The eclass has a single function stating: "Set up CFLAGS for a debug
>> build" in its description. Although it is not conditional for debug
>> builds, so gets applied all the time, being called from the eclass'
>> src_configure function. The filter flags statements are conditional and
>> applied only in case of a static-libs build.
>> Appending lazy binding is also conditional for Xorg and drivers.
>>
>> According to the Hardened/Toolchains wiki, one can find this section:
>> "The following packages have issues with BIND_NOW at the time of
>> writing,
>> and it has to be relaxed somewhat for them:
>> X - some drivers consist of several libraries which are
>> co-dependent,
>> and the modules frequently have references to modules that they load.
>> transcode - relies on lazy binding to be able to load its modules;
>> the
>> issues are similar to the X issues."
>>
>> The function does not check whether the build happens on a hardened
>> system
>> or not.
>>
>> If you are using a hardened toolchain, relro and now is specified by
>> default. I guess lazy takes precedence if present. Unless it would have
>> no
>> effect. I'm not sure what you mean by adding relro and now to the
>> filters.
>> Since these would be applied anyways by gcc specs. I'm also not sure
>> what
>> happens if both lazy and relro+now are appended at the same time.
>>
>> If I would try to test Xorg and its drivers with relro+now, I would
>> comment out the append lazy line. I can give that a try if it is
>> reasonable, but the statement in the wiki seems pretty clear. I don't
>> know
>> when those experiences described came from.
>>
> I've got an answer from Zorry via irc yesterday:
> It seems like full RELRO used to break some graphics drivers. There seems
> to be
> no real recent testing though.
> From my experience I can tell that intel seems to work fine for me (Zorry
> explicitely stated that radeon tend to break).
> I've had no time to create a hardened environment on my only nvidia
> machine to
> test nouveau and nvidia (the proprietary one).
> Since I have no radeon I've got no chance to test that at all (the failure
> happens on loading the driver, not build time sadly).
>
> Bug #339984 is a relatively old tracker bug that doesn't reflect the
> current
> state.
>
> WKR
> Hinnerk
>

On Tue, Oct 01, 2013 at 06:54:10PM +0300, Alex Efros wrote:
> Hi!
>
> On Tue, Oct 01, 2013 at 04:35:29PM +0200, Hinnerk van Bruinehsen wrote:
> > I've had no time to create a hardened environment on my only nvidia machine to
> > test nouveau and nvidia (the proprietary one).
>
> I can test proprietary nvidia if someone provide me with modified ebuild
> or patch or instructions what's to do.
>
> --
> WBR, Alex.


If you want to try, you could try the xorg-2.eclass from here:

https://github.com/N8Fear/hvb-overlay/blob/master/eclass/xorg-2.eclass

either by temporarily overwriting the one from the portage tree or otherwise by
putting it into a custom overlay (for this to work you'd need to copy
xorg-server to the overlay and likely other packages that inherit from the
eclass, too).
You could also google for eclass overriding.

WKR
Hinnerk

Hi!

On Tue, Oct 01, 2013 at 09:21:00PM +0200, Hinnerk van Bruinehsen wrote:
> If you want to try, you could try the xorg-2.eclass from here:
>
> https://github.com/N8Fear/hvb-overlay/blob/master/eclass/xorg-2.eclass
>
> either by temporarily overwriting the one from the portage tree or otherwise by

Overwriting one from the portage is ok, I think. What next - rebuild
x11-base/xorg-server-1.14.3 and restart Xorg to check is it works ok?

--
WBR, Alex.

Do we really have to explicitly append relro+now ldflags, in case of the
hardened toolchain? Aren't these in effect by default? Isn't it enough
just to comment out the append lazy line, instead of modifying it?

Shouldn't we also recompile the video driver as well for the test?

How can I properly check that the binary has proper relro+now and not just
lazy?

Thx: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2013.Október 1.(K) 21:34 időpontban Alex Efros ezt írta:
> Hi!
>
> On Tue, Oct 01, 2013 at 09:21:00PM +0200, Hinnerk van Bruinehsen wrote:
>> If you want to try, you could try the xorg-2.eclass from here:
>>
>> https://github.com/N8Fear/hvb-overlay/blob/master/eclass/xorg-2.eclass
>>
>> either by temporarily overwriting the one from the portage tree or
>> otherwise by
>
> Overwriting one from the portage is ok, I think. What next - rebuild
> x11-base/xorg-server-1.14.3 and restart Xorg to check is it works ok?
>
> --
> WBR, Alex.
>

On Tue, Oct 01, 2013 at 10:34:07PM +0300, Alex Efros wrote:
> Hi!
>
> On Tue, Oct 01, 2013 at 09:21:00PM +0200, Hinnerk van Bruinehsen wrote:
> > If you want to try, you could try the xorg-2.eclass from here:
> >
> > https://github.com/N8Fear/hvb-overlay/blob/master/eclass/xorg-2.eclass
> >
> > either by temporarily overwriting the one from the portage tree or otherwise by
>
> Overwriting one from the portage is ok, I think. What next - rebuild
> x11-base/xorg-server-1.14.3 and restart Xorg to check is it works ok?
>
> --
> WBR, Alex.

That should do it - and on the next sync everything should be back to normal.
Btw: seems like building the driver (xf86-video-intel in my case) seems to
break X (no screens found).
I think it still would be an improvement nonetheless if xorg-server could be
build with full relro.
The question is if it's the same for other drivers (building the drivers break
X, building the server itself with full relro works).

One other more or less losely related thing: x86-input-synaptics works with
full relro for me.

Hi!

On Tue, Oct 01, 2013 at 09:21:00PM +0200, Hinnerk van Bruinehsen wrote:
> > I can test proprietary nvidia if someone provide me with modified ebuild
> > or patch or instructions what's to do.
> If you want to try, you could try the xorg-2.eclass from here:

I've tried both rebuilding only xorg-server first, restart X, then
rebuilde all x11-drivers/* packages and reboot (to reload kernel
module) - in both cases everything works fine with proprietary nvidia.

I've also tried nouveau and nv drivers, but got "Failed to load …
undefined symbol: …" errors (with different symbols for each driver).
Maybe this happens because some other libs should be recompiled, or
because of already loaded nvidia kernel module.

--
WBR, Alex.

So how it can be verified, that the compiled ELF has RELRO and NOW?
1. RELRO can be verified by calling readelf with the -l option and look
for RELRO. If it's there, the ELF was compiled with RELRO
2. NOW can be verified by calling readelf with the -d option and look for
BIND_NOW
If the ELF has both, it's full RELRO. If it has only RELRO, but no
BIND_NOW, it's lazy.

If I comment out the append flag row in the xorg eclass, the resulting ELF
will be full relro. Without explicitly specifying relro and now. That's
probably because of the hardened toolchain.

I will give a try to the radeon driver soon. Now it's only Xorg and most
of the drivers compiled with full relro, except for the video card driver.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2013.Október 1.(K) 22:26 időpontban Hinnerk van Bruinehsen ezt írta:
> On Tue, Oct 01, 2013 at 10:34:07PM +0300, Alex Efros wrote:
>> Hi!
>>
>> On Tue, Oct 01, 2013 at 09:21:00PM +0200, Hinnerk van Bruinehsen wrote:
>> > If you want to try, you could try the xorg-2.eclass from here:
>> >
>> > https://github.com/N8Fear/hvb-overlay/blob/master/eclass/xorg-2.eclass
>> >
>> > either by temporarily overwriting the one from the portage tree or
>> otherwise by
>>
>> Overwriting one from the portage is ok, I think. What next - rebuild
>> x11-base/xorg-server-1.14.3 and restart Xorg to check is it works ok?
>>
>> --
>> WBR, Alex.
>
> That should do it - and on the next sync everything should be back to
> normal.
> Btw: seems like building the driver (xf86-video-intel in my case) seems to
> break X (no screens found).
> I think it still would be an improvement nonetheless if xorg-server could
> be
> build with full relro.
> The question is if it's the same for other drivers (building the drivers
> break
> X, building the server itself with full relro works).
>
> One other more or less losely related thing: x86-input-synaptics works
> with
> full relro for me.
>
>

onsdag 02 oktober 2013 20.41.32 skrev Alex Efros:
> Hi!
>
> On Tue, Oct 01, 2013 at 09:21:00PM +0200, Hinnerk van Bruinehsen wrote:
> > > I can test proprietary nvidia if someone provide me with modified ebuild
> > > or patch or instructions what's to do.
> >
> > If you want to try, you could try the xorg-2.eclass from here:
> I've tried both rebuilding only xorg-server first, restart X, then
> rebuilde all x11-drivers/* packages and reboot (to reload kernel
> module) - in both cases everything works fine with proprietary nvidia.
>
> I've also tried nouveau and nv drivers, but got "Failed to load …
> undefined symbol: …" errors (with different symbols for each driver).
> Maybe this happens because some other libs should be recompiled, or
> because of already loaded nvidia kernel module.

When i tred nouveau and the radeaon driver i needed to define the load order of
the drivers modules else i did get undefined symbols. On radeon i could not
even load some of the needed modules. But all this was some long time ago.
/Magnus

2013.Október 2.(Sze) 21:07 időpontban Magnus Granberg ezt írta:
> onsdag 02 oktober 2013 20.41.32 skrev Alex Efros:
>> Hi!
>>
>> On Tue, Oct 01, 2013 at 09:21:00PM +0200, Hinnerk van Bruinehsen wrote:
>> > > I can test proprietary nvidia if someone provide me with modified
>> ebuild
>> > > or patch or instructions what's to do.
>> >
>> > If you want to try, you could try the xorg-2.eclass from here:
>> I've tried both rebuilding only xorg-server first, restart X, then
>> rebuilde all x11-drivers/* packages and reboot (to reload kernel
>> module) - in both cases everything works fine with proprietary nvidia.
>>
>> I've also tried nouveau and nv drivers, but got "Failed to load …
>> undefined symbol: …" errors (with different symbols for each driver).
>> Maybe this happens because some other libs should be recompiled, or
>> because of already loaded nvidia kernel module.
>
> When i tred nouveau and the radeaon driver i needed to define the load
> order of
> the drivers modules else i did get undefined symbols. On radeon i could
> not
> even load some of the needed modules. But all this was some long time ago.
> /Magnus
>
Aha!

As a last step I also compiled radeon with full relro. And Xorg fails to
load.
The error message says:
Failed to load /usr/lib64/xorg/modules/drivers/radeon_drv.so:
/usr/lib64/xorg/modules/drivers/radeon_drv.so: undefined symbol:
exaWaitSync

So radeon still needs lazy. But Xorg and other drivers are RELRO now.
I have to say the first load of X takes a bit longer than usuall - makes
sense because of the BIND_NOW...

How I can define the load order of the modules?
I may play around with it. A bit more false sense of security! :-)

Thx: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

Ð’ Wed, 2 Oct 2013 22:58:35 +0200
"Tóth Attila" <atoth@atoth.sote.hu> пишет:

> 2013.Október 2.(Sze) 21:07 időpontban Magnus Granberg ezt írta:
> > onsdag 02 oktober 2013 20.41.32 skrev Alex Efros:
> >> Hi!
> >>
> >> On Tue, Oct 01, 2013 at 09:21:00PM +0200, Hinnerk van Bruinehsen wrote:
> >> > > I can test proprietary nvidia if someone provide me with modified
> >> ebuild
> >> > > or patch or instructions what's to do.
> >> >
> >> > If you want to try, you could try the xorg-2.eclass from here:
> >> I've tried both rebuilding only xorg-server first, restart X, then
> >> rebuilde all x11-drivers/* packages and reboot (to reload kernel
> >> module) - in both cases everything works fine with proprietary nvidia.
> >>
> >> I've also tried nouveau and nv drivers, but got "Failed to load …
> >> undefined symbol: …" errors (with different symbols for each driver).
> >> Maybe this happens because some other libs should be recompiled, or
> >> because of already loaded nvidia kernel module.
> >
> > When i tred nouveau and the radeaon driver i needed to define the load
> > order of
> > the drivers modules else i did get undefined symbols. On radeon i could
> > not
> > even load some of the needed modules. But all this was some long time ago.
> > /Magnus
> >
> Aha!
>
> As a last step I also compiled radeon with full relro. And Xorg fails to
> load.
> The error message says:
> Failed to load /usr/lib64/xorg/modules/drivers/radeon_drv.so:
> /usr/lib64/xorg/modules/drivers/radeon_drv.so: undefined symbol:
> exaWaitSync
>
> So radeon still needs lazy. But Xorg and other drivers are RELRO now.
> I have to say the first load of X takes a bit longer than usuall - makes
> sense because of the BIND_NOW...
>
> How I can define the load order of the modules?
> I may play around with it. A bit more false sense of security! :-)
>
> Thx: Dw.

Same problem with glamor. See comment 1 for an example of how to
define the load order of modules.

https://bugs.gentoo.org/show_bug.cgi?id=488906

--
Alexander Tsoy

2013.Október 25.(P) 15:18 időpontban Alexander Tsoy ezt írta:
> Ð’ Wed, 2 Oct 2013 22:58:35 +0200
> "Tóth Attila" <atoth@atoth.sote.hu> пишет:
>
>> 2013.Október 2.(Sze) 21:07 időpontban Magnus Granberg ezt írta:
>> > onsdag 02 oktober 2013 20.41.32 skrev Alex Efros:
>> >> Hi!
>> >>
>> >> On Tue, Oct 01, 2013 at 09:21:00PM +0200, Hinnerk van Bruinehsen
>> wrote:
>> >> > > I can test proprietary nvidia if someone provide me with modified
>> >> ebuild
>> >> > > or patch or instructions what's to do.
>> >> >
>> >> > If you want to try, you could try the xorg-2.eclass from here:
>> >> I've tried both rebuilding only xorg-server first, restart X, then
>> >> rebuilde all x11-drivers/* packages and reboot (to reload kernel
>> >> module) - in both cases everything works fine with proprietary
>> nvidia.
>> >>
>> >> I've also tried nouveau and nv drivers, but got "Failed to load …
>> >> undefined symbol: …" errors (with different symbols for each driver).
>> >> Maybe this happens because some other libs should be recompiled, or
>> >> because of already loaded nvidia kernel module.
>> >
>> > When i tred nouveau and the radeaon driver i needed to define the load
>> > order of
>> > the drivers modules else i did get undefined symbols. On radeon i
>> could
>> > not
>> > even load some of the needed modules. But all this was some long time
>> ago.
>> > /Magnus
>> >
>> Aha!
>>
>> As a last step I also compiled radeon with full relro. And Xorg fails to
>> load.
>> The error message says:
>> Failed to load /usr/lib64/xorg/modules/drivers/radeon_drv.so:
>> /usr/lib64/xorg/modules/drivers/radeon_drv.so: undefined symbol:
>> exaWaitSync
>>
>> So radeon still needs lazy. But Xorg and other drivers are RELRO now.
>> I have to say the first load of X takes a bit longer than usuall - makes
>> sense because of the BIND_NOW...
>>
>> How I can define the load order of the modules?
>> I may play around with it. A bit more false sense of security! :-)
>>
>> Thx: Dw.
>
> Same problem with glamor. See comment 1 for an example of how to
> define the load order of modules.
>
> https://bugs.gentoo.org/show_bug.cgi?id=488906

Ahh, so this is the problem with glamor.
I've already figured out the way how to specify module loading order.
However I couldn't solve the radeon driver load problem with full relro.
My efforts weren't enough. Although I haven't considered fb module. So
I'll give it another try. And also retest glamor.

Thanks:
Dwokfur
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

Even though I explicitly specify module loading order, I still have symbol
problems upon loading full relro radeon.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2013.Október 25.(P) 15:18 időpontban Alexander Tsoy ezt írta:
> Ð’ Wed, 2 Oct 2013 22:58:35 +0200
> "Tóth Attila" <atoth@atoth.sote.hu> пишет:
>
>> 2013.Október 2.(Sze) 21:07 időpontban Magnus Granberg ezt írta:
>> > onsdag 02 oktober 2013 20.41.32 skrev Alex Efros:
>> >> Hi!
>> >>
>> >> On Tue, Oct 01, 2013 at 09:21:00PM +0200, Hinnerk van Bruinehsen
>> wrote:
>> >> > > I can test proprietary nvidia if someone provide me with modified
>> >> ebuild
>> >> > > or patch or instructions what's to do.
>> >> >
>> >> > If you want to try, you could try the xorg-2.eclass from here:
>> >> I've tried both rebuilding only xorg-server first, restart X, then
>> >> rebuilde all x11-drivers/* packages and reboot (to reload kernel
>> >> module) - in both cases everything works fine with proprietary
>> nvidia.
>> >>
>> >> I've also tried nouveau and nv drivers, but got "Failed to load …
>> >> undefined symbol: …" errors (with different symbols for each driver).
>> >> Maybe this happens because some other libs should be recompiled, or
>> >> because of already loaded nvidia kernel module.
>> >
>> > When i tred nouveau and the radeaon driver i needed to define the load
>> > order of
>> > the drivers modules else i did get undefined symbols. On radeon i
>> could
>> > not
>> > even load some of the needed modules. But all this was some long time
>> ago.
>> > /Magnus
>> >
>> Aha!
>>
>> As a last step I also compiled radeon with full relro. And Xorg fails to
>> load.
>> The error message says:
>> Failed to load /usr/lib64/xorg/modules/drivers/radeon_drv.so:
>> /usr/lib64/xorg/modules/drivers/radeon_drv.so: undefined symbol:
>> exaWaitSync
>>
>> So radeon still needs lazy. But Xorg and other drivers are RELRO now.
>> I have to say the first load of X takes a bit longer than usuall - makes
>> sense because of the BIND_NOW...
>>
>> How I can define the load order of the modules?
>> I may play around with it. A bit more false sense of security! :-)
>>
>> Thx: Dw.
>
> Same problem with glamor. See comment 1 for an example of how to
> define the load order of modules.
>
> https://bugs.gentoo.org/show_bug.cgi?id=488906
>
> --
> Alexander Tsoy
>
>