Add kernel lockdown utility functions

[maramsmurthy]

This commit adds three new utility functions to avocado.utils.linux for managing kernel lockdown security feature:

1. is_kernel_lockdown_enabled(): Check current lockdown state

   • Returns tuple of (mode, is_enabled)
   • Supports none, integrity, and confidentiality modes
   • Handles cases where lockdown feature is unavailable

2. enable_kernel_lockdown_integrity(): Enable integrity mode

   • Prevents kernel modification
   • Verifies mode change via sysfs
   • Validates dmesg for lockdown message

3. enable_kernel_lockdown_confidentiality(): Enable confidentiality mode

   • Most restrictive mode (prevents modification and data exposure)
   • Verifies mode change via sysfs
   • Validates dmesg for lockdown message

All functions follow PEP 8 standards and include comprehensive docstrings. Lockdown mode transitions are one-way at runtime and require reboot to downgrade.

[maramsmurthy]

All 3 definitions are functioning as expected

from avocado.utils import linux
linux.is_kernel_lockdown_enabled()
('none', False)
linux.enable_kernel_lockdown_integrity()
True
linux.is_kernel_lockdown_enabled()
('integrity', True)
linux.enable_kernel_lockdown_confidentiality()
True
linux.is_kernel_lockdown_enabled()
('confidentiality', True)

[gemini-code-assist]

Code Review

This pull request introduces functionality to manage kernel lockdown states in avocado/utils/linux.py, including functions to check the current mode and enable integrity or confidentiality modes via sysfs. The review feedback correctly identifies that the dmesg log verification used during the enablement process is redundant and fragile, as the state change is already confirmed by reading the sysfs file. Consequently, it is recommended to remove these checks and the associated dmesg module import to improve reliability and performance.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 40 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.58%. Comparing base (33fb4ab) to head (ac57af8).

Files with missing lines	Patch %	Lines
avocado/utils/linux.py	0.00%	40 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6306      +/-   ##
==========================================
- Coverage   71.69%   71.58%   -0.12%     
==========================================
  Files         206      206              
  Lines       23480    23519      +39     
==========================================
  Hits        16835    16835              
- Misses       6645     6684      +39     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[harvey0100]

Hi @maramsmurthy, could you please rebase your branch on current master? The RTD docs build is failing because your branch predates a fix we merged in March (setuptools <82 pin in requirements-doc.txt). A rebase will pick that up and the RTD check should pass.

[maramsmurthy]

Hi @maramsmurthy, could you please rebase your branch on current master? The RTD docs build is failing because your branch predates a fix we merged in March (setuptools <82 pin in requirements-doc.txt). A rebase will pick that up and the RTD check should pass.

Thank you so much for the update @harvey0100 !

Will do as suggested

[pevogam]

The fedora-rawhide-x86_64 builds are failing on many pull requests from what I can see, is this normal @harvey0100?

Also @vaishnavibhat, what about a pull request in aautils that moves the linux file there in one first commit and this diff as second commit? I think adding code to the local avocado utils is only going to make future migration to aautils harder which is why this might be a good time to do it.

[maramsmurthy]

The fedora-rawhide-x86_64 builds are failing on many pull requests from what I can see, is this normal @harvey0100?

Also @vaishnavibhat, what about a pull request in aautils that moves the linux file there in one first commit and this diff as second commit? I think adding code to the local avocado utils is only going to make future migration to aautils harder which is why this might be a good time to do it.

Thanks for bringing this up! I'm also not aware of the root cause for the fedora-rawhide-x86_64 build failure. I've been observing this issue across multiple PRs recently, so it appears to be a broader infrastructure or dependency issue rather than something specific to this PR.

I'll wait for @harvey0100 input on this, as they may have more context about the CI environment. In the meantime, I'll continue monitoring the other test results.

@pevogam - Could you please comment about this context on one of @vaishnavibhat's open PRs? This will help ensure she's aware of the discussion and any relevant implications for her work.

However, at this point in time, we'd like to proceed with adding this functionality to avocado.utils for the following reasons:

• It maintains consistency with the current codebase structure
• It allows us to deliver this feature without introducing additional migration complexity right now
• We can plan a more comprehensive migration to aautils as a separate, focused effort

That said, I'd like to get @PraveenPenguin opinion on this approach to ensure we're aligned with the project's long-term direction. If there's strong consensus that we should migrate to aautils now, I'm happy to raise a separate PR under aautils for the same functionality.

What do you think would be the best path forward?

[pevogam]

@pevogam - Could you please comment about this context on one of @vaishnavibhat's open PRs? This will help ensure she's aware of the discussion and any relevant implications for her work?

Would you mind linking to a particular PR because I don't find any open PRs on author:vaishnavibhat.

I'll wait for @harvey0100 input on this, as they may have more context about the CI environment. In the meantime, I'll continue monitoring the other test results.

Indeed, I could try to look into this but my concern is that the failing workflow is directly tied with Fedora and Fedora maintainers and red hatters like @harvey0100 are better related to their workflows. Let's see, if he is too busy I could look for any easy fixes or temporarily disabling / expected-fail-ing this particular workflow.