1 |
I have two systems using the radeon driver and I'm getting really curious. |
2 |
I have to see it for myself how it fails to load with full relro. At least |
3 |
on my laptop. There have been improvements regarding Xorg during the last |
4 |
few years. It's no longer necessary to switch of some PaX options for |
5 |
Xorg. So there might be some improvements regarding relro+now as well. I |
6 |
don't know if the advent of the golden linker made its mark regarding the |
7 |
way Xorg gets linked. |
8 |
-- |
9 |
dr Tóth Attila, Radiológus, 06-20-825-8057 |
10 |
Attila Toth MD, Radiologist, +36-20-825-8057 |
11 |
|
12 |
2013.Október 1.(K) 16:35 időpontban Hinnerk van Bruinehsen ezt írta: |
13 |
> On Tue, Oct 01, 2013 at 11:59:33AM +0200, "Tóth Attila" wrote: |
14 |
>> You made me curious, so I took a look at on this. |
15 |
>> |
16 |
>> The eclass has a single function stating: "Set up CFLAGS for a debug |
17 |
>> build" in its description. Although it is not conditional for debug |
18 |
>> builds, so gets applied all the time, being called from the eclass' |
19 |
>> src_configure function. The filter flags statements are conditional and |
20 |
>> applied only in case of a static-libs build. |
21 |
>> Appending lazy binding is also conditional for Xorg and drivers. |
22 |
>> |
23 |
>> According to the Hardened/Toolchains wiki, one can find this section: |
24 |
>> "The following packages have issues with BIND_NOW at the time of |
25 |
>> writing, |
26 |
>> and it has to be relaxed somewhat for them: |
27 |
>> X - some drivers consist of several libraries which are |
28 |
>> co-dependent, |
29 |
>> and the modules frequently have references to modules that they load. |
30 |
>> transcode - relies on lazy binding to be able to load its modules; |
31 |
>> the |
32 |
>> issues are similar to the X issues." |
33 |
>> |
34 |
>> The function does not check whether the build happens on a hardened |
35 |
>> system |
36 |
>> or not. |
37 |
>> |
38 |
>> If you are using a hardened toolchain, relro and now is specified by |
39 |
>> default. I guess lazy takes precedence if present. Unless it would have |
40 |
>> no |
41 |
>> effect. I'm not sure what you mean by adding relro and now to the |
42 |
>> filters. |
43 |
>> Since these would be applied anyways by gcc specs. I'm also not sure |
44 |
>> what |
45 |
>> happens if both lazy and relro+now are appended at the same time. |
46 |
>> |
47 |
>> If I would try to test Xorg and its drivers with relro+now, I would |
48 |
>> comment out the append lazy line. I can give that a try if it is |
49 |
>> reasonable, but the statement in the wiki seems pretty clear. I don't |
50 |
>> know |
51 |
>> when those experiences described came from. |
52 |
>> |
53 |
> I've got an answer from Zorry via irc yesterday: |
54 |
> It seems like full RELRO used to break some graphics drivers. There seems |
55 |
> to be |
56 |
> no real recent testing though. |
57 |
> From my experience I can tell that intel seems to work fine for me (Zorry |
58 |
> explicitely stated that radeon tend to break). |
59 |
> I've had no time to create a hardened environment on my only nvidia |
60 |
> machine to |
61 |
> test nouveau and nvidia (the proprietary one). |
62 |
> Since I have no radeon I've got no chance to test that at all (the failure |
63 |
> happens on loading the driver, not build time sadly). |
64 |
> |
65 |
> Bug #339984 is a relatively old tracker bug that doesn't reflect the |
66 |
> current |
67 |
> state. |
68 |
> |
69 |
> WKR |
70 |
> Hinnerk |
71 |
> |