Peter Jones [Wed, 25 Sep 2019 10:16:18 +0000 (13:16 +0300)]
efi/tpm: Don't access event->count when it isn't mapped.
BugLink: https://bugs.launchpad.net/bugs/1845454
Some machines generate a lot of event log entries. When we're
iterating over them, the code removes the old mapping and adds a
new one, so once we cross the page boundary we're unmapping the page
with the count on it. Hilarity ensues.
This patch keeps the info from the header in local variables so we don't
need to access that page again or keep track of if it's mapped.
Fixes: 44038bc514a2 ("tpm: Abstract crypto agile event size calculations") Cc: linux-efi@vger.kernel.org Cc: linux-integrity@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Peter Jones <pjones@redhat.com> Tested-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Acked-by: Matthew Garrett <mjg59@google.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
(cherry picked from commit 512fb49c9e547f85c588d063cff8bbeb8fd6a643
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git) Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Debian] Don't use CROSS_COMPILE for i386 configs
BugLink: https://bugs.launchpad.net/bugs/1845714
Since i386 support is being removed in eoan, we will no longer
have cross toolchains to use when updating configs. Stop setting
CROSS_COMPILE for i386 so that the host toolchain will be used
instead.
UBUNTU: [Debian] Remove support for producing i386 kernels
BugLink: https://bugs.launchpad.net/bugs/1845714
i386 will not be a supported architecture in eoan, so drop i386
from our kernel packaging. However, we will still be building
i386 hwe kernel based on eoan, so we will keep the configs and
other bits required for i386 in place.
This causes an early udevadm trigger to fail. On some installer versions of
Ubuntu, this will cause init to exit, thus panicing the system very early
during boot.
Removing the bus_type from the parent device will remove some of the extra
empty files from /sys/devices/vio/, but will keep the rest of the layout for
vio devices, keeping them under /sys/devices/vio/.
It has been tested that uevents for vio devices don't change after this fix,
they still contain MODALIAS.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Jan Höppner [Fri, 27 Sep 2019 15:46:23 +0000 (16:46 +0100)]
UBUNTU: SAUCE: s390/dasd: Fix error handling during online processing
BugLink: https://bugs.launchpad.net/bugs/1845323
It is possible that the CCW commands for reading volume and extent pool
information are not supported, either by the storage server (for
dedicated DASDs) or by z/VM (for virtual devices, such as MDISKs).
As a command reject will occur in such a case, the current error
handling leads to a failing online processing and thus the DASD can't be
used at all.
Since the data being read is not essential for an fully operational
DASD, the error handling can be removed. Information about the failing
command is sent to the s390dbf debug feature.
Fixes: c729696bcf8b ("s390/dasd: Recognise data for ESE volumes") Cc: <stable@vger.kernel.org> # 5.3 Reported-by: Frank Heimes <frank.heimes@canonical.com> Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1845584
The memory region intel-lpss-pci uses has been declared as
write-combining
[ 0.001728] 5 base 4000000000 mask 6000000000 write-combining
This leads to the system hangs up during booting up.
Tuowen Zhao(ztuowen@gmail.com) provides a diff patch for intel-lpss
driver to claim to use un-cacheable memory while calling
__devm_ioremap(), and it works well. But it haven't been accepted by
maintainer yet.
To avoid the potential impact on other machines, I add a quirk to list
the machines which has the write-combining area in MTRR which overlaps
with the address that intel-lpss uses, only the machines in the list
pass the DEVM_IOREMAP_UC to __devm_ioremap().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203485 Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Paolo Pisati <paolo.pisati@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1845355
The only caller of hisi_zip_vf_q_assign() is hidden in an #ifdef,
so the function causes a warning when CONFIG_PCI_IOV is disabled:
drivers/crypto/hisilicon/zip/zip_main.c:740:12: error: unused function 'hisi_zip_vf_q_assign' [-Werror,-Wunused-function]
Replace the #ifdef with an IS_ENABLED() check that leads to the
function being dropped based on the configuration.
Fixes: 79e09f30eeba ("crypto: hisilicon - add SRIOV support for ZIP") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit bf6a7a5ad6fa69e48b735be75eeb90569d9584bb) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Reviewed-by: John Garry <john.garry@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit ad3f0a93b639c342abbe8982cc34a3370169c464) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Zhou Wang [Fri, 2 Aug 2019 07:57:55 +0000 (15:57 +0800)]
crypto: hisilicon - add debugfs for ZIP and QM
BugLink: https://bugs.launchpad.net/bugs/1845355
HiSilicon ZIP engine driver uses debugfs to provide debug information,
the usage can be found in /Documentation/ABI/testing/debugfs-hisi-zip.
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 72c7a68d2ea34803e9c4ef948261ec6744fc72fc) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 8201fdf49ff0950fa7a0c55a4aeb1ba3d747d404) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Zhou Wang [Fri, 2 Aug 2019 07:57:53 +0000 (15:57 +0800)]
crypto: hisilicon - add SRIOV support for ZIP
BugLink: https://bugs.launchpad.net/bugs/1845355
HiSilicon ZIP engine supports PCI SRIOV. This patch enable this feature.
User can enable VFs and pass through them to VM, same ZIP driver can work
in VM to provide ZLIB and GZIP algorithm by crypto acomp interface.
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 79e09f30eeba857b09832209bfc66bd689c58328) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Zhou Wang [Fri, 2 Aug 2019 07:57:52 +0000 (15:57 +0800)]
crypto: hisilicon - add HiSilicon ZIP accelerator support
BugLink: https://bugs.launchpad.net/bugs/1845355
The HiSilicon ZIP accelerator implements the zlib and gzip algorithm. It
uses Hisilicon QM as the interface to the CPU.
This patch provides PCIe driver to the accelerator and registers it to
crypto acomp interface. It also uses sgl as data input/output interface.
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Shiju Jose <shiju.jose@huawei.com> Signed-off-by: Kenneth Lee <liguozhu@hisilicon.com> Signed-off-by: Hao Fang <fanghao11@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: John Garry <john.garry@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 62c455ca853e3e352e465d66a6cc39f1f88caa60) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Zhou Wang [Fri, 2 Aug 2019 07:57:51 +0000 (15:57 +0800)]
crypto: hisilicon - add hardware SGL support
BugLink: https://bugs.launchpad.net/bugs/1845355
HiSilicon accelerators in Hip08 use same hardware scatterlist for data format.
We support it in this module.
Specific accelerator drivers can use hisi_acc_create_sgl_pool to allocate
hardware SGLs ahead. Then use hisi_acc_sg_buf_map_to_hw_sgl to get one
hardware SGL and pass related information to hardware SGL.
The DMA address of mapped hardware SGL can be passed to SGL src/dst field
in QM SQE.
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit dfed0098ab91f647b5720ab6f1e03b5b55139408) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1845355
QM is a general IP used by HiSilicon accelerators. It provides a general
PCIe interface for the CPU and the accelerator to share a group of queues.
A QM integrated in an accelerator provides queue management service.
Queues can be assigned to PF and VFs, and queues can be controlled by
unified mailboxes and doorbells. Specific task request are descripted by
specific description buffer, which will be controlled and pass to related
accelerator IP by QM.
This patch adds a QM driver used by the accelerator driver to access
the QM hardware.
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Kenneth Lee <liguozhu@hisilicon.com> Signed-off-by: Shiju Jose <shiju.jose@huawei.com> Signed-off-by: Hao Fang <fanghao11@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: John Garry <john.garry@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 263c9959c9376ec0217d6adc61222a53469eed3c) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Config] Build SafeSetID LSM but don't enable it by default
BugLink: https://launchpad.net/bugs/1845391
We can safely build the SafeSetID LSM while leaving it turned off by
default. It will be off by default due to CONFIG_LSM not containing
"safesetid" in our kernel configs. A security-minded system integrator
may want to make use of SafeSetID and can do so by enabling it with the
"lsm" kernel command-line parameter.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: John Johansen <john.johnansen@canonical.com> Acked-by: Steve Beattie <steve.beattie@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://launchpad.net/bugs/1845391
The first time a rule set is configured for SafeSetID, we shouldn't be
trying to release the previously configured ruleset, since there isn't
one. Currently, the pointer that would point to a previously configured
ruleset is uninitialized on first rule set configuration, leading to a
crash when we try to call release_ruleset with that pointer.
Acked-by: Jann Horn <jannh@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
(cherry picked from commit 21ab8580b383f27b7f59b84ac1699cb26d6c3d69) Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: John Johansen <john.johnansen@canonical.com> Acked-by: Steve Beattie <steve.beattie@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Mika Westerberg [Wed, 25 Sep 2019 10:06:01 +0000 (13:06 +0300)]
ACPI / property: Add two new Thunderbolt property GUIDs to the list
BugLink: http://bugs.launchpad.net/bugs/1844680
Ice Lake Thunderbolt controller includes two new device property
compatible properties that we need to be able to extract in the driver
so add them to the growing array of GUIDs.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit dfda204198848b47bdb98ab83b94dbb7c7692b55) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Mika Westerberg [Wed, 25 Sep 2019 10:06:00 +0000 (13:06 +0300)]
thunderbolt: Add support for Intel Ice Lake
BugLink: http://bugs.launchpad.net/bugs/1844680
The Thunderbolt controller is integrated into the Ice Lake CPU itself
and requires special flows to power it on and off using force power bit
in NHI VSEC registers. Runtime PM (RTD3) and Sx flows also differ from
the discrete solutions. Now the firmware notifies the driver whether
RTD3 entry or exit are possible. The driver is responsible of sending
Go2Sx command through link controller mailbox when system enters Sx
states (suspend-to-mem/disk). Rest of the ICM firwmare flows follow
Titan Ridge.
Signed-off-by: Raanan Avargil <raanan.avargil@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
(cherry picked from commit 3cdb9446a117d5d63af823bde6fe6babc312e77b) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Mika Westerberg [Wed, 25 Sep 2019 10:05:59 +0000 (13:05 +0300)]
thunderbolt: Expose active parts of NVM even if upgrade is not supported
BugLink: http://bugs.launchpad.net/bugs/1844680
Ice Lake Thunderbolt controller NVM firmware is part of the BIOS image
which means it is not writable through the DMA port anymore. However, we
can still read it so we can keep nvm_version and active parts of NVM.
This way users still can find out the active NVM version and other
potentially useful information directly from Linux.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
(cherry picked from commit 3f415e5ee18b0097755afc3ac3a5640b196a239e) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Mika Westerberg [Wed, 25 Sep 2019 10:05:58 +0000 (13:05 +0300)]
thunderbolt: Hide switch attributes that are not set
BugLink: http://bugs.launchpad.net/bugs/1844680
Thunderbolt host routers may not always contain DROM that includes
device identification information. This is mostly needed for Ice Lake
systems but some Falcon Ridge controllers on PCs also do not have DROM.
In that case hide the identification attributes.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
(cherry picked from commit 58f414fa435cf728a82f435bac4781da86afb623) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Mika Westerberg [Wed, 25 Sep 2019 10:05:57 +0000 (13:05 +0300)]
thunderbolt: Do not fail adding switch if some port is not implemented
BugLink: http://bugs.launchpad.net/bugs/1844680
There are two ways to mark a port as unimplemented. Typical way is to
return port type as TB_TYPE_INACTIVE when its config space is read.
Alternatively if the port is not physically present (such as ports 10
and 11 in ICL) reading from port config space returns
TB_CFG_ERROR_INVALID_CONFIG_SPACE instead. Currently the driver bails
out from adding the switch if it receives any error during port
inititialization which is wrong.
Handle this properly and just leave the port as TB_TYPE_INACTIVE before
continuing to the next port.
This also allows us to get rid of special casing for Light Ridge port 5
in eeprom.c.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
(cherry picked from commit d94dcbb10183f3b384c84e65724d2b753aa53c4d) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Mika Westerberg [Wed, 25 Sep 2019 10:05:56 +0000 (13:05 +0300)]
thunderbolt: Use 32-bit writes when writing ring producer/consumer
BugLink: http://bugs.launchpad.net/bugs/1844680
The register access should be using 32-bit reads/writes according to the
datasheet. With the previous generation hardware 16-bit writes have been
working but starting with ICL this is not the case anymore so fix
producer/consumer register update to use correct width register address.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
(cherry picked from commit 943795219d3cb9f8ce6ce51cad3ffe1f61e95c6b) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Mika Westerberg [Wed, 25 Sep 2019 10:05:55 +0000 (13:05 +0300)]
thunderbolt: Move NVM upgrade support flag to struct icm
BugLink: http://bugs.launchpad.net/bugs/1844680
This is depends on the controller and on the platform/CPU we are
running. Move it to struct icm so we can set it per controller.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com> Tested-by: Mario Limonciello <mario.limonciello@dell.com>
(cherry picked from commit f437c24bf694b0293f835dea8c25e3a5c1433d07) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Mika Westerberg [Wed, 25 Sep 2019 10:05:54 +0000 (13:05 +0300)]
thunderbolt: Correct path indices for PCIe tunnel
BugLink: http://bugs.launchpad.net/bugs/1844680
PCIe tunnel path indices got mixed up when we added support for tunnels
between switches that are not adjacent. This did not affect the
functionality as it is just an index but fix it now nevertheless to make
the code easier to understand.
Reported-by: Rajmohan Mani <rajmohan.mani@intel.com> Fixes: 8c7acaaf020f ("thunderbolt: Extend tunnel creation to more than 2 adjacent switches") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com>
(cherry picked from commit ce19f91eae43e39d5a1da55344756ab5a3c7e8d1) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reported-and-tested-by: Alexander Schmidt <alexs@linux.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit cf2c4a3f35b75d38cebb4afbd578f1594f068d1e) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1842774
New options from "s390: add support for IBM z15 machines." As per
smb's comments, these must be turned off to avoid breaking
compatibility with older hardware.
BugLink: https://bugs.launchpad.net/bugs/1842774
Add detection for machine types 0x8562 and 8x8561 and set the ELF platform
name to z15. Add the miscellaneous-instruction-extension 3 facility to
the list of facilities for z15.
And allow to generate code that only runs on a z15 machine.
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
(cherry picked from commit a0e2251132995b962281aa80ab54a9288f9e0b6b) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Sultan Alsawaf <sultan.alsawaf@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Despite extensive testing of commit 885bd765963b ("phy: qcom-qmp: Correct
READY_STATUS poll break condition") I failed to conclude that the
PHYSTATUS bit of the PCS_STATUS register used in PCIe and USB3 falls as
the PHY gets ready. Similar to the prior bug with UFS the code will
generally get past the check before the transition and thereby
"succeed".
Correct the name of the register used PCIe and USB3 PHYs, replace
mask_pcs_ready with a constant expression depending on the type of the
PHY and check for the appropriate ready state.
Cc: stable@vger.kernel.org Cc: Vivek Gautam <vivek.gautam@codeaurora.org> Cc: Evan Green <evgreen@chromium.org> Cc: Niklas Cassel <niklas.cassel@linaro.org> Reported-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Fixes: 885bd765963b ("phy: qcom-qmp: Correct READY_STATUS poll break condition") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Once upon a time, commit 2cac0c00a6cd ("ovl: get exclusive ownership on
upper/work dirs") in v4.13 added some sanity checks on overlayfs layers.
This change caused a docker regression. The root cause was mount leaks
by docker, which as far as I know, still exist.
To mitigate the regression, commit 85fdee1eef1a ("ovl: fix regression
caused by exclusive upper/work dir protection") in v4.14 turned the
mount errors into warnings for the default index=off configuration.
Recently, commit 146d62e5a586 ("ovl: detect overlapping layers") in
v5.2, re-introduced exclusive upper/work dir checks regardless of
index=off configuration.
This changes the status quo and mount leak related bug reports have
started to re-surface. Restore the status quo to fix the regressions.
To clarify, index=off does NOT relax overlapping layers check for this
ovelayfs mount. index=off only relaxes exclusive upper/work dir checks
with another overlayfs mount.
To cover the part of overlapping layers detection that used the
exclusive upper/work dir checks to detect overlap with self upper/work
dir, add a trap also on the work base dir.
Commit 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from
set_{pte,pmd,pud}") removed ISB instructions immediately following updates
to the page table, on the grounds that they are not required by the
architecture and a DSB alone is sufficient to ensure that subsequent data
accesses use the new translation:
DDI0487E_a, B2-128:
| ... no instruction that appears in program order after the DSB
| instruction can alter any state of the system or perform any part of
| its functionality until the DSB completes other than:
|
| * Being fetched from memory and decoded
| * Reading the general-purpose, SIMD and floating-point,
| Special-purpose, or System registers that are directly or indirectly
| read without causing side-effects.
However, the same document also states the following:
DDI0487E_a, B2-125:
| DMB and DSB instructions affect reads and writes to the memory system
| generated by Load/Store instructions and data or unified cache
| maintenance instructions being executed by the PE. Instruction fetches
| or accesses caused by a hardware translation table access are not
| explicit accesses.
which appears to claim that the DSB alone is insufficient. Unfortunately,
some CPU designers have followed the second clause above, whereas in Linux
we've been relying on the first. This means that our mapping sequence:
MOV X0, <valid pte>
STR X0, [Xptep] // Store new PTE to page table
DSB ISHST
LDR X1, [X2] // Translates using the new PTE
can actually raise a translation fault on the load instruction because the
translation can be performed speculatively before the page table update and
then marked as "faulting" by the CPU. For user PTEs, this is ok because we
can handle the spurious fault, but for kernel PTEs and intermediate table
entries this results in a panic().
Revert the offending commit to reintroduce the missing barriers.
Cc: <stable@vger.kernel.org> Fixes: 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}") Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
commit 1222a1601488 ("nl80211: Fix possible Spectre-v1 for CQM
RSSI thresholds") was incomplete and requires one more fix to
prevent accessing to rssi_thresholds[n] because user can control
rssi_thresholds[i] values to make i reach to n. For example,
rssi_thresholds = {-400, -300, -200, -100} when last is -34.
Cc: stable@vger.kernel.org Fixes: 1222a1601488 ("nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Masashi Honma <masashi.honma@gmail.com> Link: https://lore.kernel.org/r/20190908005653.17433-1-masashi.honma@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
When half-duplex RS485 communication is used, after RX is started, TX
tasklet still needs to be scheduled tasklet. This avoids console freezing
when more data is to be transmitted, if the serial communication is not
closed.
Fixes: 69646d7a3689 ("tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped") Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20190813074025.16218-1-razvan.stefanescu@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The sequence of arguments which was passed to handle_lsr_errors() didn't
match the parameters defined in that function, &lsr was passed to flag
and &flag was passed to lsr, this patch fixed that.
The VPD implementation from Chromium Vital Product Data project used to
parse data from untrusted input without checking if the meta data is
invalid or corrupted. For example, the size from decoded content may
be negative value, or larger than whole input buffer. Such invalid data
may cause buffer overflow.
To fix that, the size parameters passed to vpd_decode functions should
be changed to unsigned integer (u32) type, and the parsing of entry
header should be refactored so every size field is correctly verified
before starting to decode.
The first/last indexes are typically shared with a user app.
The app can change the 'last' index that the kernel uses
to store the next result. This change sanity checks the index
before using it for writing to a potentially arbitrary address.
This fixes CVE-2019-14821.
Cc: stable@vger.kernel.org Fixes: 5f94c1741bdc ("KVM: Add coalesced MMIO support (common part)") Signed-off-by: Matt Delco <delco@chromium.org> Signed-off-by: Jim Mattson <jmattson@google.com> Reported-by: syzbot+983c866c3dd6efa3662a@syzkaller.appspotmail.com
[Use READ_ONCE. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The DSA core, DSA taggers and DSA drivers all make use of
module_init(). Hence they get initialised at device_initcall() time.
The ordering is non-deterministic. It can be a DSA driver is bound to
a device before the needed tag driver has been initialised, resulting
in the message:
No tagger for this switch
Rather than have this be fatal, return -EPROBE_DEFER so that it is
tried again later once all the needed drivers have been loaded.
Fixes: d3b8c04988ca ("dsa: Add boilerplate helper to register DSA tag driver modules") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
When skb_shinfo(skb) is not able to cache extra fragment (that is,
skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS), xennet_fill_frags() assumes
the sk_buff_head list is already empty. As a result, cons is increased only
by 1 and returns to error handling path in xennet_poll().
However, if the sk_buff_head list is not empty, queue->rx.rsp_cons may be
set incorrectly. That is, queue->rx.rsp_cons would point to the rx ring
buffer entries whose queue->rx_skbs[i] and queue->grant_rx_ref[i] are
already cleared to NULL. This leads to NULL pointer access in the next
iteration to process rx ring buffer entries.
Below is how xennet_poll() does error handling. All remaining entries in
tmpq are accounted to queue->rx.rsp_cons without assuming how many
outstanding skbs are remained in the list.
985 static int xennet_poll(struct napi_struct *napi, int budget)
... ...
1032 if (unlikely(xennet_set_skb_gso(skb, gso))) {
1033 __skb_queue_head(&tmpq, skb);
1034 queue->rx.rsp_cons += skb_queue_len(&tmpq);
1035 goto err;
1036 }
It is better to always have the error handling in the same way.
Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags") Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UDP reuseport groups can hold a mix unconnected and connected sockets.
Ensure that connections only receive all traffic to their 4-tuple.
Fast reuseport returns on the first reuseport match on the assumption
that all matches are equal. Only if connections are present, return to
the previous behavior of scoring all sockets.
Record if connections are present and if so (1) treat such connected
sockets as an independent match from the group, (2) only return
2-tuple matches from reuseport and (3) do not return on the first
2-tuple reuseport match to allow for a higher scoring match later.
New field has_conns is set without locks. No other fields in the
bitmap are modified at runtime and the field is only ever set
unconditionally, so an RMW cannot miss a change.
Fixes: e32ea7e74727 ("soreuseport: fast reuseport UDP socket selection") Link: http://lkml.kernel.org/r/CA+FuTSfRP09aJNYRt04SS6qj22ViiOEWaWmLAwX0psk8-PGNxw@mail.gmail.com Signed-off-by: Willem de Bruijn <willemb@google.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Craig Gallek <kraig@google.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The test implemented by some_qdisc_is_busy() is somewhat loosy for
NOLOCK qdisc, as we may hit the following scenario:
CPU1 CPU2
// in net_tx_action()
clear_bit(__QDISC_STATE_SCHED...);
// in some_qdisc_is_busy()
val = (qdisc_is_running(q) ||
test_bit(__QDISC_STATE_SCHED,
&q->state));
// here val is 0 but...
qdisc_run(q)
// ... CPU1 is going to run the qdisc next
As a conseguence qdisc_run() in net_tx_action() can race with qdisc_reset()
in dev_qdisc_reset(). Such race is not possible for !NOLOCK qdisc as
both the above bit operations are under the root qdisc lock().
After commit 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue")
the race can cause use after free and/or null ptr dereference, but the root
cause is likely older.
This patch addresses the issue explicitly checking for deactivation under
the seqlock for NOLOCK qdisc, so that the qdisc_run() in the critical
scenario becomes a no-op.
Note that the enqueue() op can still execute concurrently with dev_qdisc_reset(),
but that is safe due to the skb_array() locking, and we can't avoid that
for NOLOCK qdiscs.
Fixes: 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue") Reported-by: Li Shuang <shuali@redhat.com> Reported-and-tested-by: Davide Caratti <dcaratti@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
In ip6erspan_tunnel_xmit(), if the skb will not be sent out, it has to
be freed on the tx_err path. Otherwise when deleting a netns, it would
cause dst/dev to leak, and dmesg shows:
unregister_netdevice: waiting for lo to become free. Usage count = 1
Fixes: ef7baf5e083c ("ip6_gre: add ip6 erspan collect_md mode") Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: William Tu <u9012063@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The hardware manual should be revised, but the initial value of
VBCTRL.OCCLREN is set to 1 actually. If the bit is set, the hardware
clears VBCTRL.VBOUT and ADPCTRL.DRVVBUS registers automatically
when the hardware detects over-current signal from a USB power switch.
However, since the hardware doesn't have any registers which
indicates over-current, the driver cannot handle it at all. So, if
"is_otg_channel" hardware detects over-current, since ADPCTRL.DRVVBUS
register is cleared automatically, the channel cannot be used after
that.
To resolve this behavior, this patch sets the VBCTRL.OCCLREN to 0
to keep ADPCTRL.DRVVBUS even if the "is_otg_channel" hardware
detects over-current. (We assume a USB power switch itself protects
over-current and turns the VBUS off.)
This patch is inspired by a BSP patch from Kazuya Mizuguchi.
Fixes: 1114e2d31731 ("phy: rcar-gen3-usb2: change the mode to OTG on the combined channel") Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The error occurs when the descriptors_changed() routine (called during
a device reset) attempts to compare the old and new BOS and capability
descriptors. The length it uses for the comparison is the
wTotalLength value stored in BOS descriptor, but this value is not
necessarily the same as the length actually allocated for the
descriptors. If it is larger the routine will call memcmp() with a
length that is too big, thus reading beyond the end of the allocated
region and leading to this fault.
The kernel reads the BOS descriptor twice: first to get the total
length of all the capability descriptors, and second to read it along
with all those other descriptors. A malicious (or very faulty) device
may send different values for the BOS descriptor fields each time.
The memory area will be allocated using the wTotalLength value read
the first time, but stored within it will be the value read the second
time.
To prevent this possibility from causing any errors, this patch
modifies the BOS descriptor after it has been read the second time:
It sets the wTotalLength field to the actual length of the descriptors
that were read in and validated. Then the memcpy() call, or any other
code using these descriptors, will be able to rely on wTotalLength
being valid.
UBUNTU: [Debian]: dkms-build: Move zfs special-casing into configure script
BugLink: https://bugs.launchpad.net/bugs/1840704
Rather than special-casing zfs in dkms-build, add support for
per-package configure hooks like we already do for post-install
hooks. Move the zfs-specific code into such a hook.
Suggested-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1840704
The regex to generate dkms_build_generic from dkms_build_specific
will return the same script name if the package name does not end
with a dash followed by digits. In this case the script will be
executed twice.
Fix this by returning an empty string if the regex does not match
and skipping execution if the dkms build script name is empty.
UBUNTU: [Debian]: dkms-build: zfs: support for debug symbols
BugLink: https://bugs.launchpad.net/bugs/1840704
Add support to enable debug symbols on ZFS in 'dkms-build',
and specify the debug package directory path in the rules.
It's a bit ugly that a change for a particular package is
in the generic build script, but unfortunately this seems
to be less intrusive than other options (eg, rely on file
in /etc/ which needs privileged permissions on build time;
or patch zfs-linux/dkms.conf to detect kernel build time.)
And it seemed short enough not to create 'pre processors'.
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Debian]: dkms-build: new parameter for debug package directory
BugLink: https://bugs.launchpad.net/bugs/1840704
Provide the 'dkms-build' script an argument that specifies
the path for installing modules built with debug symbols,
and update callers (currently just 'build_dkms' function)
and post-processor scripts for consistency (nvidia, vbox).
This is similar to the currently used package directory
argument 'pkgdir/lib/modules/abi-release/kernel', where
modules are installed anyway regardless of debug symbols.
The proposal is that the 'dkms-build' script, if provided
such argument, should handle the generation and stripping
of debug symbols, and installing the non-stripped modules
into the debug package directory and the stripped modules
into the other package directory (which is used currently).
The script double checks whether debug symbols are indeed
present in the module file (via the '.debug_info' section)
to avoid non-debug modules in the debug package directory,
with an additional benefit of backwards compatibility and
gracefully handling DKMS packages that do not yet support
building debug symbols (or that failed to for some reason).
The script should not handle the '.gnu_debuglink' section
to reference the non-stripped modules in stripped modules
(and re-signinig afterward), as this is now done in rules
after the DKMS modules have been built and installed.
This currently does nothing as no DKMS modules are built
with debug symbols (so this keeps the new argument empty).
This will allow for some of the DKMS-built modules to be
shipped with debug symbols to aid with debug and support.
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Debian]: Warn about modules without debug symbols
BugLink: https://bugs.launchpad.net/bugs/1840704
Print a warning message in the build log if a module does
not have a corresponding file in 'dbgpkgdir/usr/lib/debug'.
This should help to identify any modules without debug symbols,
which introduce additional complexity for their supportability.
In the future, it may be interesting to implement an stricter
check, to fail the build (obviously providing options to skip
the check and an exception list of modules that can bypass it).
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Debian]: Check/link modules with debug symbols after DKMS modules
BugLink: https://bugs.launchpad.net/bugs/1840704
Move the snippet that checks for existing debug symbol files
and then link/re-sign them, to after DKMS modules are built.
This provides the means to check the DKMS-built modules too.
Move just that snippet, not the whole 'ifneq skipdbg' snippet
because 'modules_install' does 'rm -rf lib/modules/.../kernel'
which would remove the modules just built/installed with DKMS.
For now, only move that code, no changes to it.
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Debian]: Handle debug symbols for modules in extras too
BugLink: https://bugs.launchpad.net/bugs/1840704
The debug symbols section only searches for modules in the
'$(pkgdir)' path (in linux-modules package) but not in the
'$(pkdir_ex)' path (in linux-modules-extra).
Thus, modules in the extras package have no '.gnu_debuglink'.
Fix it by searching in $(pkgdir_ex) too if extras is enabled.
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: [Debian]: Remove hardcoded $(pkgdir) in debug symbols handling
BugLink: https://bugs.launchpad.net/bugs/1840704
The 'find .ko | sed | while read module' loop has the $(pkgdir) path
hardcoded in a couple places to reconstruct the path 'sed' destroyed.
Remove that 'sed' expression to destroy the first components of the
absolute pathname and get its '/lib/modules/'-based path with shell.
This is needed for the next patch.
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Acked-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: Revert "UBUNTU: SAUCE: shiftfs: enable overlayfs on shiftfs"
BugLink: https://bugs.launchpad.net/bugs/1842382
This commit is causing the paths in /proc/self/maps to all show
up as / when proc is mounted over overlayfs in a chroot. Revert
the commit to fix the regression until a proper fix is found.
This keeps giving us problems with introducing unwanted binary
dependencies in linux-tools. These tools will work without these
dependencies, albeit with somewhat reduced functionality. Aside
from that I can't see that this dependency is needed, so let's
try removing it.
UBUNTU: [Packaging] Add lz4 build dependency for s390x
BugLink: https://bugs.launchpad.net/bugs/1840934
When switching s390x to use lz4 for compressing the kernel, the
build dependencies were not updated. Fix this.
This is no longer needed as zfs is build via the dkms build now.
I thought it had been deleted previously, but it's still there
for some reason, so let's get rid of it.
Lee Jones [Fri, 6 Sep 2019 09:38:16 +0000 (10:38 +0100)]
UBUNTU: SAUCE: i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630
We have a production-level laptop (Lenovo Yoga C630) which is exhibiting
a rather horrific bug. When I2C HID devices are being scanned for at
boot-time the QCom Geni based I2C (Serial Engine) attempts to use DMA.
When it does, the laptop reboots and the user never sees the OS.
Attempts are being made to debug the reason for the spontaneous reboot.
No luck so far, hence the requirement for this hot-fix. This workaround
will be removed once we have a viable fix.
Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
PCI: Restore Resizable BAR size bits correctly for 1MB BARs
BugLink: http://bugs.launchpad.net/bugs/1838751
In a Resizable BAR Control Register, bits 13:8 control the size of the BAR.
The encoded values of these bits are as follows (see PCIe r5.0, sec
7.8.6.3):
Previously we incorrectly set the BAR size bits for a 1 MB BAR to 0x1f
instead of 0, so devices that support that size, e.g., new megaraid_sas and
mpt3sas adapters, fail to initialize during resume from S3 sleep.
Correctly calculate the BAR size bits for Resizable BAR control registers.
Link: https://lore.kernel.org/r/20190725192552.24295-1-sumit.saxena@broadcom.com
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203939 Fixes: d3252ace0bc6 ("PCI: Restore resized BAR state on resume") Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org # v4.19+
(cherry-picked from d2182b2d4b71ff0549a07f414d921525fade707b linux-next) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: sched: Add __ASSEMBLY__ guards around struct clone_args
The addition of struct clone_args to uapi/linux/sched.h is not
protected by __ASSEMBLY__ guards, cuasing a FTBFS for glibc on
RISC-V. Add the guards to fix this.
BugLink: https://bugs.launchpad.net/bugs/1837726
Until 5.2 nvram support was built into the kernel for ppc64el.
Now it is a module and not included in the installer udebs, which
causes installation to fail. Change it back to =y for ppc64el to
fix this.
projects / mirror_ubuntu-eoan-kernel.git / log