* Drop patches which have been applied to 4.19-stable
* Drop "Revert "net: stmmac: Send TSO packets always from Queue 0"" in
favour of upstream fix "net: stmmac: Re-work the queue selection for
TSO packets"
* Refresh patches that became fuzzy
* Accept revert of "[sh4]: Check for kprobe trap number before trying
to handle a kprobe trap" and update debian/changelog accordingly, as
sh4 is not a release architecture
* Keep "[arm64] Improve support for the Huawei TaiShan server platform"
which was reverted on the buster-security branch
This retrieves the patch from the linux-4.19.y branch and refreshes the
previous one "floppy: fix out-of-bounds read in copy_buffer", because
this is firstly "floppy: fix div-by-zero in setup_format_params" that is
applied upstream, then the one regarding out-of-bounds read in copy_buffer.
The one for CVE-2019-14283 was previously refreshed because it was not
applicable directly. Now both patches are synchronized with upstream and
applied in the same order.
We need to be based onto 4.19.37-5+deb10u1, and only include security
related topics. Things or improvements added to 4.19.37-6 (that is
already in sid) should be removed because they should not be uploaded
to buster-security accidentaly.
Closes: #930554
Enable the HNS/ROCE Infiniband driver
Backport fixes from 4.20 and 4.21 for HNS3 networking, hisi_sas SAS
and HNS/ROCE Infiniband
Signed-off-by: Steve McIntyre <93sam@debian.org>
On Samsung Chromebook Plus (v1) trying to boot from a rootfs on a USB
storage device without these modules in the initramfs, it drops to an
initramfs shell with a non-working display. For the d-i netboot image,
the screen doesn't turn on, but the installer menu works.
A recent change to initramfs-tools includes extcon-usbc-cros-ec, so
include that and a relevant PHY module here as well.
Relevant:
https://salsa.debian.org/kernel-team/initramfs-tools/commit/994d698a
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
On some ChromeOS devices, this is required to connect to a wireless
network via mwifiex_pcie.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The cros_ec multifunction device provides the keyboard services on some
ChromeOS devices, but requires a bus to be enabled to communicate with
it. On Samsung Chromebook Plus (v1), including spi-rockchip and
cros_ec_spi are enough. A recent change in initramfs-tools included all
SPI drivers, so include them here as well.
Relevant:
https://salsa.debian.org/kernel-team/initramfs-tools/commit/797e5fed
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Some important modules like cros_ec_keyb are in input/keyboard. A recent
change in initramfs-tools also includes them, so include them here too.
Relevant:
https://salsa.debian.org/kernel-team/initramfs-tools/commit/40f66474
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Debian policy says the package name must change when the soname
changes. We don't expect the ABI to change in a stable update,
so use only 2 components in both.
It's not necessary to delete the definitions of the variables that
become unused. Nor is it necessary to move the definition of
LIBBPF_VERSION before LIB_FILES, because the latter is defined
as recursively expanded (i.e. its variable references are not
immediately expanded).
This makes the actual change we're making clearer, and should
reduce the future work to maintain this patch.
Import patches from:
https://lore.kernel.org/patchwork/cover/933178/
that allow to also load dbx and MOKX as blacklists for modules.
These patches also disable loading MOK/MOKX when secure boot is
not enabled, as the variables will not be safe, and to check the
variables attributes before accepting them.
Import patches from:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-uefi
that enable a new option that automatically loads keys from db
and MOK into the secondary keyring, so that they can be used to
verify the signature of kernel modules. Enable the required KCONFIGs.
Allows users to self-sign modules (eg: dkms).
With this option enabled, the kernel will be able to retrieve firmware
logs by looking in the coreboot table. This can be accessed from
userspace via the sysfs file /sys/firmware/log.
Requested by John Paul Adrian Glaubitz, with the explanation:
> GRUB doesn't really support compressed kernels with OpenFirmware, at
> least on SPARC. It used to work with 2.02+patches but it doesn't
> work with GRUB 2.04~rc1 and upstream said that it's not really
> supported.
The "recommends" field set in the [image] section for these
configurations overrode the field at the top level. We want
gencontrol.py to concatenate the relations in this section at all
levels.
The ConfigCore.get_merge method supports doing this, but only with
list fields So we need to specify in the config schema that these
fields are comma-separated lists.
We were building the omap-rng driver, because the same block is used
on some recent Marvell chips and HW_RANDOM_OMAP is enabled by default
if ARCH_MVEBU is enabled.
We were also building virtio-rng, but there isn't (so far as I know)
any publicly available emulation of the ARMv5 Marvell chips.
As we're about to include HWRNG drivers to the installer, disable the
whole subsystem for armel/marvell to avoid adding useless drivers.
Closes: #785065
This finally removes the need for the ppc64el compiler to support
32-bit code generation, and removes a useless file from debug
packages on ppc64el.
Since we don't use the Release and Packages files to verify the
packages we download, it's worth using TLS to reduce the risk of
a man-in-the-middle corrupting them.
ftp.ports.debian.org and security.debian.org don't support TLS
in general, so use deb.debian.org for the ports and security
archives.
If the changelog distribution is *-security, fetch from the security
archive. Otherwise, try the main archive, ports, incoming, and
incoming.ports in that order.
It appears to be technically possible to use PCMCIA cards on POWER8/9
systems through a PCI Express to PCI adapter and a PCI to
PCMCIA/CardBus adapter. But I can't believe anyone would want to.
So rather than adding a pcmcia-modules package or excluding the
drivers from udebs, disable PCMCIA altogether.
Module loading needs the issuer certificate to validate the signature,
and that certificate is not embedded in the signature itself.
For now embed both the signing certificate and the root CA.
This workaround is no longer needed for Debian's OpenJDK packages:
* OpenJDK 7 is unfixed (bug #876068) but is not present in stretch or
later suites
* OpenJDK 8 was fixed in unstable (bug #876051) and the fix was then
included in a stretch security update
* OpenJDK 9 and later were fixed (bug #876069)
The workaround was never applied upstream and it also doesn't seem
like a good idea to have a Debian-specific VM quirk that weakens the
defence against Stack Clash. Therefore drop it now rather than
including it in another release.
With this option set, module text and rodata memory areas will be made
read-only. Moreover, non-text memory will be made non-executable. This
provides protection against certain security exploits. Currently, this
option is implicitly enabled in Kconfig for most configurations where it
is possible to enable it. This commit enables the option by default
explictly for all supported targets (except marvell to keep it small)
When set, this generates crash dump after being started by kexec. Useful
for debugging purpose on ARM. As this is already enabled for other arch,
enable it for ARM, as well (except marvell to keep it small).
Nowadays, Raspberry Pi 2 and Rasberry Pi 3 works perfectly fine with
Debian (including the official kernel package or the userland). RPi 1
and RPi Zero have an SoC that contains an armv6-based CPU, this means
that it cannot work with an hardfloat ABI, that is armv7 based. So we
have to use the Debian armel userland for this reason. Both boards are
supported in the mainline linux kernel and not being supported in the
debian-kernel package is the only blocking point that prevent RPI 1 and
RPI Zero from being well supported in an official Debian distribution.
This commit add a new kernel flavour for enabling support for the both
platforms.
It is no longer possible to run the "setup" rules without a compiler,
because Kconfig symbols can depend on compiler properties. Add a way
to invoke just the first step of setup, which merges the kconfig files
and overrides together.
The lockdown code for arm64 currently fails to engage when in Secure Boot
mode. Seth Forshee noticed that this is because init_lockdown() checks
for efi_enabled(EFI_BOOT), but that bit doesn't get set until uefi_init()
is called.
These modules will end up in every installer build, one way or
another. Move them into kernel-image, which all other packages
depend on, so we can then split up the remaining PV drivers.
The previous version failed to build on alpha:
debian/virtio-modules-4.19.0-3-alpha-generic-di lib/modules/4.19.0-3-alpha-generic/kernel/drivers/i2c/i2c-core.ko
debian/i2c-modules-4.19.0-3-alpha-generic-di lib/modules/4.19.0-3-alpha-generic/kernel/drivers/i2c/i2c-core.ko
and sparc64:
debian/virtio-modules-4.19.0-3-sparc64-di lib/modules/4.19.0-3-sparc64/kernel/drivers/i2c/i2c-core.ko
debian/nic-modules-4.19.0-3-sparc64-di lib/modules/4.19.0-3-sparc64/kernel/drivers/i2c/i2c-core.ko
sparc64 was missing a i2c-modules package, but adding that just gets
it to the same state as alpha. On both architectures drm_kms_helper
is included in the virtio-modules package as a dependency of
virtio-gpu, and then i2c-core is included as a dependency of
drm_kms_helper.
I don't think it makes sense to make virtio-modules directly depend on
i2c-modules. (In fact I think virtio-modules was a mistake entirely.)
Instead, for all configurations that enable both DRM and virtio:
1. Add an fb-modules package if it doesn't already exist
2. Include drm and drm_kms_helper in it
Enabling this symbol makes rmi4_core depend on the media/v4l2
subsystem which is not only weird but also results in duplicate
modules at kernel-wedge time.
These drivers depend on the corresponding net drivers, or at least
common modules built under drivers/net/ethernet, currently leading
to duplicate modules.
I don't want to resolve this by adding a dependency between
nic-modules and scsi-modules, as that would pull in both into
installer images that previously only needed one set of drivers. I
also don't want to add the common modules into kernel-image as that
would bloat all installer images. Instead, put the drivers in a new
package and we can work out which installer images should include it
later.
Build scsi-nic-modules for all architectures/flavours that build
scsi-modules using the common module list now.
Part of the section we move was moved upstream in 4.19.15 by commit
ae206a1a5e3a "kbuild: fix false positive warning/error about missing
libelf". Don't duplicate that section.
This will allow to get graphics support in VM instances right from
Debian installer phase.
(cherry picked from commit fb11c71e7c36b2e9abb7535e6c9c0ddbb8dc7c15)
While pycodestyle and pyflakes wrongly write error messages to stdout,
the unittest module has the opposite bug: it writes successful status
messages to stderr.
In order to access Azure's VMbus via /sys/vmbus, the corresponding
UIO module must be available.
Also enable VFIO for safe userspace device handling when the host
exposes a vIOMMU.
We use the default compiler provided by (cross-)build-essential for
userland, so the compiler build-dependencies are not needed when
the pkg.linux.nokernel profile is used.
Since commit f5f169ba99 "Split build rules for tools to allow
skipping them." these recursive makefiles are not used.
(debian/rules.d/Makefile can additionally install the top-level Kbuild
and Makefile, but that target hasn't been used since svn rev 18133
(version 3.1-1~experimental.1).)
Since commit f5f169ba99 "Split build rules for tools to allow
skipping them." debian/rules.d/Makefile is not used and the current
kernel's UAPI headers are not installed. This hasn't caused breakage
yet, probably because many tools have their own workaround using
include/uapi etc. directly, but could break backports builds at some
point.
Move the build of userland headers up into debian/rules.real and
make all tools build targets depend on it.
With the recent refactor, setting source: false in debian/config/defines
is no longer enough to disable the linux-source-$ver package build, as
dh_listpackages is used to determine what is built.
Do not add linux-source-$ver to d/control if it is disabled.
Some new Loongson servers are using Aspeed BMC, which has an GPU.
Some other Loongson servers are using SM750 GPU instead of AMD's.
Since MIPS doesn't have a generic display driver like VESA, we need
to install sm750fb and (drm_)ast into Loongson's fb-moduels udeb package.
(cherry picked from commit 6fbe9f4e363b32a70adf391e6d74ae21c52f16b6)
The packages we should build are restricted by:
* Package configuration in debian/config (limits which binary packages are
included in debian/control)
* Architecture (specified per package in debian/templates/control.* and
then in debian/control)
* Build profile (specified per package in debian/templates/control.* and
then in debian/control)
The logic for these restrictions is currently repeated in
debian/rules.real, but sometimes it becomes inconsistent with
debian/control (as with my recent changes for libbpf).
dh_listpackages reads debian/control and filters it by the current
host architecture and build profiles, so that it reliably reports
which packages we should build.
Therefore:
* Replace the logic in debian/rules.real with checks for package names
in the output of dh_listpackages
* Remove the redundant flag variables passed by debian/rules and
debian/rules.gen
* Remove the special-casing of stage1 in debian/rules and
debian/rules.gen
Drop iomap-Revert-fs-iomap.c-get-put-the-page-in-iomap_pa.patch
Drop usb-hso-fix-oob-memory-access-in-hso_probe-hso_get_config_data.patch
Add bug closer for #917569
Cleanup debian/changelog file
Python 3.7 warns:
.../debian/lib/python/debian_linux/debian.py:403: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
class PackageArchitecture(collections.MutableSet):
On powerpc architectures that may use a bootwrapper, we create a
temporary build_<arch>_<featureset>_<flavour>_bootwrapper directory
for each kernel configuration to hold the related tools which we won't
install for real (because they are always native).
This directory is then matched by the wildcard used in building
linux-config, causing linux-config packages to contain spurious
(empty) kconfig files based on these directories in addition to the
real kconfig files.
Rename the temporary directory to avoid matching that wildcard.
In unstable, linux-image-*-unsigned packages and any corresponding
metapackage updates tend to be available a few hours before the
corresponding signed packages. An automatic upgrade with aptitude (at
least) may then install the unsigned kernel where a signed kernel
was previously used, resulting in boot failure.
I gave the linux-image-*-unsigned packages a Provides relation to the
unsuffixed (i.e. signed) package name because I thought packages built
by module-assistant generally depended on the corresponding kernel
package. That may have been true once but doesn't appear to be so
now.
So the Provides field can be harmful and doesn't appear to be useful,
and should be removed.
The current check has never worked because the find -path predicate
matches against the whole path, including the given root. In this
case that is $DESTDIR which always includes the version string.
Change to use cd before find.
Also, check all non-directories rather than all entries with "perf" in
the name.
Backport Amazon ENA ethernet driver version 2.0.2 from Linux 4.20
This mostly ammounts to cherry-picking the commits in the range described by
git log v4.19.5..v4.20-rc7 drivers/net/ethernet/amazon
Change e641e99f261f5203a911a9e0db54a214460d2cc4 introduced changes outside the
ena directory, but only removed a redundant #include and was trivial to scope
down.
Upstream dealt with merge conflicts in
d864991b220b7c62e81d21209e1fd978fd67352c; the resolution here was identical to
upstream.
tl;dr: Xen PVH is the perfect upgrade path from PV and in combination
with grub2 support, it's the Xen "killer feature" we really should have
in Buster.
Background info about Xen PVH:
https://wiki.xen.org/wiki/Virtualization_Spectrum#Almost_fully_PV:_PVH_mode
PVH mode in Xen, a.k.a. "HVM without having to run qemu" is a Xen guest
type best supported since Xen 4.11 and Linux kernel 4.17. Just like when
using PV mode, the guest does not have an emulated BIOS and the guest
kernel is directly started by the dom0. Buster will ship with Xen 4.11.
Why is PVH interesting?
1. When the whole Meltdown/Spectre story started, it quickly became
apparent that 64-bit PV is the most problematic virtualization mode to
protect and to protect from, since address space from the hypervisor and
other guests (including dom0) is reachable from a 64-bit PV domU. To
mitigate this, XPTI (the Xen variant of PTI) has been implemented in the
hypervisor, but with a performance hit. HVM (so, also PVH) guests are
better isolated from the hypervisor and other guests. Inside the guest a
choice can be made about which mitigations to enable or not. Also see
https://xenbits.xen.org/xsa/advisory-254.html
2. Unlike HVM, it's not needed to have a boot loader/sector, partitions,
and a qemu process in the dom0 (using cpu and memory and having an
attack surface). Also, when running a largeish amount of domUs on a
physical server, not having all the qemu processes is an advantage.
3. Unlike PV, PVH makes use of all hardware features that accelerate
virtualization.
The upgrade path from PV to PVH is super optimal. It's just setting
type='pvh' in the guest file and doing a full restart of the domU!
Unless... (insert Monty Python's Dramatic Chord!)
Unless... grub2 was used to boot the PV guests.
Why is it interesting to be able to use grub?
Without using grub in between, the guest kernel and initrd have to be
copied out of the guest onto the dom0 filesystem, because the guest has
to be booted with them directly. Currently, we already have the
grub-xen packages in Debian, which provide grub images which can be used
as kernel for a PV guest, after which it can load the actual linux
kernel that is symlinked from /vmlinuz on the guest filesystem at that
moment.
The final changes to the Linux kernel for grub+PVH are in Linux 4.20.
This request, to carry a few patches from Linux 4.20, provides one half
of the dots that need to be connected to make the full thing happen for
Buster.
Since we'll have Xen 4.11 in Buster, PVH is supported. The related grub2
patchset was committed to the grub master branch on Dec 12 2018 (yup,
today). So, I'll also start contacting the debian grub team soon to ask
(and help) to get the current grub-xen functionality in Debian to be
extended with PVH capabilities as well.
Test reports:
https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01913.htmlhttps://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03312.html
Salvatore Bonaccorso
Romain Perier
Cyril Brulebois
Ben Hutchings
Romain Perier
Romain Perier
Aurelien Jarno
Uwe Kleine-König
John Paul Adrian Glaubitz
Steve McIntyre
Alper Nebi Yasak
Vagrant Cascadian
Luca Boccassi
Bastian Blank
YunQiang Su
Stefan Fritsch
Yves-Alexis Perez
Marcin Juszkiewicz
dann frazier
Wookey
Hideki Yamane
Uwe Kleine-König
Luigi Baldoni
YunQiang Su
Michal Simek
Noah Meyerhans
Hans van Kranenburg