Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKXcmWpryk=-yuySapqLsV_qTff3+Q1VvM38d+UsV4Gdg@mail.gmail.com>
Date: Mon, 3 Oct 2016 15:21:10 -0700
From: Kees Cook <keescook@...omium.org>
To: Jann Horn <jann@...jh.net>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, David Windsor <dwindsor@...il.com>, 
	Hans Liljestrand <ishkamiel@...il.com>, Elena Reshetova <elena.reshetova@...el.com>
Subject: Re: [RFC PATCH 05/13] fs: identify wrapping atomic usage

On Mon, Oct 3, 2016 at 2:57 PM, Jann Horn <jann@...jh.net> wrote:
> On Mon, Oct 03, 2016 at 09:41:18AM +0300, Elena Reshetova wrote:
>> From: David Windsor <dwindsor@...il.com>
>>
>> In some cases atomic is not used for reference
>> counting and therefore should be allowed to overflow.
>> Identify such cases and make a switch to non-hardened
>> atomic version.
>
> Depending on what the overhead ends up being, it might make sense to opt
> f_count in struct file out of the protection. It is the hottest user of
> atomic_t/atomic_long_t that I know of (incremented and decremented for
> every operation on a file descriptor in a multithreaded process), it is
> 64 bits wide and it's only incremented and decremented in steps of 1.

That's certainly an option, but I'd like to see benchmarks before we
start optimizing. :) If we can retain full coverage, that'd be
preferable.

-Kees

-- 
Kees Cook
Nexus Security

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.