PoC code for SWIFT v2 addition to Kata

[JocelynBerrendonner]

Merge Checklist

• Followed patch format from upstream recommendation: https://github.com/kata-containers/community/blob/main/CONTRIBUTING.md#patch-format
• Included a single commit in a given PR - at least unless there are related commits and each makes sense as a change on its own.
• Merged using "create a merge commit" rather than "squash and merge" (or similar)
• genPolicy only: Builds on Windows
• genPolicy only: Updated sample YAMLs' policy annotations, if applicable

Summary

This PR captures the PoC code for SWIFT v2 support in Kata. The code does two things:

1. It adds support for vmbus based physical network adapters
2. It adds support for non-VF (i.e. non SR-IOV) physical network adapters

The code mostly modifies the physical network path to provide the above support. It also uses the same approach as VETH for all the non-VF / non SR-IOV network adapters that are being added to a Kata UVM.

Associated issues

Links to CVEs

Test Methodology

Manual validation of the PoC. No regression testing (this is pure PoC code)

[romoh]

Shouldn't that still be needed?

[JocelynBerrendonner]

It is still needed, but this check was moved into "createPhysicalEndpoint" because the VFIO Disabled config flag only applies to VFIO interfaces, and we can't check the VFIO Disabled config flag before we know the interface is an actual VFIO interface. In the previous code, the flow assumed that "isPhysical" automatically means "is VFIO", which is what I changed here, so this check cannot be done as early in the code anymore.

[romoh]

Should we add some logging here?

[JocelynBerrendonner]

I am on the fence for this one. I took the same approach as the existing veth code:

kata-containers/src/runtime/virtcontainers/veth_endpoint.go

Line 127 in a207f85

if !netNsCreated {

Adding logging here can significantly increase the number of log lines but the usefulness of the log line may be arguable (the netNsCreated flag is an internal flag to prevent detaching a network interface multiple times, as "Detach" can be called multiple times, so, if we add a log line here, we will see a call with "netNsCreated" for both the successful deletion, and the harmless subsequent calls to Detach. This may make the logs confusing).

In general, the issue arises because strconv.ParseInt is invoked with a 64-bit size, but the result is then converted to int with no check. To fix this pattern, either (a) parse with a bit size matching the target type (e.g., 32 for 32-bit int), or (b) keep parsing as 64-bit and add explicit bounds checks to ensure the value fits into the target type before converting.

Here, lastIdx is an int used as an index-like counter derived from the numeric suffix of an endpoint name. The safest and simplest change that preserves behavior is to (1) parse the numeric suffix as a 32-bit integer (since int is at least 32 bits) using strconv.ParseInt with bit size 32, (2) check that the parsed value is non-negative and within the int range, and then (3) convert to int. Because we must avoid extra imports and math is not currently imported in this file, we cannot rely on math.MaxInt32 directly; however, if we parse with bit size 32 and then convert to int, the value is guaranteed to fit in int on 32-bit and 64-bit Go architectures (where int is 32 or 64 bits respectively). We should also guard against negative values defensively, even though the regex extracts only digits.

Concretely, in addSingleEndpoint in src/runtime/virtcontainers/network_linux.go, modify the block that extracts and parses the numeric suffix: change the ParseInt call to use bit size 32, and replace lastIdx = int(n) with a small validity check, e.g., ensure n >= 0 before assigning and otherwise return an error. All other behavior remains the same.