[cfe-dev] [libc++][RFC] Implementing Directory Entry Caching for Filesystem

Aaron Ballman via cfe-dev cfe-dev at lists.llvm.org
Wed Jul 18 09:56:56 PDT 2018

On Tue, Jul 17, 2018 at 6:31 PM, Eric Fiselier <eric at efcs.ca> wrote:
> On Tue, Jul 17, 2018 at 12:43 PM Eric Fiselier <eric at efcs.ca> wrote:
>> On Tue, Jul 17, 2018 at 5:46 AM Aaron Ballman <aaron at aaronballman.com>
>> wrote:
>>> Thank you for putting this together, I greatly appreciate it!
>>> Out of curiosity, is the caching behavior something you expect you'll
>>> make configurable for users of libc++ (for instance, a macro to enable
>>> or disable caching), or are there issues preventing such an
>>> implementation? My feeling is that we're going to have the usual push
>>> and pull between security and performance where different users will
>>> have different (and equally valid) use cases in mind justifying the
>>> need for the performance provided by caching or the security red flags
>>> enhanced by not caching. We should obviously pick a good default
>>> behavior (and can argue over the definition of "good" in that
>>> context), but I think no matter what option we pick, users will want
>>> the other option to be available.
>> I hadn't thought of making it configurable, but I'm happy to do so.
>> It'll have to maintain the same ABI, so the cache will simply be unused,
>> but providing a configuration option seems feasible.
> After attempting to implement a configuration option to disable caching, I
> don't think it's possible.
> Because so much of <filesystem> lives across a library boundary, it's tricky
> to make that library
> code sensitive to a macro defined later by the user.

Crud, I was worried that might be the case. :-(

> That being said, perhaps we could file an issue to add
> `directory_entry::clear_cache()` or similar,
> so that users can explicitly make their `directory_entry` cacheless?

I'd have to think about this further, but my concern is primarily with
users who already have TOCTOU bugs that will have their attack vectors
expanded by caching. If they knew their code had a TOCTOU bug in it
and cared about that, they wouldn't need this function at all because
they'd fix their code. Based on that, I'm not certain it'd be much of
a win and could potentially lead to even worse code, like thinking
clear_cache() fixes the TOCTOU issues rather than fixing the real


More information about the cfe-dev mailing list