| Message ID | 1588193551-31439-1-git-send-email-bbhatt@codeaurora.org |
|---|---|
| Headers | show |
| Series | Bug fixes and improved logging in MHI | expand |
On 4/29/2020 2:52 PM, Bhaumik Bhatt wrote: > Add a bounds check in the firmware copy routine to exit if a malformed > vector table is found while attempting to load the firmware in to the > BHIe vector table. > > Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org> > --- > drivers/bus/mhi/core/boot.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c > index 17c636b..bc70edc 100644 > --- a/drivers/bus/mhi/core/boot.c > +++ b/drivers/bus/mhi/core/boot.c > @@ -362,8 +362,14 @@ static void mhi_firmware_copy(struct mhi_controller *mhi_cntrl, > int i = 0; > struct mhi_buf *mhi_buf = img_info->mhi_buf; > struct bhi_vec_entry *bhi_vec = img_info->bhi_vec; > + struct device *dev = &mhi_cntrl->mhi_dev->dev; > > while (remainder) { > + if (WARN_ON(i >= img_info->entries)) { > + dev_err(dev, "Malformed vector table\n"); I feel like this message needs more detail. At a minimum, I think it should indicate what vector table (BHIe). I think if you can identify what file, etc the the glitch is in, that would be better. Maybe some detail about i and img_info->entries. If I see this error message, I should have enough information to immediately debug the issue. If it tells enough to go directly into the firmware file and have a look at entry X to see what might be corrupt about it, that makes my debugging very efficient. If I have to go back to the code to figure out what "Malformed vector table" means, and then maybe apply a patch to get more data about the error - the error message is not as useful as it should be. > + return; > + } > + > to_cpy = min(remainder, mhi_buf->len); > memcpy(mhi_buf->buf, buf, to_cpy); > bhi_vec->dma_addr = mhi_buf->dma_addr; >
On 4/29/2020 2:52 PM, Bhaumik Bhatt wrote: > Add log messages to track boot flow errors and timeouts in SBL or AMSS > firmware loading to aid in debug. > > Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org> > Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org>
On 2020-04-30 08:02, Jeffrey Hugo wrote: > On 4/29/2020 2:52 PM, Bhaumik Bhatt wrote: >> Add a bounds check in the firmware copy routine to exit if a malformed >> vector table is found while attempting to load the firmware in to the >> BHIe vector table. >> >> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org> >> --- >> drivers/bus/mhi/core/boot.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c >> index 17c636b..bc70edc 100644 >> --- a/drivers/bus/mhi/core/boot.c >> +++ b/drivers/bus/mhi/core/boot.c >> @@ -362,8 +362,14 @@ static void mhi_firmware_copy(struct >> mhi_controller *mhi_cntrl, >> int i = 0; >> struct mhi_buf *mhi_buf = img_info->mhi_buf; >> struct bhi_vec_entry *bhi_vec = img_info->bhi_vec; >> + struct device *dev = &mhi_cntrl->mhi_dev->dev; >> while (remainder) { >> + if (WARN_ON(i >= img_info->entries)) { >> + dev_err(dev, "Malformed vector table\n"); > > I feel like this message needs more detail. At a minimum, I think it > should indicate what vector table (BHIe). I think if you can identify > what file, etc the the glitch is in, that would be better. Maybe some > detail about i and img_info->entries. > > If I see this error message, I should have enough information to > immediately debug the issue. If it tells enough to go directly into > the firmware file and have a look at entry X to see what might be > corrupt about it, that makes my debugging very efficient. If I have > to go back to the code to figure out what "Malformed vector table" > means, and then maybe apply a patch to get more data about the error - > the error message is not as useful as it should be. > I plan on dropping this patch as it looks like an unnecessary check since we will always rely on the firmware->size from the request_firmware() API in order to calculate the img_info->entries (or we can call it the number of segments, in our case). And we will never fail in the if loop as values will already be bounded. >> + return; >> + } >> + >> to_cpy = min(remainder, mhi_buf->len); >> memcpy(mhi_buf->buf, buf, to_cpy); >> bhi_vec->dma_addr = mhi_buf->dma_addr; >>