Matthew stopped maintaining the securelevel patch set, and David
Howells has taken it up under the new name 'lockdown'. This is
taken from:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git#efi-lock-down
commits ddb99e118e37f324a4be65a411bb60ae62795cf9..0240fa7c7c948b19d57c0163d57e55296277ff3c
Rebase the three patches not included there (cold boot mitigation,
arm64 SB integration, MTD RAM restrictions).
Update our kconfig for the renaming.
efi_get_secureboot() now returns one of three enumerated values, not
a boolean. We need to either redefine the DT property the same way
(risky unless we also rename it) or squash them into a boolean.
Do the latter.
Remove merged patches and rebase remaining patches.
A portion of the secureboot patches have been upstreamed, but were
changed substantially during review, primarily to avoid code
duplication among arches. I've stripped the patches of the merged
bits and rebased the remainder.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
[bwh: Undo some incorrect context changes in
bugfix/all/firmware-remove-redundant-log-messages-from-drivers.patch]
dak currently allows a binary upload to include debug symbol packages
that don't appear in the overrides file or the Binary field of the
changes file, so long as they have the appropriate
'Auto-Built-Package' field and their name matches another binary
package in the upload plus the '-dbgsym' suffix.
For architectures with code signing enabled, our binary uploads never
match this condition as the corresponding binary package has the
'-unsigned' suffix and the debug symbols package does not. Since we
do list the debug symbol packages in the Binary field, they do get
added to the overrides file when accepted through the NEW queue, but
they are automatically pruned from there some time later. Later
uploads then have to go through NEW even though they are not
introducing new binary packages. This would be a big problem for
stable security updates.
For now, move debug symbols back to the main archive with the old
'-dbg' suffix. Keep them enabled for all architectures.
ThunderX1 has 48 cores and supports 2-way systems for 96 CPUs.
ThunderX2 has 54 cores and also supports 2-way systems for 108 CPUs.
X-Gene 3 "Skylark" is supposed to support 8-way systems with 32
cores each for 256 CPUs (I'm not sure if they're cache-coherent
beyond 2-way though.
The CN7890 has 48 Octeon III cores.
I don't know whether current configuration will run on a CN7890, but this
should avoid an ABI break if we add support later.
The Loongson 3B2000 has 4 cores and can apparently be used in a 4-way
configuration, for 16 CPUs.
I don't think the current configuration will run on a 3B2000, but this
should avoid an ABI break if we address that.
This driver was removed in 3.18, but has been updated to use the new
target framework and was added again in 4.8.
As it lives under drivers/scsi and not drivers/target, exclude it from
the scsi-modules udeb.
Ben Hutchings
Aurelien Jarno
Lukas Wunner
Salvatore Bonaccorso