This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: Are syconf(_SC_XXX) issues glibc or kernel issues?


On Wed, Mar 21, 2018 at 2:27 PM, Jason Duerstock
<jason.duerstock@gmail.com> wrote:
> That would be my interpretation.  See:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/sysconf.c;h=8b74ad6184cc724b2291c35249021a059e331fcc;hb=HEAD#l1182
>
> What value are you seeing returned?

I'm seeing 0, which is incorrect. The L1 cache line size on the POWER
System S822 is 128, not 0.

The man pages don't discuss how to interpret a 0 return value.
Shouldn't -1 be returned with a ENOENT or ENOSYS or similar error set?

_POSIX_LEVEL1_DCACHE_LINESIZE is not defined. If I am parsing the man
page correctly, then _SC_LEVEL1_DCACHE_LINESIZE is a runtime test. A
value of -1 means it is unsupported.

A lot of code is written like this, which is incorrect for the new return value:

    if ((cacheLineSize = sysconf(_SC_LEVEL1_DCACHE_LINESIZE)) < 0)
       ...

Some high integrity software, like Botan and Crypto++, use the cache
line size to coerce cache evictions to harden against some timing
attacks. Returning 0 may have really bad consequences.

Jeff


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