Bug#896165: ITP: bpftool -- utility for querying and updating BPF objects

[Christian Barcenas]

Control: reassign -1 wnpp
Control: notfound -1 linux/4.16.5-1
Control: affects -1 src:linux
Control: retitle ITP: bpftool -- utility for querying and updating BPF objects
Control: owner -1 !

Hi all, I'm restructuring this as an ITP.

I'm very keen to get bpftool in Debian as well, now that the copyright
concerns are resolved.

I'll work with the kernel team to get it packaged. Thanks Noah for all the
work so far.

Christian

--

* Package name: bpftool
  Version : 5.5.8
  Upstream Author : Various Linux kernel developers
* URL : https://www.kernel.org/
* License : GPL-2.0-only OR BSD-2-Clause
  Programming Lang: C
  Description : utility for querying and updating BPF objects

bpftool is a utility for querying and updating BPF objects on the system.

Packaging bpftool will improve the experience of developing and deploying
BPF-backed software on Debian systems.

bpftool is actively developed and is maintained as part of the upstream kernel.

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/bpf/bpftool

Therefore, the Debian kernel source package (src:linux) is a natural place for
the bpftool binary package.

Bug#945604: linux-source-5.4: Failed to build linux-source-5.4 in efi_set_secure_boot

[Christian Barcenas]

Control: tags -1 patch

The root cause is that lock_kernel_down() is unconditionally called
in efi_set_secure_boot, even if the kernel is compiled without
lockdown support (i.e. SECURITY_LOCKDOWN_LSM=n).

This build failure shouldn't affect the Debian official kernel
packages because the Kconfig default value is overridden
to enable lockdown support. However, if you use the Kconfig
defaults (e.g. when building via the linux-source package)
then you may encounter this error.

There is a flag LOCK_DOWN_IN_EFI_SECURE_BOOT (depending
on SECURITY_LOCKDOWN_LSM) that is currently ignored. It seems
like it was originally supposed to gate the lock_kernel_down call().

I've attached a patch to honor this flag again, which should fix this issue.
From de06de54508caf6bb1d3f25d4ef652d1360a43e0 Mon Sep 17 00:00:00 2001
From: Christian Barcenas 
Date: Mon, 17 Feb 2020 02:50:58 -0800
Subject: [PATCH] lockdown: honor LOCK_DOWN_IN_EFI_SECURE_BOOT

Previously LOCK_DOWN_IN_EFI_SECURE_BOOT was ignored;
lock_kernel_down() was always called during EFI Secure Boot.

Additionally this resolves a link-time error that occurs when
the kernel is built with EFI=y and SECURITY_LOCKDOWN_LSM=n.

Closes: #945604
---
 ...efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/patches/features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch b/debian/patches/features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
index e20fd562963c..7d7eada166d0 100644
--- a/debian/patches/features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
+++ b/debian/patches/features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
@@ -50,12 +50,14 @@ Signed-off-by: Ben Hutchings 
  
  /*
   * Decide what to do when UEFI secure boot mode is enabled.
-@@ -28,6 +29,8 @@ void __init efi_set_secure_boot(enum efi
+@@ -28,6 +29,10 @@ void __init efi_set_secure_boot(enum efi
  			break;
  		case efi_secureboot_mode_enabled:
  			set_bit(EFI_SECURE_BOOT, );
++#ifdef CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT
 +			lock_kernel_down("EFI Secure Boot",
 +	 LOCKDOWN_CONFIDENTIALITY_MAX);
++#endif
  			pr_info("Secure boot enabled\n");
  			break;
  		default:
-- 
2.25.0