Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez1ojhc2reSwY_oXUPBKg3TVVhCHsvL196EBakCVRQ=hAA@mail.gmail.com>
Date: Sun, 21 Jan 2018 21:24:31 +0100
From: Jann Horn <jannh@...gle.com>
To: Russell King - ARM Linux <linux@...linux.org.uk>
Cc: Dan Williams <dan.j.williams@...el.com>, Thomas Gleixner <tglx@...utronix.de>, 
	linux-arch <linux-arch@...r.kernel.org>, 
	Kernel Hardening <kernel-hardening@...ts.openwall.com>, Peter Zijlstra <peterz@...radead.org>, 
	Catalin Marinas <catalin.marinas@....com>, "the arch/x86 maintainers" <x86@...nel.org>, 
	Will Deacon <will.deacon@....com>, Ingo Molnar <mingo@...hat.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "H. Peter Anvin" <hpa@...or.com>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, alan@...ux.intel.com
Subject: Re: Re: [PATCH v4.1 02/10] asm/nospec, array_ptr:
 sanitize speculative array de-references

On Sun, Jan 21, 2018 at 9:15 PM, Jann Horn <jannh@...gle.com> wrote:
> [whoops, resending as non-HTML mail]
>
> On Sun, Jan 21, 2018 at 11:40 AM, Russell King - ARM Linux
> <linux@...linux.org.uk> wrote:
>> On Sat, Jan 20, 2018 at 01:06:09PM -0800, Dan Williams wrote:
>>> +/*
>>> + * If idx is negative or if idx > size then bit 63 is set in the mask,
>>> + * and the value of ~(-1L) is zero. When the mask is zero, bounds check
>>> + * failed, array_ptr will return NULL.
>>
>> The more times I see this the more times I'm unhappy with this comment:
>>
>> 1. does this really mean "idx > size" or "idx >= size" ?  The code
>>    implements the latter not the former.
>
> Copying the code here for context:
> return ~(long)(idx | (sz - 1 - idx)) >> (BITS_PER_LONG - 1);
>
> That part of the condition (ignoring the overflow edgecases) is
> equivalent to "!(idx > sz - 1)", which is equivalent to "idx <= sz -
> 1", which is (ignoring overflow edgecases) equivalent to "idx < sz".
>
> Handling of edgecases:
> idx>=2^(BITS_PER_LONG-1) will cause a NULL return through the first
> part of the condition.
> Hmm... a problematic case might be "sz==0 &&
> idx==2^(BITS_PER_LONG-1)-1". The first part of the expression wouldn't
> trigger, the second part would be
> "2^(BITS_PER_LONG)-1-(2^(BITS_PER_LONG-1)-1) ==
> 2^(BITS_PER_LONG)-2^(BITS_PER_LONG-1) == 2^(BITS_PER_LONG-1)", which
> also wouldn't trigger, I think?

Er, of course 2^(BITS_PER_LONG-1) still has the high bit set.
Sorry for the noise.

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.