nf_tables and iptable_filter kernel modules fail with "Operation not permitted" on Trusted Launch VM despite Secure Boot disabled

Hello @Michal Hrcka

Yes, known bug - vTPM state corruption after resize on Trusted Launch.

Your boot log tpm_crb: Bad ACPI memory layout + Disabling hwrng = vTPM NVRAM got out of sync when you resized D2as -> D4as. When vTPM is broken, Debian cloud kernel blocks nf_tables/iptable_filter with EPERM even though lockdown says [none] and Secure Boot says disabled. GuestAttestation extension installs but never starts for same reason.

Fix:

Don't troubleshoot modules - fix vTPM:

Bash

# 1. Remove attestation extensionaz vm extension delete -g RG -n VM --name GuestAttestation
# 2. Disable vTPM + SecureBoot fully and force re-create TPMaz vm update -g RG -n VM --set securityProfile.uefiSettings.vTpmEnabled=false securityProfile.uefiSettings.secureBootEnabled=falseaz vm deallocate -g RG -n VMaz vm update -g RG -n VM --set securityProfile.uefiSettings.vTpmEnabled=true securityProfile.uefiSettings.secureBootEnabled=falseaz vm start -g RG -n VM

If still Bad ACPI layout -> VM is stuck in Trusted Launch with broken TPM. Only clean fix is redeploy to Standard security type - you can't downgrade Trusted Launch in place:

Create snapshot of OS disk > create new disk > create new VM with --security-type Standard - then nf_tables loads fine.

For prod, avoid resizing Trusted Launch VMs - always deallocate before resize.

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

Hello Michal Hrcka, 

Thank you for the detailed troubleshooting notes. 

From the information shared so far, we cannot confirm a known vTPM or attestation state inconsistency after the VM resize. In Azure Trusted Launch, vTPM supports boot-chain measurement and remote attestation, while Secure Boot verifies signed boot components and kernel drivers. Because Secure Boot is disabled and kernel lockdown shows [none], the current evidence does not point directly to Azure Trusted Launch or vTPM preventing the nf_tables or iptable_filter modules from loading. 

At this point, the issue appears more likely to be within the guest OS/kernel/module-loading path. The next step is to capture the exact kernel-side denial reason immediately after reproducing the failure: 

sudo modprobe -v nf_tables

 sudo modprobe -v iptable_filter 

sudo dmesg -T | egrep -i "nf_tables|iptable_filter|module|lockdown|signature|tomoyo|apparmor|secure|permission|denied|taint" 

sudo journalctl -k -b | egrep -i "nf_tables|iptable_filter|module|lockdown|signature|tomoyo|apparmor|secure|permission|denied"

Please also confirm whether the issue is limited to the current kernel by booting into an earlier installed kernel, if available, or by testing with another supported Debian kernel package. You can also compare the behavior with a newly deployed Debian 12 Trusted Launch VM in the same region and with the same VM size. 

Recommended remediation path: 

• Take a snapshot or back up the OS disk before making any further changes. 
• Try booting into an earlier known-good kernel, if one is available. 
• Reinstall or install an alternate supported Debian kernel, then regenerate initramfs. 
• If the issue remains specific to this VM, test with a clean Debian 12 Trusted Launch VM in the same region and size. 
• If the clean VM works, continue with guest OS repair using a rescue VM or migrate the workload to the clean VM. 

Keep the TPM-related serial console message as a data point, but on its own it does not confirm that vTPM or attestation is blocking the kernel modules. The key evidence we need is the kernel log entry generated at the time modprobe or insmod fails.