Message ID | 1467202586-13412-1-git-send-email-imunsie@au.ibm.com (mailing list archive) |
---|---|
State | Accepted |
Headers | show |
Le 29/06/2016 14:16, Ian Munsie a écrit : > From: Ian Munsie <imunsie@au1.ibm.com> > > If the AFU descriptor of an AFU directed AFU indicates that it supports > 0 maximum processes, we will accept that value and attempt to use it. > The SPA will still be allocated (with 2 pages due to another minor bug > and room for 958 processes), and when a context is allocated we will > pass the value of 0 to idr_alloc as the maximum. However, idr_alloc will > treat that as meaning no maximum and will allocate a context number and > we return a valid context. > > Conceivably, this could lead to a buffer overflow of the SPA if more > than 958 contexts were allocated, however this is mitigated by the fact > that there are no known AFUs in the wild with a bogus AFU descriptor > like this, and that only the root user is allowed to flash an AFU image > to a card. > > Add a check when validating the AFU descriptor to reject any with 0 > maximum processes. > > We do still allow a dedicated process only AFU to indicate that it > supports 0 contexts even though that is forbidden in the architecture, > as in that case we ignore the value and use 1 instead. This is just on > the off-chance that such a dedicated process AFU may exist (not that I > am aware of any), since their developers are less likely to have cared > about this value at all. > > Signed-off-by: Ian Munsie <imunsie@au1.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
On 29/06/16 22:16, Ian Munsie wrote: > From: Ian Munsie <imunsie@au1.ibm.com> > > If the AFU descriptor of an AFU directed AFU indicates that it supports > 0 maximum processes, we will accept that value and attempt to use it. > The SPA will still be allocated (with 2 pages due to another minor bug > and room for 958 processes), and when a context is allocated we will > pass the value of 0 to idr_alloc as the maximum. However, idr_alloc will > treat that as meaning no maximum and will allocate a context number and > we return a valid context. > > Conceivably, this could lead to a buffer overflow of the SPA if more > than 958 contexts were allocated, however this is mitigated by the fact > that there are no known AFUs in the wild with a bogus AFU descriptor > like this, and that only the root user is allowed to flash an AFU image > to a card. > > Add a check when validating the AFU descriptor to reject any with 0 > maximum processes. > > We do still allow a dedicated process only AFU to indicate that it > supports 0 contexts even though that is forbidden in the architecture, > as in that case we ignore the value and use 1 instead. This is just on > the off-chance that such a dedicated process AFU may exist (not that I > am aware of any), since their developers are less likely to have cared > about this value at all. > > Signed-off-by: Ian Munsie <imunsie@au1.ibm.com> Looks good to me. Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
On Wed, 2016-29-06 at 12:16:25 UTC, Ian Munsie wrote: > From: Ian Munsie <imunsie@au1.ibm.com> > > If the AFU descriptor of an AFU directed AFU indicates that it supports > 0 maximum processes, we will accept that value and attempt to use it. > The SPA will still be allocated (with 2 pages due to another minor bug > and room for 958 processes), and when a context is allocated we will > pass the value of 0 to idr_alloc as the maximum. However, idr_alloc will > treat that as meaning no maximum and will allocate a context number and > we return a valid context. > > Conceivably, this could lead to a buffer overflow of the SPA if more > than 958 contexts were allocated, however this is mitigated by the fact > that there are no known AFUs in the wild with a bogus AFU descriptor > like this, and that only the root user is allowed to flash an AFU image > to a card. > > Add a check when validating the AFU descriptor to reject any with 0 > maximum processes. > > We do still allow a dedicated process only AFU to indicate that it > supports 0 contexts even though that is forbidden in the architecture, > as in that case we ignore the value and use 1 instead. This is just on > the off-chance that such a dedicated process AFU may exist (not that I > am aware of any), since their developers are less likely to have cared > about this value at all. > > Signed-off-by: Ian Munsie <imunsie@au1.ibm.com> > Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> > Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/49e9c99f47fc43abc9598f9fcf cheers
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c index 648817a..58d7d821 100644 --- a/drivers/misc/cxl/pci.c +++ b/drivers/misc/cxl/pci.c @@ -775,6 +775,21 @@ static int cxl_afu_descriptor_looks_ok(struct cxl_afu *afu) } } + if ((afu->modes_supported & ~CXL_MODE_DEDICATED) && afu->max_procs_virtualised == 0) { + /* + * We could also check this for the dedicated process model + * since the architecture indicates it should be set to 1, but + * in that case we ignore the value and I'd rather not risk + * breaking any existing dedicated process AFUs that left it as + * 0 (not that I'm aware of any). It is clearly an error for an + * AFU directed AFU to set this to 0, and would have previously + * triggered a bug resulting in the maximum not being enforced + * at all since idr_alloc treats 0 as no maximum. + */ + dev_err(&afu->dev, "AFU does not support any processes\n"); + return -EINVAL; + } + return 0; }