On 05/23/2018 11:31 AM, Mark Rutland wrote:
On Wed, May 23, 2018 at 04:07:37PM +0100, Mark Rutland wrote:
I think that either way, we have a potential problem if the compiler
generates a branch dependent on the result of validate_index_nospec().
In that case, we could end up with codegen appr
On Wed, May 23, 2018 at 04:07:37PM +0100, Mark Rutland wrote:
> I think that either way, we have a potential problem if the compiler
> generates a branch dependent on the result of validate_index_nospec().
>
> In that case, we could end up with codegen approximating:
>
> bool safe = false;
On Wed, May 23, 2018 at 04:07:37PM +0100, Mark Rutland wrote:
> I think that either way, we have a potential problem if the compiler
> generates a branch dependent on the result of validate_index_nospec().
>
> In that case, we could end up with codegen approximating:
>
> bool safe = false;
On Wed, May 23, 2018 at 8:07 AM, Mark Rutland wrote:
> On Wed, May 23, 2018 at 11:08:40AM +0200, Peter Zijlstra wrote:
>>
>> Sorry for being late to the party..
>
> Likewise!
>
>> On Wed, May 23, 2018 at 12:03:57AM -0500, Gustavo A. R. Silva wrote:
>> > +#define validate_index_nospec(index, size)
On Wed, May 23, 2018 at 11:08:40AM +0200, Peter Zijlstra wrote:
>
> Sorry for being late to the party..
Likewise!
> On Wed, May 23, 2018 at 12:03:57AM -0500, Gustavo A. R. Silva wrote:
> > +#define validate_index_nospec(index, size)\
> > +({
On Wed, May 23, 2018 at 2:08 AM, Peter Zijlstra wrote:
>
> Sorry for being late to the party..
>
> On Wed, May 23, 2018 at 12:03:57AM -0500, Gustavo A. R. Silva wrote:
>
>> +#define validate_index_nospec(index, size)\
>> +({
Sorry for being late to the party..
On Wed, May 23, 2018 at 12:03:57AM -0500, Gustavo A. R. Silva wrote:
> +#define validate_index_nospec(index, size)\
> +({\
> + bool ret = true;
On 05/23/2018 12:15 AM, Dan Williams wrote:
OK. How about this:
diff --git a/include/linux/nospec.h b/include/linux/nospec.h
index e791ebc..498995b 100644
--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -55,4 +55,21 @@ static inline unsigned long
array_index_mask_nospec(unsigned
On Tue, May 22, 2018 at 10:03 PM, Gustavo A. R. Silva
wrote:
>
>
> On 05/22/2018 03:50 PM, Dan Williams wrote:
Dan,
What do you think about this first draft:
diff --git a/include/linux/nospec.h b/include/linux/nospec.h
index e791ebc..6154183 100644
---
On 05/22/2018 03:50 PM, Dan Williams wrote:
Dan,
What do you think about this first draft:
diff --git a/include/linux/nospec.h b/include/linux/nospec.h
index e791ebc..6154183 100644
--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -55,4 +55,16 @@ static inline unsigned long
array
On Sun, May 20, 2018 at 7:00 PM, Gustavo A. R. Silva
wrote:
>
>
> On 05/20/2018 07:50 PM, Gustavo A. R. Silva wrote:
>>
>>
>>
>> On 05/18/2018 03:44 PM, Gustavo A. R. Silva wrote:
>
>
> #ifndef sanitize_index_nospec
> inline bool sanitize_index_nospec(unsigned long *index,
>
On 05/20/2018 07:50 PM, Gustavo A. R. Silva wrote:
On 05/18/2018 03:44 PM, Gustavo A. R. Silva wrote:
#ifndef sanitize_index_nospec
inline bool sanitize_index_nospec(unsigned long *index,
unsigned long size)
{
if (*index >= size)
On 05/18/2018 03:44 PM, Gustavo A. R. Silva wrote:
#ifndef sanitize_index_nospec
inline bool sanitize_index_nospec(unsigned long *index,
unsigned long size)
{
if (*index >= size)
return false;
*index = array_index_nospec(*in
On 05/18/2018 05:08 PM, Dan Williams wrote:
Oh I see now. Just to double check, then something like the following would
be broken too, because is basically the same as the code above, and well, it
doesn't make much sense to store the value returned by macro
array_index_nospec into x, correct?:
On Fri, May 18, 2018 at 3:01 PM, Gustavo A. R. Silva
wrote:
>
>
> On 05/18/2018 04:45 PM, Dan Williams wrote:
>>
>> On Fri, May 18, 2018 at 2:27 PM, Gustavo A. R. Silva
>> wrote:
>>>
>>>
>>>
>>> On 05/18/2018 03:44 PM, Gustavo A. R. Silva wrote:
>>>
>>>
>>>
>>
>> Oops, it seem
On 05/18/2018 04:45 PM, Dan Williams wrote:
On Fri, May 18, 2018 at 2:27 PM, Gustavo A. R. Silva
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
On Fri, May 18, 2018 at 2:27 PM, Gustavo A. R. Silva
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(u
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 >
On 05/18/2018 03:38 PM, Dan Williams wrote:
On Fri, May 18, 2018 at 12:21 PM, Gustavo A. R. Silva
wrote:
On 05/18/2018 02:04 PM, Gustavo A. R. Silva wrote:
On 05/15/2018 05:57 PM, Dan Williams wrote:
On Tue, May 15, 2018 at 3:29 PM, Thomas Gleixner
wrote:
On Tue, 15 May 2018, Andre
On Fri, May 18, 2018 at 12:21 PM, Gustavo A. R. Silva
wrote:
>
>
> On 05/18/2018 02:04 PM, Gustavo A. R. Silva wrote:
>>
>>
>>
>> On 05/15/2018 05:57 PM, Dan Williams wrote:
>>>
>>> On Tue, May 15, 2018 at 3:29 PM, Thomas Gleixner
>>> wrote:
On Tue, 15 May 2018, Andrew Morton wrote:
>>>
On 05/18/2018 02:04 PM, Gustavo A. R. Silva wrote:
On 05/15/2018 05:57 PM, Dan Williams wrote:
On Tue, May 15, 2018 at 3:29 PM, Thomas Gleixner
wrote:
On Tue, 15 May 2018, Andrew Morton wrote:
On Mon, 14 May 2018 22:00:38 -0500 "Gustavo A. R. Silva"
wrote:
resource can be controlled b
On 05/15/2018 05:57 PM, Dan Williams wrote:
On Tue, May 15, 2018 at 3:29 PM, Thomas Gleixner wrote:
On Tue, 15 May 2018, Andrew Morton wrote:
On Mon, 14 May 2018 22:00:38 -0500 "Gustavo A. R. Silva"
wrote:
resource can be controlled by user-space, hence leading to a
potential exploitatio
On Tue, May 15, 2018 at 3:29 PM, Thomas Gleixner wrote:
> On Tue, 15 May 2018, Andrew Morton wrote:
>> On Mon, 14 May 2018 22:00:38 -0500 "Gustavo A. R. Silva"
>> wrote:
>>
>> > resource can be controlled by user-space, hence leading to a
>> > potential exploitation of the Spectre variant 1 vuln
On Tue, 15 May 2018, Andrew Morton wrote:
> On Mon, 14 May 2018 22:00:38 -0500 "Gustavo A. R. Silva"
> wrote:
>
> > resource can be controlled by user-space, hence leading to a
> > potential exploitation of the Spectre variant 1 vulnerability.
> >
> > This issue was detected with the help of Sm
On Mon, 14 May 2018 22:00:38 -0500 "Gustavo A. R. Silva"
wrote:
> resource can be controlled by user-space, hence leading to a
> potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> kernel/sys.c:1474 __do_compat_sys_old_getrlim
resource can be controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
kernel/sys.c:1474 __do_compat_sys_old_getrlimit() warn: potential
spectre issue 'get_current()->signal->rlim' (local cap)
ke
26 matches
Mail list logo
