On Mon, Jul 24, 2017 at 10:09:32PM +1000, Michael Ellerman wrote:
> Peter Zijlstra writes:
> > anyway, and the fact that your LL/SC is horrendously slow in any case.
>
> Boo :/
:-)
> Just kidding. I suspect you're right that we can probably pack a
> reasonable amount of tests in the body of the
Peter Zijlstra writes:
> On Mon, Jul 24, 2017 at 04:38:06PM +1000, Michael Ellerman wrote:
>
>> What I'm not entirely clear on is what the best trade off is in terms of
>> overhead vs checks. The summary of behaviour between the fast and full
>> versions you promised Ingo will help there I think.
On Mon, Jul 24, 2017 at 04:38:06PM +1000, Michael Ellerman wrote:
> What I'm not entirely clear on is what the best trade off is in terms of
> overhead vs checks. The summary of behaviour between the fast and full
> versions you promised Ingo will help there I think.
That's something that's proba
Kees Cook writes:
> On Fri, Jul 21, 2017 at 2:22 PM, Andrew Morton
>>
>> Do we have a feeling for how feasible/difficult it will be for other
>> architectures to implement such a thing?
>
> The PaX atomic_t overflow protection this is heavily based on was
> ported to a number of architectures (arm
On Fri, Jul 21, 2017 at 2:22 PM, Andrew Morton
wrote:
> On Thu, 20 Jul 2017 11:11:06 +0200 Ingo Molnar wrote:
>
>>
>> * Kees Cook wrote:
>>
>> > This implements refcount_t overflow protection on x86 without a noticeable
>> > performance impact, though without the fuller checking of REFCOUNT_FULL
On Thu, 20 Jul 2017 11:11:06 +0200 Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
> > This implements refcount_t overflow protection on x86 without a noticeable
> > performance impact, though without the fuller checking of REFCOUNT_FULL.
> > This is done by duplicating the existing atomic_t refco
* Kees Cook wrote:
> On Thu, Jul 20, 2017 at 10:15 AM, Kees Cook wrote:
> > On Thu, Jul 20, 2017 at 2:11 AM, Ingo Molnar wrote:
> >> Could you please also create a tabulated quick-comparison of the three
> >> variants,
> >> of all key properties, about behavior, feature and tradeoff differenc
On Thu, Jul 20, 2017 at 10:15 AM, Kees Cook wrote:
> On Thu, Jul 20, 2017 at 2:11 AM, Ingo Molnar wrote:
>> Could you please also create a tabulated quick-comparison of the three
>> variants,
>> of all key properties, about behavior, feature and tradeoff differences?
>>
>> Something like:
>>
>>
On Thu, Jul 20, 2017 at 2:11 AM, Ingo Molnar wrote:
> Could you please also create a tabulated quick-comparison of the three
> variants,
> of all key properties, about behavior, feature and tradeoff differences?
>
> Something like:
>
> !ARCH_HAS_REFCOUNT ARCH_
* Kees Cook wrote:
> This implements refcount_t overflow protection on x86 without a noticeable
> performance impact, though without the fuller checking of REFCOUNT_FULL.
> This is done by duplicating the existing atomic_t refcount implementation
> but with normally a single instruction added to
This series implements a fast refcount overflow protection for x86, which is
needed to provide coverage for the several refcount-overflow use-after-free
flaws the kernel has seen over the last many years. For example, here are
two from 2016:
http://perception-point.io/2016/01/14/analysis-and-explo
11 matches
Mail list logo
