Re: [PATCH] atm: zatm: Fix potential Spectre v1

2018-05-04 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Thu, 3 May 2018 13:17:12 -0500

> pool can be indirectly 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:
> 
> drivers/atm/zatm.c:1462 zatm_ioctl() warn: potential spectre issue
> 'zatm_dev->pool_info' (local cap)
> 
> Fix this by sanitizing pool before using it to index
> zatm_dev->pool_info
> 
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
> 
> [1] https://marc.info/?l=linux-kernel=152449131114778=2
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 

Applied and queued up for -stable.


Re: [PATCH] atm: zatm: Fix potential Spectre v1

2018-05-04 Thread David Miller
From: "Gustavo A. R. Silva" 
Date: Thu, 3 May 2018 13:17:12 -0500

> pool can be indirectly 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:
> 
> drivers/atm/zatm.c:1462 zatm_ioctl() warn: potential spectre issue
> 'zatm_dev->pool_info' (local cap)
> 
> Fix this by sanitizing pool before using it to index
> zatm_dev->pool_info
> 
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
> 
> [1] https://marc.info/?l=linux-kernel=152449131114778=2
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 

Applied and queued up for -stable.


Re: [PATCH] atm: zatm: Fix potential Spectre v1

2018-05-03 Thread David Miller
From: Randy Dunlap 
Date: Thu, 3 May 2018 12:09:40 -0700

> Just for (my) info:  all of these types of patches are to prevent
> what is loaded in cache when the index is out of range, right?
> Not some random pool_info[random], but pool_info[valid, i.e., 0].
> 
> Since the value of pool is already sanity checked and -EINVAL is
> returned when it's out of range.

Well, the whole point is that the cpu can speculate execution past the
range check and execute the indexed read anyways.  So even if the
value is "sanity checked" the cpu can execute ahead and load things
into the cache, just cancelling the register state updates later when
the range check is fully resolved.



Re: [PATCH] atm: zatm: Fix potential Spectre v1

2018-05-03 Thread David Miller
From: Randy Dunlap 
Date: Thu, 3 May 2018 12:09:40 -0700

> Just for (my) info:  all of these types of patches are to prevent
> what is loaded in cache when the index is out of range, right?
> Not some random pool_info[random], but pool_info[valid, i.e., 0].
> 
> Since the value of pool is already sanity checked and -EINVAL is
> returned when it's out of range.

Well, the whole point is that the cpu can speculate execution past the
range check and execute the indexed read anyways.  So even if the
value is "sanity checked" the cpu can execute ahead and load things
into the cache, just cancelling the register state updates later when
the range check is fully resolved.



Re: [PATCH] atm: zatm: Fix potential Spectre v1

2018-05-03 Thread Randy Dunlap
On 05/03/2018 11:17 AM, Gustavo A. R. Silva wrote:
> pool can be indirectly 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:
> 
> drivers/atm/zatm.c:1462 zatm_ioctl() warn: potential spectre issue
> 'zatm_dev->pool_info' (local cap)
> 
> Fix this by sanitizing pool before using it to index
> zatm_dev->pool_info
> 
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
> 
> [1] https://marc.info/?l=linux-kernel=152449131114778=2

Hi,

Just for (my) info:  all of these types of patches are to prevent
what is loaded in cache when the index is out of range, right?
Not some random pool_info[random], but pool_info[valid, i.e., 0].

Since the value of pool is already sanity checked and -EINVAL is
returned when it's out of range.

Thanks.

> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/atm/zatm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/atm/zatm.c b/drivers/atm/zatm.c
> index 1ef67db..9c9a229 100644
> --- a/drivers/atm/zatm.c
> +++ b/drivers/atm/zatm.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "uPD98401.h"
>  #include "uPD98402.h"
> @@ -1458,6 +1459,8 @@ static int zatm_ioctl(struct atm_dev *dev,unsigned int 
> cmd,void __user *arg)
>   return -EFAULT;
>   if (pool < 0 || pool > ZATM_LAST_POOL)
>   return -EINVAL;
> + pool = array_index_nospec(pool,
> +   ZATM_LAST_POOL + 1);
>   spin_lock_irqsave(_dev->lock, flags);
>   info = zatm_dev->pool_info[pool];
>   if (cmd == ZATM_GETPOOLZ) {
> 


-- 
~Randy


Re: [PATCH] atm: zatm: Fix potential Spectre v1

2018-05-03 Thread Randy Dunlap
On 05/03/2018 11:17 AM, Gustavo A. R. Silva wrote:
> pool can be indirectly 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:
> 
> drivers/atm/zatm.c:1462 zatm_ioctl() warn: potential spectre issue
> 'zatm_dev->pool_info' (local cap)
> 
> Fix this by sanitizing pool before using it to index
> zatm_dev->pool_info
> 
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
> 
> [1] https://marc.info/?l=linux-kernel=152449131114778=2

Hi,

Just for (my) info:  all of these types of patches are to prevent
what is loaded in cache when the index is out of range, right?
Not some random pool_info[random], but pool_info[valid, i.e., 0].

Since the value of pool is already sanity checked and -EINVAL is
returned when it's out of range.

Thanks.

> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/atm/zatm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/atm/zatm.c b/drivers/atm/zatm.c
> index 1ef67db..9c9a229 100644
> --- a/drivers/atm/zatm.c
> +++ b/drivers/atm/zatm.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "uPD98401.h"
>  #include "uPD98402.h"
> @@ -1458,6 +1459,8 @@ static int zatm_ioctl(struct atm_dev *dev,unsigned int 
> cmd,void __user *arg)
>   return -EFAULT;
>   if (pool < 0 || pool > ZATM_LAST_POOL)
>   return -EINVAL;
> + pool = array_index_nospec(pool,
> +   ZATM_LAST_POOL + 1);
>   spin_lock_irqsave(_dev->lock, flags);
>   info = zatm_dev->pool_info[pool];
>   if (cmd == ZATM_GETPOOLZ) {
> 


-- 
~Randy