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

8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups #14491

Closed
wants to merge 17 commits into from

Conversation

Michael-Mc-Mahon
Copy link
Member

@Michael-Mc-Mahon Michael-Mc-Mahon commented Jun 15, 2023

Hi,

Can I get the following change reviewed please? It disables the IPV6_MULTICAST_ALL socket option on UDP sockets on Linux systems which support the option (kernel version 4.20+). This has the effect of disabling the surprising default behavior of multicast sockets on Linux where sockets can receive packets sent to groups the receiver has not joined, if some other socket has joined that group on the same system.

The equivalent behavior has already been implemented for IPv4 sockets.

Thanks,
Michael.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups (Enhancement - P3)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14491/head:pull/14491
$ git checkout pull/14491

Update a local copy of the PR:
$ git checkout pull/14491
$ git pull https://git.openjdk.org/jdk.git pull/14491/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 14491

View PR using the GUI difftool:
$ git pr show -t 14491

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14491.diff

Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Jun 15, 2023

👋 Welcome back michaelm! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr Pull request is ready for review label Jun 15, 2023
@openjdk
Copy link

openjdk bot commented Jun 15, 2023

@Michael-Mc-Mahon The following label will be automatically applied to this pull request:

  • nio

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the nio nio-dev@openjdk.org label Jun 15, 2023
@mlbridge
Copy link

mlbridge bot commented Jun 15, 2023

"Unable to set IPV6_MULTICAST_ALL");
close(fd);
return -1;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be better to move this to just below the attempt to set IPV6_MULTICAST_HOPS as that code only runs for IPv6 datagrams.

That said, I'm a bit concerned that this will fail on older kernels. Are you sure the error is ENOPROTOOPT?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, the error is the same as for the IPv4 option. If you like I can change the test to set the option and check an exception is not thrown in those cases.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, the error is the same as for the IPv4 option. If you like I can change the test to set the option and check an exception is not thrown in those cases.

If you are confident that ENOPROTOOPT is returned by older kernels then okay.

Also just to double check, IPV6_MULTICAST_ALL applied only to IPv6 multicast datagrams, we have to continue to set IP_MULTICAST_ALL for cases where the IPv6 socket joins an IPv4 multicast group.

@msheppar
Copy link

so is it the case that for INET6 two call setsockopt calls need to be called one for IP_MULTICAST_ALL and one for IPV6_MULTICAST_ALL. IFF that is the case I think two conditional blocks, on the domain, to emphasize this would be clearer and convey such semantics more cleanly

if (domain == AF_INET6) {
....
if((setsockopt(fd, IPPROTO_IPV6, IP_MULTICAST_ALL, (char*)&arg, sizeof(arg)) < 0) && ... {
....
}
if((setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_ALL, (char*)&arg, sizeof(arg)) < 0) && ... {
....
}
} else {
if((setsockopt(fd, IPPROTO_IP, IP_MULTICAST_ALL, (char*)&arg, sizeof(arg)) < 0) && ... {
....
}
}

@Michael-Mc-Mahon
Copy link
Member Author

It's certainly the case that the IPv4 option can be called on AF_INET6 sockets but only affects the IPv4 stack. Which suggests the IPv6 option only affects the IPv6 stack. I'll see if I can confirm that is true.

@Michael-Mc-Mahon
Copy link
Member Author

It's certainly the case that the IPv4 option can be called on AF_INET6 sockets but only affects the IPv4 stack. Which suggests the IPv6 option only affects the IPv6 stack. I'll see if I can confirm that is true.

I just checked and the two options are independent of each other, applying only to the IPv4 stack and IPv6 stack respectively.

"Unable to set IPV6_MULTICAST_ALL");
close(fd);
return -1;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This implementation change looks okay, assuming ENOPROTOOPT on older kernels. I haven't had time to study the test yet, tricky scenario to test reliably.

Copy link
Member Author

Choose a reason for hiding this comment

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

I am running some repeat 50 test runs of the datagram tests on the newer Linux systems.

@AlanBateman
Copy link
Contributor

Can you look at test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java? I wonder if this should be updated to exercise the test with two IPv6 multicast groups? In passing, I assume the check for the OS version isn't needed in this test anymore.

As regards the new test then I think the naming should be a bit more consistent with the existing tests if possible. The existing test for IP_MULTICAST_ALL is Promiscuous so maybe the new test is PromiscuousIPv6 or something with "IPv6" in the name?

The test launches "uname -r", maybe it can use the Platform test infra class instead.

The class initializer probes for interfaces that support IPv6 multicasting. Can this be moved to the main method so that it's easier to see in main why the test is skipping?

If < 4.20 then I think the test should just skip on Linux. No need to create a socket + close it. If we have an issue here then all DatagramChannel tests would fail.

The select(2000) might not be enough on slow machines. So if we are keeping this test then I think it will need a few rounds of cleanup to make it more robust.

@Michael-Mc-Mahon
Copy link
Member Author

Can you look at test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java? I wonder if this should be updated to exercise the test with two IPv6 multicast groups? In passing, I assume the check for the OS version isn't needed in this test anymore.

Okay

As regards the new test then I think the naming should be a bit more consistent with the existing tests if possible. The existing test for IP_MULTICAST_ALL is Promiscuous so maybe the new test is PromiscuousIPv6 or something with "IPv6" in the name?

Right

The test launches "uname -r", maybe it can use the Platform test infra class instead.

Ah, I missed that Platform can return the os version numbers. Will change that.

The class initializer probes for interfaces that support IPv6 multicasting. Can this be moved to the main method so that it's easier to see in main why the test is skipping?

ok

If < 4.20 then I think the test should just skip on Linux. No need to create a socket + close it. If we have an issue here then all DatagramChannel tests would fail.

ok, I just added that after the previous round. I will take it out.

The select(2000) might not be enough on slow machines. So if we are keeping this test then I think it will need a few rounds of cleanup to make it more robust.

I'll increase that. I suspect the test doesn't need othervm mode for that matter. Will change that too.

@openjdk openjdk bot removed the rfr Pull request is ready for review label Jun 16, 2023
@Michael-Mc-Mahon
Copy link
Member Author

So, it turns out there is already an IPv6 version of the Promiscuous test. It only required a small change to this test to verify the behavior with the wildcard address. I updated it, and removed the new test. Updated both Promiscuous.java and PromiscuousIPv6.java to use the test library Platform utility.

return;
}
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Version check removed, good!

// Solaris and Linux allow IPv6 sockets join IPv4 multicast groups
if (os.equals("Linux"))
// Linux allows IPv6 sockets join IPv4 multicast groups
if (Platform.isLinux())
Copy link
Contributor

Choose a reason for hiding this comment

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

If you can, it would be useful to double check it is Linux specific, I would expect it should pass on Windows and macOS too.


if (!os.equals("Linux")) {
if (!Platform.isLinux()) {
throw new SkippedException("This test should be run only on Linux");
Copy link
Contributor

Choose a reason for hiding this comment

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

The test has `@requires os.family == "linux" so it only runs on Linux. It doesn't need both, and maybe it will pass on Windows too.

@@ -145,6 +147,7 @@ static void receiveDatagram(DatagramChannel dc,

static void test(ProtocolFamily family,
NetworkInterface nif,
boolean bindToWildCard,
Copy link
Contributor

Choose a reason for hiding this comment

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

Wildcard rather than WildCard :-)

@AlanBateman
Copy link
Contributor

So, it turns out there is already an IPv6 version of the Promiscuous test. It only required a small change to this test to verify the behavior with the wildcard address. I updated it, and removed the new test

Good!

@Michael-Mc-Mahon
Copy link
Member Author

So, the test Promiscuous.java (the IPv4 version) can run on all platforms now. The IPv6 version (PromiscuousIPv6.java) still does not work on Windows.

@openjdk openjdk bot added the rfr Pull request is ready for review label Jun 19, 2023
@@ -43,6 +43,7 @@
import java.util.stream.Collectors;

import jdk.test.lib.NetworkConfiguration;
import jdk.test.lib.Platform;
Copy link
Contributor

Choose a reason for hiding this comment

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

I assume this isn't needed for the current patch.

if (os.equals("Linux"))
test(UNSPEC, nif, ip4Group1, ip4Group2);
// test IPv6 sockets joining IPv4 multicast groups
test(UNSPEC, nif, ip4Group1, ip4Group2);
Copy link
Contributor

Choose a reason for hiding this comment

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

The SAP and/or IBM folks that maintain the AIX port will probably have to adjust this to skip on that platform.

}
int major = Platform.getOsVersionMajor();
int minor = Platform.getOsVersionMinor();
hasIPV6MulticastAll = Platform.isOSX() || (major > 4) || ((major == 4 && minor >= 20));
Copy link
Contributor

Choose a reason for hiding this comment

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

The version check should be Linux only.

Copy link
Member Author

Choose a reason for hiding this comment

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

It runs the additional tests if it is MacOSX or if Linux and kernel > 4.20.

Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like it's good the version check on AIX too. I think you'll need to include a check for isLinux to avoid a follow-up bug from the maintainers of that port.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh, I see there is a missing pair of parentheses. I will fix that

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok then. I'll add explicit tests for Linux, Mac and Windows (for the IPv4 test), and Linux + Mac for the IPv6 one. The AIX folks can add that if/when they verify it works.

@@ -192,24 +193,13 @@ static void test(ProtocolFamily family,
}
}

private static boolean supportedByPlatform() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you mind adding a /**/ comment to this method to say that it returns true if platform allows an IPv6 socket join an IPv4 multicast group?

@@ -194,19 +201,22 @@ static void test(ProtocolFamily family,
}
}

private static boolean supportedByPlatform() {
Copy link
Contributor

Choose a reason for hiding this comment

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

This method too, I think it needs a comment to this method to say that it returns true if platform allows an IPv6 socket join an IPv4 multicast group without interference.

@openjdk
Copy link

openjdk bot commented Jun 19, 2023

@Michael-Mc-Mahon This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups

Reviewed-by: alanb

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 3 new commits pushed to the master branch:

  • 137a5f7: 8310105: LoongArch64 builds are broken after JDK-8304913
  • 33c6ec9: 8310019: MIPS builds are broken after JDK-8304913
  • e08e94f: 8310266: JFR: Refactor after 'view' command

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jun 19, 2023
@Michael-Mc-Mahon
Copy link
Member Author

/integrate

@openjdk
Copy link

openjdk bot commented Jun 19, 2023

Going to push as commit 7b45c8f.
Since your change was applied there have been 3 commits pushed to the master branch:

  • 137a5f7: 8310105: LoongArch64 builds are broken after JDK-8304913
  • 33c6ec9: 8310019: MIPS builds are broken after JDK-8304913
  • e08e94f: 8310266: JFR: Refactor after 'view' command

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Jun 19, 2023
@openjdk openjdk bot closed this Jun 19, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jun 19, 2023
@openjdk
Copy link

openjdk bot commented Jun 19, 2023

@Michael-Mc-Mahon Pushed as commit 7b45c8f.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@Michael-Mc-Mahon Michael-Mc-Mahon deleted the ipv6opt branch June 19, 2023 21:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated nio nio-dev@openjdk.org
3 participants