Bug#1052304: Debian 6.1 Kernels suspect
On 2023-12-14 01:54, Bill MacAllister wrote: This took me longer that I wanted, but I have built kernels the following kernels with the patch: linux-image-6.1.0-15-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-amd64-unsigned_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-cloud-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-cloud-amd64-unsigned_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-rt-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-rt-amd64-unsigned_6.1.66-2~afs1_amd64.deb I have installed linux-image-6.1.0-15-amd64-unsigned_6.1.66-2~afs1_amd64.deb on a couple systems. Things look fine, but the problem is intermittent and I won't be convinced that it is fixed until there are no errors for at least a day. One of the systems uses kafs heavily so I should see any errors fairly quickly. I send an update tomorrow. This patch resolves this bug from my testing. The original bug was not intermittent, and the failure could be forced on demand. My reference to an intermittent problem was to another bug altogether---apologies for the confusion. Bill -- My heart is warm with the friends I make, And better friends I'll not be knowing, Yet there isn't a train I wouldn't take, No matter where it's going. Edna St Vincent Millay
Re: How to revoke Debian kernels for secure boot
On Thu, Dec 14, 2023 at 09:31:11PM +0100, Bastian Blank wrote: > On Thu, Dec 14, 2023 at 03:09:51PM +, Steve McIntyre wrote: > > It's a difficult thing to do, especially in light of significant > > pushback from upstream developers. Okay, I finally managed to read most of that thread. And it boils down to procedural problems, leading to no viable patch. Like the submitter not wanting to take replies seriously or even sending the patch to the correct maintainer in the first place. To specify a SBAT policy for upstream Linux, where people told the submitter several times that Linux is not interested in a secure boot policy, but such a policy needs to be defined by the signers, aka us. So we are free to specify "linux.debian" and attach our own policy to it. Or "linux-debian", so we can use "linux-debian.*" for internal things. Or so. Just curious: how to MOK and SBAT interact? Regards, Bastian -- If I can have honesty, it's easier to overlook mistakes. -- Kirk, "Space Seed", stardate 3141.9
Re: How to revoke Debian kernels for secure boot
On Thu, Dec 14, 2023 at 03:09:51PM +, Steve McIntyre wrote: > On Wed, Dec 13, 2023 at 10:18:40PM +, Dimitri John Ledkov wrote: > >There is no sbat for kernels yet (and/or nobody has yet started to use sbat > >for > >kernels). > It's a difficult thing to do, especially in light of significant > pushback from upstream developers. Well, if I read that correctly, that way mainly about policy. We have to define our own policy then, and then we can decide our own. The only problem would be that we have to carry the patch. Bastian -- Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant." -- Kirk, "The Ultimate Computer", stardate 4731.3
Re: How to revoke Debian kernels for secure boot
Hey all, On Wed, Dec 13, 2023 at 10:18:40PM +, Dimitri John Ledkov wrote: >At the moment the best options are: > >- rotate online signing key >- build new shim with old signing key in vendorx (revoked ESL) >- build new kernels with old signing key built-in revoked keyring > >This is to ensure that old shim & old kernel can boot or kexec new kernels. >To ensure new shim cannot boot old kernels. >To ensure that new kernels cannot kexec old kernels. Yes, this is roughly what I was thinking too. Thanks for explaining it well here. Something else we should *also* be doing is starting public documentation on what changes we've made to signing over time, tracking keys, revocations etc. so that: * users have a chance to understand what's changed and why * (being honest!) *developers* have a record so we can remember too I'm not sure the wiki is the best place for this, but I'm also not sure this should live on the main www.d.o either. Suggestions? >This is revocation strategy used by Canonical Kernel Team for Ubuntu Kernels. ACK, makes sense. >There is no sbat for kernels yet (and/or nobody has yet started to use sbat for >kernels). It's a difficult thing to do, especially in light of significant pushback from upstream developers. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Re: [arm64] secure boot breach via VFIO_NOIOMMU
On Thu, Dec 14, 2023 at 09:26:09AM +0100, Salvatore Bonaccorso wrote: >Hi, > >On Wed, Dec 13, 2023 at 10:45:01PM +0100, Bastian Blank wrote: >> Hi >> >> Over six years ago, support for VFIO without IOMMU was enabled for >> arm64. This is a breach of the integrity lockdown requirement of secure >> boot. >> >> VFIO is a framework for handle devices in userspace. To make >> this safe, an IOMMU is required by default. Without it, user space can >> write everywhere in memory. The code is still not conditional on >> lockdown, even if a patch was proposed. >> >> I intend to disable this option for all supported kernels. Definitely. >Agreed. > >For the readers reading this along, this was raised in context of >https://salsa.debian.org/kernel-team/linux/-/merge_requests/925#note_446730 >and >https://salsa.debian.org/kernel-team/linux/-/merge_requests/502#note_315464 > >The proposed patch felt probably trough the cracks. Nod. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Bug#1057967: linux-image-6.1.0-15-amd64: Fixed in 6.1.67-1
I can confirm that this issue is fixed in my Macbook Pro after upgrading to 6.1.67-1 from bookworm-proposed-updates. --- $ apt-cache policy linux-image-amd64 linux-image-amd64: Installed: 6.1.67-1 Candidate: 6.1.67-1 Version table: *** 6.1.67-1 500 500 http://httpredir.debian.org/debian bookworm-proposed-updates/main amd64 Packages 100 /var/lib/dpkg/status 6.1.66-1 500 500 http://httpredir.debian.org/debian bookworm/main amd64 Packages 6.1.52-1 500 500 http://security.debian.org/debian-security bookworm-security/main amd64 Packages --- # lspci -vvv 02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4331 802.11a/b/g/n (rev 02) ... Kernel driver in use: wl Kernel modules: bcma, wl --- # modinfo wl filename: /lib/modules/6.1.0-16-amd64/updates/dkms/wl.ko license:MIXED/Proprietary alias: pci:v*d*sv*sd*bc02sc80i* depends:cfg80211 retpoline: Y name: wl vermagic: 6.1.0-16-amd64 SMP preempt mod_unload modversions sig_id: PKCS#7 ... # Thanks.
Bug#1052304: Debian 6.1 Kernels suspect
On 2023-12-09 09:49, Bill MacAllister wrote: On 2023-12-08 15:59, Diederik de Haas wrote: On Saturday, 9 December 2023 00:28:50 CET Jeffrey Altman wrote: The bug is considered valid by upstream. A proposed fix for this issue is being reviewed. http://lists.infradead.org/pipermail/linux-afs/2023-December/007408.html Please leave this issue open until the fix has been back ported into the kernels shipped by Debian. https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4 describes a simple procedure with which one can test patches. I've attached the above referenced patch and verified that it applies (cleanly) onto a 6.1 kernel. Bill: can you test this patch and see if it resolved the issue? Yes, I can test it. Mostly likely I will not get to doing that until Sunday night here in California. For sure Monday morning at the latest. This took me longer that I wanted, but I have built kernels the following kernels with the patch: linux-image-6.1.0-15-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-amd64-unsigned_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-cloud-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-cloud-amd64-unsigned_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-rt-amd64-dbg_6.1.66-2~afs1_amd64.deb linux-image-6.1.0-15-rt-amd64-unsigned_6.1.66-2~afs1_amd64.deb I have installed linux-image-6.1.0-15-amd64-unsigned_6.1.66-2~afs1_amd64.deb on a couple systems. Things look fine, but the problem is intermittent and I won't be convinced that it is fixed until there are no errors for at least a day. One of the systems uses kafs heavily so I should see any errors fairly quickly. I send an update tomorrow. Bill -- My heart is warm with the friends I make, And better friends I'll not be knowing, Yet there isn't a train I wouldn't take, No matter where it's going. Edna St Vincent Millay
Bug#1056056: linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640
Hi Ben,
On Thu, Dec 14, 2023 at 09:16:48AM +, Ben Mesman | Spark Narrowcasting
wrote:
> The attached patch works on my systems. Is there a way to get this in?
> --- arch/x86/kernel/reboot.c.orig 2023-12-14 08:25:10.033382061 +0100
> +++ arch/x86/kernel/reboot.c 2023-12-14 08:31:10.394325941 +0100
> @@ -469,6 +469,14 @@
> DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq"),
> },
> },
> + { /* Handle problems with rebooting HP t640 thin-clients */
> + .callback = set_pci_reboot,
> + .ident = "HP t640",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "HP"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP t640 Thin Client"),
> + },
> + },
>
> { /* PCIe Wifi card isn't detected after reboot otherwise */
> .callback = set_pci_reboot,
We cannot pick changes which are not going to land in Linux upstream
and then backported to the stable series. So the way to go here is to
report the bug upstream, along with your proposed change. Candidates
to reach out are:
./scripts/get_maintainer.pl arch/x86/kernel/reboot.c
Thomas Gleixner (maintainer:X86 ARCHITECTURE (32-BIT AND
64-BIT),commit_signer:2/11=18%)
Ingo Molnar (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
Borislav Petkov (maintainer:X86 ARCHITECTURE (32-BIT AND
64-BIT))
Dave Hansen (maintainer:X86 ARCHITECTURE (32-BIT
AND 64-BIT))
x...@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
"H. Peter Anvin" (reviewer:X86 ARCHITECTURE (32-BIT AND
64-BIT))
Sean Christopherson
(commit_signer:10/11=91%,authored:10/11=91%,added_lines:176/177=99%,removed_lines:102/103=99%)
Kai Huang (commit_signer:7/11=64%)
Josh Poimboeuf (commit_signer:1/11=9%,authored:1/11=9%)
"Peter Zijlstra (Intel)" (commit_signer:1/11=9%)
linux-ker...@vger.kernel.org (open list:X86 ARCHITECTURE (32-BIT AND 64-BIT))
as it is affecting 6.1.y mention that the fix needs to be backported to various
stable series at least back 6.1.y and describe which testing you have
performed.
Feel free to keep as well the Debian bug in the loop for the report.
Hope this helps?
Regards,
Salvatore
Bug#1057967: fixed in linux 6.1.67-1
Hereby I confirm that linux-image-6.1.0-16-amd64 (6.1.67-1) from bookworm-proposed-updates fixed the problems for me. Regards Stephan signature.asc Description: This is a digitally signed message part
Bug#1056056: linux-image-6.1.0-13-amd64: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640
The attached patch works on my systems. Is there a way to get this in?
--- arch/x86/kernel/reboot.c.orig 2023-12-14 08:25:10.033382061 +0100
+++ arch/x86/kernel/reboot.c 2023-12-14 08:31:10.394325941 +0100
@@ -469,6 +469,14 @@
DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq"),
},
},
+ { /* Handle problems with rebooting HP t640 thin-clients */
+ .callback = set_pci_reboot,
+ .ident = "HP t640",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP t640 Thin Client"),
+ },
+ },
{ /* PCIe Wifi card isn't detected after reboot otherwise */
.callback = set_pci_reboot,
Re: How to revoke Debian kernels for secure boot
On Wed, Dec 13, 2023 at 10:18:40PM +, Dimitri John Ledkov wrote: > At the moment the best options are: > > - rotate online signing key > - build new shim with old signing key in vendorx (revoked ESL) > - build new kernels with old signing key built-in revoked keyring > > This is to ensure that old shim & old kernel can boot or kexec new kernels. > To ensure new shim cannot boot old kernels. > To ensure that new kernels cannot kexec old kernels. > > This is revocation strategy used by Canonical Kernel Team for Ubuntu > Kernels. > > There is no sbat for kernels yet (and/or nobody has yet started to use sbat > for kernels). Reading this summary also made me realize that if we do SBAT for kernels and want to rely it, we also need to make kernels *check* SBAT so that it is respected at kexec. This can be done two ways: - You do an SBAT self-check at startup to see if you are revoked yourself, which is what shim does - You check the SBAT of the kernel you are about to kexec I'd generally prefer the self-check I think because that also applies if you boot kernels via UEFI directly or something. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Re: [arm64] secure boot breach via VFIO_NOIOMMU
Hi, On Wed, Dec 13, 2023 at 10:45:01PM +0100, Bastian Blank wrote: > Hi > > Over six years ago, support for VFIO without IOMMU was enabled for > arm64. This is a breach of the integrity lockdown requirement of secure > boot. > > VFIO is a framework for handle devices in userspace. To make > this safe, an IOMMU is required by default. Without it, user space can > write everywhere in memory. The code is still not conditional on > lockdown, even if a patch was proposed. > > I intend to disable this option for all supported kernels. Agreed. For the readers reading this along, this was raised in context of https://salsa.debian.org/kernel-team/linux/-/merge_requests/925#note_446730 and https://salsa.debian.org/kernel-team/linux/-/merge_requests/502#note_315464 The proposed patch felt probably trough the cracks. Regards, Salvatore
