On Fri, May 18, 2018 at 2:27 PM, Gustavo A. R. Silva
<gustavo@xxxxxxxxxxxxxx> wrote:
On 05/18/2018 03:44 PM, Gustavo A. R. Silva wrote:
Oops, it seems I sent the wrong patch. The function would look like
this:
#ifndef sanitize_index_nospec
inline bool sanitize_index_nospec(unsigned long *index,
unsigned long size)
{
if (*index >= size)
return false;
*index = array_index_nospec(*index, size);
return true;
}
#endif
I think this is fine in concept, we already do something similar in
mpls_label_ok(). Perhaps call it validate_index_nospec() since
validation is something that can fail, but sanitization in theory is
something that can always succeed.
OK. I got it.
However, the problem is the data type of the index. I expect you would
need to do this in a macro and use typeof() if you wanted this to be
generally useful, and also watch out for multiple usage of a macro
argument. Is it still worth it at that point?
Yeah. I think it is worth it. I'll work on this during the weekend and
send a proper patch for review.
Thanks for the feedback.
BTW, I'm analyzing other cases, like the following:
bool foo(int x)
{
if(!validate_index_nospec(&x))
return false;
[...]
return true;
}
int vulnerable(int x)
{
if (!foo(x))
return -1;
temp = array[x];
[...]
};
Basically my doubt is how deep this barrier can be placed into the call
chain in order to continue working.
This is broken you would need to pass the address of x into foo()
otherwise there may be speculation on the return value of foo.