Creating a custom Debian kernel package with an external patch

[MrT]

I needed to patch the kernel for ACS override and I found this process to be unexpectedly complicated and difficult in debian.

If I had just downloaded the tarball from kernel.org and done it the old way I would have been done with this yesterday, but I wanted to keep using the stable debian kernel with the only difference being the ACS Override patch.

I have a folder full of new fresh .debs, but if I want to install any of them it complains that it will conflict with what I already have installed. I do not wish to remove the kernel I already have installed in case I need to boot to it again.

I ended up using someone else's Makefile that magically renamed the packages, but I am still left with an unsigned kernel I can't use secure boot with.

#1 If I recompile and install the "proper" debian way, how do I ensure the packages are named differently enough to not conflict with the stock kernel already installed?
#2 How do I use the signed-templates package to sign my newly compiled kernel for use with secure boot?

I have already seen https://wiki.debian.org/SecureBoot#Shim, but surely there is an easier way?
I would follow the above, but I am afraid I will mess up the signing of the currently installed kernel since I have no idea how this works.

[CwF]

I moved this to the more appropriate Hardware forum.

Not an answer, but have you considered building a machine to purpose with a motherboard that doesn't need the ACS patch? I have tried it a few times and never resulted in a 24/7/365 stable result. I've done up to 4 gpu's without the patch on a default stable kernel with perfect stability. The next snag is the gpu's themselves - not all work correctly.

For overall superior results the hardware should be a primary consideration and not an afterthought.

[MrT]

I don't need hardware help... I already have a Windows guest working at bare metal performance in games with a RTX 4090.

I just want to make a second guest for a Linux desktop VM. The problem is I need to split off another USB controller to pass through to this second VM, and I can't do that without the ACS patch...

The ACS is patch is perfectly stable for my use case. I have already been dealing with people supporting the VFIO end of things.

Why is it so incredibly hard to recompile and install a kernel in debian? I just need some example command lines so I don't run into the issues in my first post. The documentation is very sparse for this issue. A Makefile would be nice...

I shouldn't be getting stuck on trying to recompiling a kernel. I should be getting filtered by the the VFIO setup, but I already have that part covered!

[CwF]

I see.
I'm surprised usb needs the tweak. Most usb thing soft pass without vfio. Too few usb's onboard, and no room for a usb card to pass?

The only reason I see to vfio a usb port is to allow a vm to boot from port. Some usb devices have been problematic in the past and benefit from a vfio port, but all my examples have become soft pass tolerant. That's tv, bt, wifi, game controllers, loggers, etc.

Also note that for usb and most network examples a device can be vfio declared and it does not prevent host use or soft pass to another vm while the vfio claiming vm is not running. So the only case to vfio a usb port (other than boot) is if the device has a sticky driver active in the host - for which I've only seen gpu's and storage controllers guilty of.

What's the usb device?

Good luck.

[MrT]

Well there's too many USB controllers on this thing. I didn't want to mention this part since it is hardware related, but this is a known bug/issue. The VFIO guys blame it on AMD who is outsourcing to ASmedia.... On AM5 boards if you try to pass through a USB controller on the CPU lanes it will crash the host. Newer kernels will not fix the issue.

That leaves you with three USB controllers on the chipset lanes. One is on its own IOMMU group, but the other two are on a group with the onboard NIC etc.. I know the security issues, but since it will be my personal desktop guest, it's not like it will be any worse than running it on bare metal. The Windows guest that I want full isolation from the host is already fully isolated.

If you use other methods of passing stuff through it requires more complicated configuration and it won't be as performant. On something like Proxmox it is easy to do, but I opted to not use it because I would prefer to use libvirt. I would also just prefer to use pcie pass if possible. Emulated ports will have degraded performance.

Another reason is I am already isolating the other USB controller with the same vendor id at boot time, so I really must use this with pcie pass. The vendor id will lock out both of them as unavailable to the host. ACS patch is the best solution here.

Code: Select all

10:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43f7 (rev 01) (prog-if 30 [XHCI])
        Subsystem: ASMedia Technology Inc. Device 1142
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 24
        IOMMU group: 15
        Region 0: Memory at 80800000 (64-bit, non-prefetchable) [size=32K]
        Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [68] MSI-X: Enable- Count=8 Masked-
                Vector table: BAR=0 offset=00002000
                PBA: BAR=0 offset=00002080
        Capabilities: [78] Power Management version 3
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
        Capabilities: [80] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 256 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis- NROPrPrP- LTR+
                         10BitTagComp+ 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
                         EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
                         FRS-
                         AtomicOpsCap: 32bit- 64bit- 128bitCAS-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ 10BitTagReq- OBFF Disabled,
                         AtomicOpsCtl: ReqEn-
                LnkCap2: Supported Link Speeds: 2.5GT/s, Crosslink- Retimer+ 2Retimers+ DRS-
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot
                LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete- EqualizationPhase1-
                         EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
                         Retimer- 2Retimers- CrosslinkRes: unsupported
                                 Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
                AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn-
                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
                HeaderLog: 00000000 00000000 00000000 00000000
        Capabilities: [160 v1] Latency Tolerance Reporting
                Max snoop latency: 0ns
                Max no snoop latency: 0ns
        Kernel driver in use: vfio-pci
        Kernel modules: xhci_pci

[CwF]

Got it.

The vendor id will lock out both of them as unavailable to the host.

I mentioned this, it doesn't lock them out, especially usb. Declaring vfio may 'avoid' loading a host driver. Sticky drivers is what I called it - vfio is a placeholder and the host can still use the device, it just doesn't autoconfigure at boot.
Perhaps this also doesn't work on the AMD platform, I wouldn't know. I do see the issue if two within the same group need to be separated, bummer.

Someone with current kernel knowledge may come along. I gave it up at 4.72 and now carefully stay within the lines.

Note that 'soft' passing the usb within libvirt is not adding any emulating layer and is indistinguishable from vfio. The method is post boot vs pre boot defined, the hardware redirect is the same. This changed a few versions ago.

[MrT]

For the soft pass can you show me an example configuration?

<devices>
<hostdev mode='subsystem' type='usb'>
<source startupPolicy='optional' guestReset='off'>
<vendor id='0x1234'/>
<product id='0xbeef'/>
</source>
</hostdev>

The problem with this one is that there's multiple devices with the same vendor and product id. So this won't work for me.

Edit: Apparently you can use the address element also... will try it out in a bit. The question I have now is, do I need to remove the vfio-pci binding and load the usb driver module before trying this?

[CwF]

It's available via gui if using virt-manager (vm console view) or virt-viewer with "Redirect USB Device". a popup window will list all usb things available and is updated live

You can also issue the command using virsh which I don't do and would need to look up.

Even with a vfio gpu you can still use the console view (it will be a blank window) to accomplish this though while active it may redirect kbm+sound, no issue, just redirect usb and close the window. In any case, it's done after the guest boots. In your case the virsh route may be easier, and if only using a virsh script I'd assume this could be included.

The first vm would show both, pick one, the second vm will show the one left.

So yes, extra steps but simple steps.

Edit: Apparently you can use the address element also... will try it out in a bit. The question still is, do I need to remove the vfio-pci module and load the usb module before trying this?

yes for using the address. It may not care about the vfio declaration in the host if no vm is configured for it, a separate post boot pass will see the path. But yah, remove vfio for simplicity.

[MrT]

So, I was determined to do this. It should not have been this hard though.

Code: Select all

apt source linux
cd linux-version
patch -p1 <  path/to/patch
export DEB_BUILD_PROFILES='pkg.linux.nokerneldbg pkg.linux.nokerneldbginfo'
nano debian/changelog (change version line)
debian/rules source (fails)
md5sum debian/control > debian/control.md5sum
debian/rules source
DEB_RULES_REQUIRES_ROOT=no make -f debian/rules.gen binary-arch_amd64_none_amd64
cd ..
mkdir package-edit
cd package-edit
ar x ../linux-image-6.1.0-18-amd64-unsigned_6.1.76-1+ACSO1_amd64.deb
mkdir control
tar xvf control.tar.xz -C control 
sed -i s/linux-image-6.1.0-18/linux-image-6.1.0-18-ACSO/ control/control
tar -cv --lzma -f control.tar.xz -C control .
ar r ../linux-image-6.1.0-18-amd64-unsigned_6.1.76-1+ACSO1_amd64-fixed.deb debian-binary control.tar.xz data.tar.xz

I really wanted to made a guide for doing this, but I can't make a guide with patching the kernel being this kludge. I would really appreciate a better way. Tomorrow I might try to setup secure boot too.

[Aki]

Hello,

The "Debian Administrator's Handbook" and the "Debian Kernel Handbook" can help you compile the kernel the Debian way:

• The Debian Administrator's Handbook: 8.10. Compiling a Kernel

• Debian Kernel handbook: Rebuilding official Debian kernel packages

Hope this helps.

[MrT]

The problem is if you just rebuild it as the debian handbook tells you, the package will have the same name and conflict with the currently installed kernel.

If I had used dpkg-buildpackage I am assuming I could have used "--append-to-version", but the only line the handbook gives is "dpkg-buildpackage -b -nc -uc" which builds literally eveything.

I only wanted to build binary-arch_amd64_none_amd64. So the only way listed was to use:

$ debian/rules source
$ DEB_RULES_REQUIRES_ROOT=no make -f debian/rules.gen binary-arch_amd64_none_amd64

So what I listed in my previous post is the only way I was able to fix the name and version so it didn't conflict.

How do I change the name and version of the built package the debian way?

[MrT]

Actually, I still am pretty sure this won't work because I am missing the kbuild package etc...

This is just too much trouble...

I ended up using this Makefile which creates a weirdly named kernel, but at least it works.

Code: Select all

build:
        mkdir -p debian
        cd debian && apt-get source linux/stable
        cd debian/linux-*/ && \
        DEBEMAIL="your.email.address@example.org" \
        DEBFULLNAME="Firstname Lastname" \
        DEB_BUILD_PROFILES='pkg.linux.nokerneldbg pkg.linux.nokerneldbginfo' \
        MAKEFLAGS=-j8 \
        ./debian/bin/test-patches -f amd64 ../../acs-5.10.patch

clean:
        rm -Rf debian

install:
        dpkg -i debian/linux-image-*-amd64-unsigned_*.deb debian/linux-headers-*-amd64_*.deb debian/linux-headers-*-common_*.deb debian/linux-kbuild-6.1_*.deb

[Aki]

Hello,

Since this thread is mainly intended by you to be about rebuilding the Debian kernel with an external patch, it would be useful to change the subject of the first post to something like:

Creating a custom Debian kernel package with an external patch

By the way, that's a "work in progress" sketch on how to do it "the Debian way":

• install required packages from Debian repositories

  Code: Select all

  su -l -c "apt install install build-essential devscripts quilt libtracefs-dev libtraceevent-dev wget"
  

• download the patch file (replace patch_url with the URL of the patch)

  Code: Select all

  wget patch_url
  

• download the source code for the current Linux kernel version used in the release of your Debian distribution

  Code: Select all

  # note: deb-src must be configured in /etc/apt/sources.list
  apt source linux

• change current directory to kernel's source code directory:

  Code: Select all

  # <package-directory> is the name of the directory of the downloaded source code for the linux kernel
  cd <package-directory>

• create the x509.genkey file required for a new custom kernel signing key (machine owner key=MOK) for UEFI boot.

  Code: Select all

  cp certs/default_x509.genkey certs/x509.genkey
  
  # Edit the following fields in certs/x509.genkey before proceeding:
  # 	O = Unspecified company
  # 	CN = Build time autogenerated kernel key
  # 	emailAddress = unspecified.user@unspecified.company
  

• test the patch applying it against the kernel source code

  Code: Select all

  # Test to see if the patch applies successfully, if it does not, stop here
  # and check the patch (replace "../custom.patch" with the file name 
  # of your patch in the parent directory)
  patch --dry-run -p1 < ../custom.patch
  

• if the patch applies successfully, add the patch to the Debian package patches series (in directory named ./debian/patches )

  Code: Select all

  # Configure quilt according to:
  # 	https://www.debian.org/doc/manuals/maint-guide/modify.en.html#quiltrc)
  #	https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/)
  dquilt push -a
  dquilt import -p 1 ../patch
  dquilt push
  dquilt pop -a
  while dquilt push; do dquilt refresh; done
  

• create a new changelog and a new package version for the new custom kernel packages

  Code: Select all

  dch -n

• rebuild kernel package

  Code: Select all

  # (see https://www.debian.org/doc/manuals/maint-guide/build.en.html )
  
  # for a complete rebuild
  # dpkg-buildpackage -us -uc
  
  # for a binary only rebuild
  # dpkg-buildpackage -b
  
  # for a fast binary rebuild
  fakeroot debian/rules binary-arch
  

Hope this helps.

[MrT]

Thank you. I will try it this way sometime later on. I have changed the topic of the thread.

[MrT]

1) I got this again:

This target is made to fail intentionally, to make sure
that it is NEVER run during the automated build. Please
ignore the following error, the debian/control file has
been generated SUCCESSFULLY.

So I did this before starting the build

Code: Select all

md5sum debian/control > debian/control.md5sum

2) The compile is ignoring my export MAKEFLAGS=-j8, so it takes many hours to compile

3) After waiting hours for this to finish it bombed with this error:

Code: Select all

sed: can't read modules.order: No such file or directory
make[3]: *** [/home/user1/debiankernel/linux-6.1.85/Makefile:1597: __modinst_pre] Error 2
make[3]: Leaving directory '/home/user1/debiankernel/linux-6.1.85/debian/build/build_amd64_none_amd64'
make[2]: *** [debian/rules.real:363: binary_image] Error 2
make[2]: Leaving directory '/home/user1/debiankernel/linux-6.1.85'
make[1]: *** [debian/rules.gen:64: binary-arch_amd64_none_amd64_real_image] Error 2
make[1]: Leaving directory '/home/user1/debiankernel/linux-6.1.85'
make: *** [debian/rules:56: binary-arch] Error 2

Other things:

It seems to be using far more space than it needs to??

Code: Select all

706M    build_amd64_none_amd64
660M    build_amd64_none_cloud-amd64
18G     build_amd64_rt_amd64

Maybe I just didn't notice it using this much space before, because the build was finishing so quickly and it was cleaning up after itself?