* [PATCH] iommu/io-pgtable-arm: Fix IOVA validation for 32-bit
@ 2020-02-28 14:18 ` Robin Murphy
0 siblings, 0 replies; 10+ messages in thread
From: Robin Murphy @ 2020-02-28 14:18 UTC (permalink / raw)
To: will, joro; +Cc: iommu, Stephan Gerhold, linux-arm-kernel
Since we ony support the TTB1 quirk for AArch64 contexts, and
consequently only for 64-bit builds, the sign-extension aspect of the
"are all bits above IAS consistent?" check should implicitly only apply
to 64-bit IOVAs. Change the type of the cast to ensure that 32-bit longs
don't inadvertently get sign-extended, and thus considered invalid, if
they happen to be above 2GB in the TTB0 region.
Reported-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
Logically there may also have been a UBSAN "shift greater than size of
type" warning too, but arch/arm doesn't support UBSAN_SANITIZE_ALL,
and that's now my only easy "spin up a 32-bit VM" option to hand :)
drivers/iommu/io-pgtable-arm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 983b08477e64..04fbd4bf0ff9 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -468,7 +468,7 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
arm_lpae_iopte *ptep = data->pgd;
int ret, lvl = data->start_level;
arm_lpae_iopte prot;
- long iaext = (long)iova >> cfg->ias;
+ long iaext = (s64)iova >> cfg->ias;
/* If no access, then nothing to do */
if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
@@ -645,7 +645,7 @@ static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
struct io_pgtable_cfg *cfg = &data->iop.cfg;
arm_lpae_iopte *ptep = data->pgd;
- long iaext = (long)iova >> cfg->ias;
+ long iaext = (s64)iova >> cfg->ias;
if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size))
return 0;
--
2.23.0.dirty
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH] iommu/io-pgtable-arm: Fix IOVA validation for 32-bit
@ 2020-02-28 14:18 ` Robin Murphy
0 siblings, 0 replies; 10+ messages in thread
From: Robin Murphy @ 2020-02-28 14:18 UTC (permalink / raw)
To: will, joro; +Cc: iommu, Stephan Gerhold, linux-arm-kernel
Since we ony support the TTB1 quirk for AArch64 contexts, and
consequently only for 64-bit builds, the sign-extension aspect of the
"are all bits above IAS consistent?" check should implicitly only apply
to 64-bit IOVAs. Change the type of the cast to ensure that 32-bit longs
don't inadvertently get sign-extended, and thus considered invalid, if
they happen to be above 2GB in the TTB0 region.
Reported-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
Logically there may also have been a UBSAN "shift greater than size of
type" warning too, but arch/arm doesn't support UBSAN_SANITIZE_ALL,
and that's now my only easy "spin up a 32-bit VM" option to hand :)
drivers/iommu/io-pgtable-arm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 983b08477e64..04fbd4bf0ff9 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -468,7 +468,7 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
arm_lpae_iopte *ptep = data->pgd;
int ret, lvl = data->start_level;
arm_lpae_iopte prot;
- long iaext = (long)iova >> cfg->ias;
+ long iaext = (s64)iova >> cfg->ias;
/* If no access, then nothing to do */
if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
@@ -645,7 +645,7 @@ static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
struct io_pgtable_cfg *cfg = &data->iop.cfg;
arm_lpae_iopte *ptep = data->pgd;
- long iaext = (long)iova >> cfg->ias;
+ long iaext = (s64)iova >> cfg->ias;
if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size))
return 0;
--
2.23.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] iommu/io-pgtable-arm: Fix IOVA validation for 32-bit
2020-02-28 14:18 ` Robin Murphy
@ 2020-03-02 11:53 ` Will Deacon
-1 siblings, 0 replies; 10+ messages in thread
From: Will Deacon @ 2020-03-02 11:53 UTC (permalink / raw)
To: Robin Murphy, joro; +Cc: iommu, Stephan Gerhold, linux-arm-kernel
On Fri, Feb 28, 2020 at 02:18:55PM +0000, Robin Murphy wrote:
> Since we ony support the TTB1 quirk for AArch64 contexts, and
> consequently only for 64-bit builds, the sign-extension aspect of the
> "are all bits above IAS consistent?" check should implicitly only apply
> to 64-bit IOVAs. Change the type of the cast to ensure that 32-bit longs
> don't inadvertently get sign-extended, and thus considered invalid, if
> they happen to be above 2GB in the TTB0 region.
>
> Reported-by: Stephan Gerhold <stephan@gerhold.net>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> ---
>
> Logically there may also have been a UBSAN "shift greater than size of
> type" warning too, but arch/arm doesn't support UBSAN_SANITIZE_ALL,
> and that's now my only easy "spin up a 32-bit VM" option to hand :)
>
> drivers/iommu/io-pgtable-arm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Will Deacon <will@kernel.org>
Joerg -- pleae can you take this as a fix for 5.6?
Thanks,
Will
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 983b08477e64..04fbd4bf0ff9 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -468,7 +468,7 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
> arm_lpae_iopte *ptep = data->pgd;
> int ret, lvl = data->start_level;
> arm_lpae_iopte prot;
> - long iaext = (long)iova >> cfg->ias;
> + long iaext = (s64)iova >> cfg->ias;
>
> /* If no access, then nothing to do */
> if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
> @@ -645,7 +645,7 @@ static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
> struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
> struct io_pgtable_cfg *cfg = &data->iop.cfg;
> arm_lpae_iopte *ptep = data->pgd;
> - long iaext = (long)iova >> cfg->ias;
> + long iaext = (s64)iova >> cfg->ias;
>
> if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size))
> return 0;
> --
> 2.23.0.dirty
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iommu/io-pgtable-arm: Fix IOVA validation for 32-bit
@ 2020-03-02 11:53 ` Will Deacon
0 siblings, 0 replies; 10+ messages in thread
From: Will Deacon @ 2020-03-02 11:53 UTC (permalink / raw)
To: Robin Murphy, joro; +Cc: iommu, Stephan Gerhold, linux-arm-kernel
On Fri, Feb 28, 2020 at 02:18:55PM +0000, Robin Murphy wrote:
> Since we ony support the TTB1 quirk for AArch64 contexts, and
> consequently only for 64-bit builds, the sign-extension aspect of the
> "are all bits above IAS consistent?" check should implicitly only apply
> to 64-bit IOVAs. Change the type of the cast to ensure that 32-bit longs
> don't inadvertently get sign-extended, and thus considered invalid, if
> they happen to be above 2GB in the TTB0 region.
>
> Reported-by: Stephan Gerhold <stephan@gerhold.net>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> ---
>
> Logically there may also have been a UBSAN "shift greater than size of
> type" warning too, but arch/arm doesn't support UBSAN_SANITIZE_ALL,
> and that's now my only easy "spin up a 32-bit VM" option to hand :)
>
> drivers/iommu/io-pgtable-arm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Will Deacon <will@kernel.org>
Joerg -- pleae can you take this as a fix for 5.6?
Thanks,
Will
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 983b08477e64..04fbd4bf0ff9 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -468,7 +468,7 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
> arm_lpae_iopte *ptep = data->pgd;
> int ret, lvl = data->start_level;
> arm_lpae_iopte prot;
> - long iaext = (long)iova >> cfg->ias;
> + long iaext = (s64)iova >> cfg->ias;
>
> /* If no access, then nothing to do */
> if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
> @@ -645,7 +645,7 @@ static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
> struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
> struct io_pgtable_cfg *cfg = &data->iop.cfg;
> arm_lpae_iopte *ptep = data->pgd;
> - long iaext = (long)iova >> cfg->ias;
> + long iaext = (s64)iova >> cfg->ias;
>
> if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size))
> return 0;
> --
> 2.23.0.dirty
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iommu/io-pgtable-arm: Fix IOVA validation for 32-bit
2020-03-02 11:53 ` Will Deacon
@ 2020-03-02 16:11 ` Joerg Roedel
-1 siblings, 0 replies; 10+ messages in thread
From: Joerg Roedel @ 2020-03-02 16:11 UTC (permalink / raw)
To: Will Deacon; +Cc: iommu, Robin Murphy, Stephan Gerhold, linux-arm-kernel
On Mon, Mar 02, 2020 at 11:53:01AM +0000, Will Deacon wrote:
> On Fri, Feb 28, 2020 at 02:18:55PM +0000, Robin Murphy wrote:
> > Since we ony support the TTB1 quirk for AArch64 contexts, and
> > consequently only for 64-bit builds, the sign-extension aspect of the
> > "are all bits above IAS consistent?" check should implicitly only apply
> > to 64-bit IOVAs. Change the type of the cast to ensure that 32-bit longs
> > don't inadvertently get sign-extended, and thus considered invalid, if
> > they happen to be above 2GB in the TTB0 region.
> >
> > Reported-by: Stephan Gerhold <stephan@gerhold.net>
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >
> > ---
> >
> > Logically there may also have been a UBSAN "shift greater than size of
> > type" warning too, but arch/arm doesn't support UBSAN_SANITIZE_ALL,
> > and that's now my only easy "spin up a 32-bit VM" option to hand :)
> >
> > drivers/iommu/io-pgtable-arm.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Acked-by: Will Deacon <will@kernel.org>
>
> Joerg -- pleae can you take this as a fix for 5.6?
Done, do you also have a fixes-tag for me?
Regards,
Joerg
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iommu/io-pgtable-arm: Fix IOVA validation for 32-bit
@ 2020-03-02 16:11 ` Joerg Roedel
0 siblings, 0 replies; 10+ messages in thread
From: Joerg Roedel @ 2020-03-02 16:11 UTC (permalink / raw)
To: Will Deacon; +Cc: iommu, Robin Murphy, Stephan Gerhold, linux-arm-kernel
On Mon, Mar 02, 2020 at 11:53:01AM +0000, Will Deacon wrote:
> On Fri, Feb 28, 2020 at 02:18:55PM +0000, Robin Murphy wrote:
> > Since we ony support the TTB1 quirk for AArch64 contexts, and
> > consequently only for 64-bit builds, the sign-extension aspect of the
> > "are all bits above IAS consistent?" check should implicitly only apply
> > to 64-bit IOVAs. Change the type of the cast to ensure that 32-bit longs
> > don't inadvertently get sign-extended, and thus considered invalid, if
> > they happen to be above 2GB in the TTB0 region.
> >
> > Reported-by: Stephan Gerhold <stephan@gerhold.net>
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >
> > ---
> >
> > Logically there may also have been a UBSAN "shift greater than size of
> > type" warning too, but arch/arm doesn't support UBSAN_SANITIZE_ALL,
> > and that's now my only easy "spin up a 32-bit VM" option to hand :)
> >
> > drivers/iommu/io-pgtable-arm.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Acked-by: Will Deacon <will@kernel.org>
>
> Joerg -- pleae can you take this as a fix for 5.6?
Done, do you also have a fixes-tag for me?
Regards,
Joerg
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iommu/io-pgtable-arm: Fix IOVA validation for 32-bit
2020-03-02 16:11 ` Joerg Roedel
@ 2020-03-02 16:14 ` Will Deacon
-1 siblings, 0 replies; 10+ messages in thread
From: Will Deacon @ 2020-03-02 16:14 UTC (permalink / raw)
To: Joerg Roedel; +Cc: iommu, Robin Murphy, Stephan Gerhold, linux-arm-kernel
On Mon, Mar 02, 2020 at 05:11:23PM +0100, Joerg Roedel wrote:
> On Mon, Mar 02, 2020 at 11:53:01AM +0000, Will Deacon wrote:
> > On Fri, Feb 28, 2020 at 02:18:55PM +0000, Robin Murphy wrote:
> > > Since we ony support the TTB1 quirk for AArch64 contexts, and
> > > consequently only for 64-bit builds, the sign-extension aspect of the
> > > "are all bits above IAS consistent?" check should implicitly only apply
> > > to 64-bit IOVAs. Change the type of the cast to ensure that 32-bit longs
> > > don't inadvertently get sign-extended, and thus considered invalid, if
> > > they happen to be above 2GB in the TTB0 region.
> > >
> > > Reported-by: Stephan Gerhold <stephan@gerhold.net>
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > >
> > > ---
> > >
> > > Logically there may also have been a UBSAN "shift greater than size of
> > > type" warning too, but arch/arm doesn't support UBSAN_SANITIZE_ALL,
> > > and that's now my only easy "spin up a 32-bit VM" option to hand :)
> > >
> > > drivers/iommu/io-pgtable-arm.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Acked-by: Will Deacon <will@kernel.org>
> >
> > Joerg -- pleae can you take this as a fix for 5.6?
>
> Done, do you also have a fixes-tag for me?
Fixes: db6903010aa5 ("iommu/io-pgtable-arm: Prepare for TTBR1 usage")
Although it doesn't need to go to -stable, since this was only introduced
during the recent merge window.
Will
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iommu/io-pgtable-arm: Fix IOVA validation for 32-bit
@ 2020-03-02 16:14 ` Will Deacon
0 siblings, 0 replies; 10+ messages in thread
From: Will Deacon @ 2020-03-02 16:14 UTC (permalink / raw)
To: Joerg Roedel; +Cc: iommu, Robin Murphy, Stephan Gerhold, linux-arm-kernel
On Mon, Mar 02, 2020 at 05:11:23PM +0100, Joerg Roedel wrote:
> On Mon, Mar 02, 2020 at 11:53:01AM +0000, Will Deacon wrote:
> > On Fri, Feb 28, 2020 at 02:18:55PM +0000, Robin Murphy wrote:
> > > Since we ony support the TTB1 quirk for AArch64 contexts, and
> > > consequently only for 64-bit builds, the sign-extension aspect of the
> > > "are all bits above IAS consistent?" check should implicitly only apply
> > > to 64-bit IOVAs. Change the type of the cast to ensure that 32-bit longs
> > > don't inadvertently get sign-extended, and thus considered invalid, if
> > > they happen to be above 2GB in the TTB0 region.
> > >
> > > Reported-by: Stephan Gerhold <stephan@gerhold.net>
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > >
> > > ---
> > >
> > > Logically there may also have been a UBSAN "shift greater than size of
> > > type" warning too, but arch/arm doesn't support UBSAN_SANITIZE_ALL,
> > > and that's now my only easy "spin up a 32-bit VM" option to hand :)
> > >
> > > drivers/iommu/io-pgtable-arm.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Acked-by: Will Deacon <will@kernel.org>
> >
> > Joerg -- pleae can you take this as a fix for 5.6?
>
> Done, do you also have a fixes-tag for me?
Fixes: db6903010aa5 ("iommu/io-pgtable-arm: Prepare for TTBR1 usage")
Although it doesn't need to go to -stable, since this was only introduced
during the recent merge window.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iommu/io-pgtable-arm: Fix IOVA validation for 32-bit
2020-02-28 14:18 ` Robin Murphy
@ 2020-03-02 19:57 ` Stephan Gerhold
-1 siblings, 0 replies; 10+ messages in thread
From: Stephan Gerhold @ 2020-03-02 19:57 UTC (permalink / raw)
To: Robin Murphy; +Cc: will, iommu, linux-arm-kernel
Hi Robin,
On Fri, Feb 28, 2020 at 02:18:55PM +0000, Robin Murphy wrote:
> Since we ony support the TTB1 quirk for AArch64 contexts, and
> consequently only for 64-bit builds, the sign-extension aspect of the
> "are all bits above IAS consistent?" check should implicitly only apply
> to 64-bit IOVAs. Change the type of the cast to ensure that 32-bit longs
> don't inadvertently get sign-extended, and thus considered invalid, if
> they happen to be above 2GB in the TTB0 region.
>
> Reported-by: Stephan Gerhold <stephan@gerhold.net>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
Thanks for the patch!
Just wanted to report that this patch does indeed fix the problem
I had with qcom-venus on ARM32.
It's probably too late now, but FWIW:
Tested-by: Stephan Gerhold <stephan@gerhold.net>
> ---
>
> Logically there may also have been a UBSAN "shift greater than size of
> type" warning too, but arch/arm doesn't support UBSAN_SANITIZE_ALL,
> and that's now my only easy "spin up a 32-bit VM" option to hand :)
>
> drivers/iommu/io-pgtable-arm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 983b08477e64..04fbd4bf0ff9 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -468,7 +468,7 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
> arm_lpae_iopte *ptep = data->pgd;
> int ret, lvl = data->start_level;
> arm_lpae_iopte prot;
> - long iaext = (long)iova >> cfg->ias;
> + long iaext = (s64)iova >> cfg->ias;
>
> /* If no access, then nothing to do */
> if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
> @@ -645,7 +645,7 @@ static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
> struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
> struct io_pgtable_cfg *cfg = &data->iop.cfg;
> arm_lpae_iopte *ptep = data->pgd;
> - long iaext = (long)iova >> cfg->ias;
> + long iaext = (s64)iova >> cfg->ias;
>
> if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size))
> return 0;
> --
> 2.23.0.dirty
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] iommu/io-pgtable-arm: Fix IOVA validation for 32-bit
@ 2020-03-02 19:57 ` Stephan Gerhold
0 siblings, 0 replies; 10+ messages in thread
From: Stephan Gerhold @ 2020-03-02 19:57 UTC (permalink / raw)
To: Robin Murphy; +Cc: joro, will, iommu, linux-arm-kernel
Hi Robin,
On Fri, Feb 28, 2020 at 02:18:55PM +0000, Robin Murphy wrote:
> Since we ony support the TTB1 quirk for AArch64 contexts, and
> consequently only for 64-bit builds, the sign-extension aspect of the
> "are all bits above IAS consistent?" check should implicitly only apply
> to 64-bit IOVAs. Change the type of the cast to ensure that 32-bit longs
> don't inadvertently get sign-extended, and thus considered invalid, if
> they happen to be above 2GB in the TTB0 region.
>
> Reported-by: Stephan Gerhold <stephan@gerhold.net>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
Thanks for the patch!
Just wanted to report that this patch does indeed fix the problem
I had with qcom-venus on ARM32.
It's probably too late now, but FWIW:
Tested-by: Stephan Gerhold <stephan@gerhold.net>
> ---
>
> Logically there may also have been a UBSAN "shift greater than size of
> type" warning too, but arch/arm doesn't support UBSAN_SANITIZE_ALL,
> and that's now my only easy "spin up a 32-bit VM" option to hand :)
>
> drivers/iommu/io-pgtable-arm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 983b08477e64..04fbd4bf0ff9 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -468,7 +468,7 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
> arm_lpae_iopte *ptep = data->pgd;
> int ret, lvl = data->start_level;
> arm_lpae_iopte prot;
> - long iaext = (long)iova >> cfg->ias;
> + long iaext = (s64)iova >> cfg->ias;
>
> /* If no access, then nothing to do */
> if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
> @@ -645,7 +645,7 @@ static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
> struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
> struct io_pgtable_cfg *cfg = &data->iop.cfg;
> arm_lpae_iopte *ptep = data->pgd;
> - long iaext = (long)iova >> cfg->ias;
> + long iaext = (s64)iova >> cfg->ias;
>
> if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size))
> return 0;
> --
> 2.23.0.dirty
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-03-02 20:03 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-28 14:18 [PATCH] iommu/io-pgtable-arm: Fix IOVA validation for 32-bit Robin Murphy
2020-02-28 14:18 ` Robin Murphy
2020-03-02 11:53 ` Will Deacon
2020-03-02 11:53 ` Will Deacon
2020-03-02 16:11 ` Joerg Roedel
2020-03-02 16:11 ` Joerg Roedel
2020-03-02 16:14 ` Will Deacon
2020-03-02 16:14 ` Will Deacon
2020-03-02 19:57 ` Stephan Gerhold
2020-03-02 19:57 ` Stephan Gerhold
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.