Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
114 changes: 114 additions & 0 deletions .github/workflows/kmod.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,114 @@
name: kmod Tests

on:
push:
branches: [ 'master', 'main', 'release/**' ]
pull_request:
branches: [ '*' ]

concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true

jobs:
build_wolfprovider:
uses: ./.github/workflows/build-wolfprovider.yml
with:
wolfssl_ref: ${{ matrix.wolfssl_ref }}
openssl_ref: ${{ matrix.openssl_ref }}
strategy:
matrix:
wolfssl_ref: [ 'master', 'v5.8.0-stable' ]
openssl_ref: [ 'openssl-3.5.0' ]

test_kmod:
runs-on: ubuntu-22.04
needs: build_wolfprovider
timeout-minutes: 20
strategy:
fail-fast: false
matrix:
kmod_ref: [ 'v33' ]
wolfssl_ref: [ 'master', 'v5.8.0-stable' ]
openssl_ref: [ 'openssl-3.5.0' ]
# Note: No WOLFPROV_FORCE_FAIL needed - kmod is only a signature parser,
Copy link
Contributor

@padelsbach padelsbach Jul 29, 2025

Choose a reason for hiding this comment

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

If this is true, then are we actually testing wolfprovider?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because WP is used to parse it just doesn't verify. WPFF shouldn't have any effect on the parsing functions that are used so there is no reason to test WPFF. We should still test WP for the parsing functions however since WP does use these.

Copy link
Contributor

Choose a reason for hiding this comment

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

WPFF shouldn't have any effect on the parsing functions

Can you elaborate on the reasoning behind this? I thought WPFF was our main mechanism for ensuring that WP is actually being used by the test.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep it is. Honestly the main reason is for IGEL

Copy link
Contributor

Choose a reason for hiding this comment

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

Any idea why we don't use WPFF in the parsing functions? Should we add it? Maybe @ColtonWilley can chime in here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Im not sure why we do not. This is a @ColtonWilley question for sure.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@padelsbach Colton and I have verified that kmod does use openssl to be able to do the parsing operation d2i_PKCS7_bio but this doesn't dispatch to any real crypto implementation that would call wolfProvider. So Basically Kmod needs openssl but it doesn't actually call any provider functionality. Either way we need this workflow to be implemented for IGEL.

Copy link
Contributor

Choose a reason for hiding this comment

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

this doesn't dispatch to any real crypto implementation that would call wolfProvider

So this doesn't actually call into wolfProvider? If that's true, why do we need this workflow?

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with @padelsbach if there is no crypto usage this should not be a workflow

# not a crypto verification tool. The signature tests only extract metadata
# (hash algo, signer name, key ID) but don't perform crypto operations.
steps:
- name: Checkout wolfProvider
uses: actions/checkout@v4
with:
fetch-depth: 1

- name: Retrieving wolfSSL/wolfProvider from cache
uses: actions/cache/restore@v4
id: wolfprov-cache
with:
path: |
wolfssl-install
wolfprov-install
openssl-install/lib64
openssl-install/include
openssl-install/bin

key: wolfprov-${{ matrix.wolfssl_ref }}-${{ matrix.openssl_ref }}-${{ github.sha }}
fail-on-cache-miss: true

- name: Install kmod test dependencies
run: |
sudo apt-get update
sudo apt-get install -y git sudo build-essential meson ninja-build \
pkg-config python3-pip python3-setuptools python3-wheel \
zlib1g-dev liblzma-dev libzstd-dev autotools-dev libtool \
automake autoconf

- name: Install kernel headers for kmod tests
run: |
sudo apt-get update
AVAILABLE_HEADERS=$(apt-cache search linux-headers | grep -E "^linux-headers-[0-9]" | head -1 | cut -d' ' -f1)
if [ -n "$AVAILABLE_HEADERS" ]; then
sudo apt-get install -y "$AVAILABLE_HEADERS"
KERNEL_VERSION=$(uname -r)
HEADERS_PATH=$(echo $AVAILABLE_HEADERS | sed 's/linux-headers-//')
sudo mkdir -p /lib/modules/$KERNEL_VERSION
sudo ln -sf /usr/src/linux-headers-$HEADERS_PATH /lib/modules/$KERNEL_VERSION/build
else
sudo apt-get install -y linux-headers-generic || echo "No generic headers available"
fi

- name: Download kmod
uses: actions/checkout@v4
with:
repository: kmod-project/kmod
ref: ${{ matrix.kmod_ref }}
path: kmod
fetch-depth: 1

- name: Checkout OSP
uses: actions/checkout@v4
with:
repository: wolfssl/osp
path: osp
fetch-depth: 1
- run: |
cd kmod
patch -p1 < $GITHUB_WORKSPACE/osp/wolfProvider/kmod/kmod-${{ matrix.kmod_ref }}-wolfprov.patch

- name: Build and install kmod
working-directory: kmod
run: |
source $GITHUB_WORKSPACE/scripts/env-setup
./autogen.sh
./configure --prefix="$GITHUB_WORKSPACE/kmod-install" \
--disable-manpages \
--with-openssl \
CPPFLAGS="-I$GITHUB_WORKSPACE/openssl-install/include" \
LDFLAGS="-L$GITHUB_WORKSPACE/openssl-install/lib64 -lcrypto"
make -j$(nproc)
sudo make install

- name: Run kmod tests
working-directory: kmod
run: |
source $GITHUB_WORKSPACE/scripts/env-setup
KMOD_LOG=debug TESTSUITE_VERBOSE=1 make check V=1
Loading