-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Application-supplied buffer addresses not checked for validity #406
Conversation
e450d21
to
eca60ff
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to make these chunks into a macro? At first glance, they are all doing the same thing.
@edmooring Yes, I can do that. Thank you. |
I have not ported my API test application to OpenAMP, but here are the tests I am running against our implementation:
|
lib/rpmsg/rpmsg_internal.h
Outdated
sizeof(struct rpmsg_hdr))) && \ | ||
((addr + len) < (((struct metal_io_region *)rvdev->rvq->shm_io)->virt + \ | ||
((struct metal_io_region *)rvdev->rvq->shm_io)->size))) ? 1 : 0) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The metal_io_region structure should be manipulated in libmetal.
please create metal_io_block_check
or metal_io_is_block_valid
API in libmetal instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arnopo I have some questions since this will cause a dependency for OpenAMP on a specific version of libmetal. From a PR merging standpoint, we can just ensure the two PRs in the different repos are merged at the same time, but from a release standpoint, how do we denote that OpenAMP version x is dependent on libmetal version y? Or, do we strive to keep OpenAMP interoperable with older verisons of libmetal and thus remove dependencies? In which case, I would need to #define the libmetal macro to nothing within OpenAMP if it doesn't already exist in libmetal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question:
In term of merging, I will integrate the libmetal first, and rerun the OpenAMP build test to ensure that is working.
For the release. I don't expect to maintain interoperability with older versions of libmetal.
I think we should only have a dependency message in the release note and offer to send a PR on the dedicated branch for the release if backwards compatibility is needed for a specific libmetal version.
I assume that libmetal APIs will be independent enough to be backported to a legacy branch...
@edmooring: what is your feeling?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arnopo: I agree. I think there has always been an implicit assumption that the libmetal and open amp libraries are tightly coupled. We should probably document this.
Code must check for valid buffer address to avoid potential corruption Signed-off-by: Tammy Leino <[email protected]>
657a882
to
a30441c
Compare
Build will fail until OpenAMP/libmetal#222 is merged, but I wanted to commit these changes so they can be reviewed in sync with the libmetal PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to go.
This pull request has been marked as a stale pull request because it has been open (more than) 45 days with no activity. |
Code must check for valid buffer address to avoid potential corruption
Signed-off-by: Tammy Leino [email protected]