debian/abi/powerpc-avoid-abi-change-for-disabling-tm.patch let us postpone an
ABI bump. But with the 4.19.81 upstream release, we can no longer avoid it.
This is a backport of v6 of the TAA patch set, and will probably
require updates before release. The subject lines for these patches
didn't come through.
We already have everything we need inside the kernel 4.19.x for
supporting this board. backporting patches from upstream so we get
the support for buster.
* 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>
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.
* Set a correct, specific Origin header for each patch, instead of a
repo URL and "cherry picked" message
* Add back Date header and Cc pseudo-headers for the second series
* Note which patches have been modified by Luca
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).
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.
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.
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.
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.
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
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