[gentoo-hardened] Re: [Cpufreqd-devel] Re: [gentoo-hardened] cpufreqd-1.1.1 segmentation fault with hardened

[Alexander Gabert]

aeriksson2@××××××××.org wrote:

>>>I recently hacked a bit on cpufreqd (unapplied) and discovered that
>>>adding elements to the middle of its structures resulted in data
>>>corruption. My (limited) investigations suggested that some users of
>>>the structs assume a certain layout for memcpy operations. Adding my
>>>stuff to the end of the structures fixed it for me.
>>
>>this sound like a full rebuild of cpufreqd is needed, plugins included.
>>Changing headers and not compiling also libsys_{acpi,apm,pmu} can
>>potentially lead to segfaults as they all use the same structures (eg.:
>>struc general, struct sys_info). Could this be the case?
>>
>>Please, let me know
>
>
> Well as far as memory serves, I did 'make clean ; make' or whatever
> the equivalent was at the time. It sure was somewhere in the the
> libsys drivers it bombed out, though. (They're copied in to the source
> and rebuilt in place, so the 'make clean' should fix things, right?
> Using a .so would be another thing...).
>
> Could it be something in the (use of) function pointers pax dislike?
> At any rate, the original poster did not add anything himself, so
> something's off with the buld-out-of-the-box scenario (at least on his
> paxified machine).
>
> /A
>
>
could you do me a favour and first try suggesting chpaxing or paxctling 
the binary to suppress ASLR on the running binary and maybe also 
suppress the other memory access restrictions to find out if its some or 
all of the pax features that makes it break?

This would help me solve the problem for the user before we start 
talking about what needs to be done upstream for making this program 
pax-aware and compatible somehow.

thanks,

Alex

-- 
Chaos is just a perceptional disorder of reality.

--
gentoo-hardened@g.o mailing list