Skip to content
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

openamp: replace all strncpy to strlcpy #602

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

wyr-7
Copy link

@wyr-7 wyr-7 commented Jul 9, 2024

No description provided.

strlcpy is more convenient and safer than strncpy

Signed-off-by: Yongrong Wang <[email protected]>
@arnopo
Copy link
Collaborator

arnopo commented Jul 11, 2024

It seems that strlcpy is only available recently in glibc, or I'm wrong?
in such case, I'm not sure if we can use it if we want to maintain compatibility. Otherwise, we would have to create a default function.

@@ -141,7 +141,7 @@ int rpmsg_send_ns_message(struct rpmsg_endpoint *ept, unsigned long flags)

ns_msg.flags = flags;
ns_msg.addr = ept->addr;
strncpy(ns_msg.name, ept->name, sizeof(ns_msg.name));
strlcpy(ns_msg.name, ept->name, sizeof(ns_msg.name));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ept->name is safe as already truncated in rpmsg_register_endpoint, we could use a memcpy here.

@@ -305,7 +305,7 @@ void rpmsg_register_endpoint(struct rpmsg_device *rdev,
rpmsg_ept_cb cb,
rpmsg_ns_unbind_cb ns_unbind_cb, void *priv)
{
strncpy(ept->name, name ? name : "", sizeof(ept->name));
strlcpy(ept->name, name ? name : "", sizeof(ept->name));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should create our own strncpy.
we could create a libutil/strncpy.c that contains a safe_strncpy function.

char *safe_strncpy(char *dest, char *src, size_t size) {
	size_t len;

	if (size == 0) {
		dest[0] = '\0';
	} else {	
		len = strnlen(src, size - 1);
		memcpy(dest, src, len);
		dest[len] = '\0';
	}
	return dest;
}

@edmooring, @tnmysh : any opinon/suggestion?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that makes sense. In kernel as well, strlcpy was deprecated, and strscpy was introduced. https://www.kernel.org/doc/html/latest/core-api/kernel-api.html?highlight=declare_bitmap#c.strscpy

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am okay, to introduce such function.

Copy link
Contributor

@edmooring edmooring left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to look closely at how Linux RPMSG handles these cases. My impression was that the Linux kernel implementation could leave some strings not null-terminated.

This ops can do in rpmsg without coupling to virtio.

Signed-off-by: wangyongrong <[email protected]>
@@ -55,6 +55,7 @@ typedef void (*rpmsg_ept_release_cb)(struct rpmsg_endpoint *ept);
typedef void (*rpmsg_ns_unbind_cb)(struct rpmsg_endpoint *ept);
typedef void (*rpmsg_ns_bind_cb)(struct rpmsg_device *rdev,
const char *name, uint32_t dest);
typedef int (*rpmsg_notify_wait_cb)(struct rpmsg_device *rdev, uint32_t id);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please introduce this commit in a new PR, you also need to provide more information to explain why you need this update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants