This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bugzilla component missing and another (minor) fuzzing-related bug report

On 2015-10-21 23:18, Florian Weimer wrote:
> On 10/21/2015 10:17 PM, Alexander Cherepanov wrote:
>> On 19.10.2015 12:07, Florian Weimer wrote:
>>> On 10/19/2015 02:50 AM, Alexander Cherepanov wrote:
>>>> gcc doesn't support objects more than half the address space in size --
>>>> . So if you are
>>>> malloc'ing >2GB on 32-bit platforms you should be concerned.
>>> This needs to be fixed in GCC.  Even if we artificially fail large
>>> allocations in malloc, there will be cases where people call mmap or
>>> shmat directly.  And at least for the latter two, there is an
>>> expectation that this works with larger-than-2-GiB mappings for 32-bit
>>> processes (to the degree that Red Hat shipped very special 32-bit
>>> kernels for a while to support this).
>> I'm all for fixing it in GCC. It gives more flexibility: you cannot
>> support huge objects in libc when your compiler doesn't support them but
>> you can choose if you want to support them in libc when you compiler
>> support them. But I guess it's not easy to fix.
>> OTOH perhaps ability to create huge objects in libc should be somehow
>> hidden by default? As evidenced by this thread:-)
> It's possible to set a virtual address space limit with ulimit.  Is this
> sufficient?

Such a limit is overly strict for this problem as it bounds the total 
size of all allocations. And it have to be default in 32-bit distros to 
be effective. Which seems doubtful given its strictness. OTOH it's easy 
to change for those who need it and I guess it could be implemented by 
distros very fast, without waiting for gcc or glibc fixes.

Alexander Cherepanov

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]