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

Add hal transmitter and socket support for remote hal #434

Merged
merged 2 commits into from May 16, 2024

Conversation

coldav
Copy link
Collaborator

@coldav coldav commented Apr 11, 2024

Overview

Add hal transmitter and socket support for remote hal

Reason for change

part of the support needed for communications for remote hal support

Description of change

Add base class hal_transmitter which can be used for simple send/ receive operations of data. This can be used by client and servers for different models of communication.

Also added a socket version which will be the default use case.

sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
server_address.sin_family = AF_INET;
server_address.sin_port = htons(port_requested);
server_address.sin_addr.s_addr = INADDR_ANY;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Always binding to all interfaces, with no way to override, seems like a possible security concern.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

what would you prefer here? I'm fairly new to sockets.

Copy link
Collaborator

Choose a reason for hiding this comment

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

See e.g. Apache's configuration, https://httpd.apache.org/docs/2.4/bind.html, where users can specify the IP address to listen to in addition to the port. How this should look in code I'm not entirely sure of, it depends on how this PR later ends up used, which I have not looked at yet.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm happy to extend this to an optional address and default to this (and document that) - would you be happy with that?

Copy link
Collaborator

Choose a reason for hiding this comment

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

That seems okay, though keep in mind that depending on the address, we may also need AF_INET6 instead of AF_INET.

Question: since the purpose of the HAL process is to take untrusted code from a remote client and execute it, what is the overall security going to look like?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

it does add risk, but the user should be aware that this does remotely run processes, so your suggestion of limiting it to a particular IP address sounds good. Also it's not got any superuser priviledges.
For that matter, you can override the libhal as a shared library and grab things that way.


hal_socket_transmitter::error_code hal_socket_transmitter::setup_connection(
bool server) {
// @return 0 if success, otherwise -1 and errno set
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does a @return comment work here?

@coldav coldav force-pushed the colin/hal_transmitter branch 4 times, most recently from 4c8f584 to 0729da9 Compare April 18, 2024 10:12
@coldav coldav force-pushed the colin/hal_transmitter branch 5 times, most recently from db1cdd2 to a612fb4 Compare May 1, 2024 16:15
Add base class hal_transmitter which can be used for simple send/
receive operations of data. This can be used by client and servers
for different models of communication.

Also added a socket version which will be the default use case.
}

int hal_socket_transmitter::listen() {
if (const int res = ::listen(sock, 1) != 0) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This means res is initialised to ::listen(sock, 1) != 0, i.e. it will always be zero or one, rather than returning the result of ::listen(sock, 1). Also, the if (res != 0) return res; else return 0; logic looks overly complicated, that amounts to just return res;.

But given that the API here is "1 is failure, 0 is success", whereas below for accept(), it's "-1 is failure, anything else, possibly zero, is the file descriptor that must not be used", I wonder if it's worth updating both to just return bool?

Copy link
Collaborator

Choose a reason for hiding this comment

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

This pattern of const int res = ... != 0 appears in a few other places where that does not look intentional.

// don't support port 0
if (port_requested == 0) {
if (debug_enabled()) {
(void)fprintf(stderr, "port 0 requested. This is disallowed\n");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Given that port 0 is the default, this may not actually have been requested, would an error message along the lines of "The port to listen on must be specified" work?

@coldav coldav merged commit dcc0a29 into codeplaysoftware:main May 16, 2024
3 checks passed
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.

None yet

2 participants