The function dma_set_mask() in setup_hw() can fail, so its return value
should be checked.
Fixes: 1700fe1a10dc ("Add mISDN HFC PCI driver") Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
When vp_vdpa driver is unbind, vp_vdpa is freed in vdpa_unregister_device
and then vp_vdpa->mdev.pci_dev is dereferenced in vp_modern_remove,
triggering use-after-free.
Signed-off-by: Zhang Min <zhang.min9@zte.com.cn> Signed-off-by: Yi Wang <wang.yi59@zte.com.cn> Link: https://lore.kernel.org/r/20220301091059.46869-1-wang.yi59@zte.com.cn Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Fixes: 64b9f64f80a6 ("vdpa: introduce virtio pci driver") Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Currently the value of max_discard_segment will be set to
MAX_DISCARD_SEGMENTS (256) with no basis in hardware if device
set 0 to max_discard_seg in configuration space. It's incorrect
since the device might not be able to handle such large descriptors.
To fix it, let's follow max_segments restrictions in this case.
Fixes: 1f23816b8eb8 ("virtio_blk: add discard and write zeroes support") Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Link: https://lore.kernel.org/r/20220304100058.116-1-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when
start is 0 and last is ULONG_MAX. One instance where it can happen
is when userspace sends an IOTLB message with iova=size=uaddr=0
(vhost_process_iotlb_msg). So, an entry with size = 0, start = 0,
last = ULONG_MAX ends up in the iotlb. Next time a packet is sent,
iotlb_access_ok() loops indefinitely due to that erroneous entry.
Reported by syzbot at:
https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87
To fix this, do two things:
1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map
a range with size 0.
2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX]
by splitting it into two entries.
Fixes: 0bbe30668d89e ("vhost: factor out IOTLB") Reported-by: syzbot+0abd373e2e50d704db87@syzkaller.appspotmail.com Tested-by: syzbot+0abd373e2e50d704db87@syzkaller.appspotmail.com Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com> Link: https://lore.kernel.org/r/20220305095525.5145-1-mail@anirudhrb.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
dsp_pipeline_build() allocates dup pointer by kstrdup(cfg),
but then it updates dup variable by strsep(&dup, "|").
As a result when it calls kfree(dup), the dup variable contains NULL.
Found by Linux Driver Verification project (linuxtesting.org) with SVACE.
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Fixes: 960366cf8dbb ("Add mISDN DSP") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
This PHY doesn't support a link-up interrupt source. If aneg is enabled
we use the "aneg complete" interrupt for this purpose, but if aneg is
disabled link-up isn't signaled currently.
According to a vendor driver there's an additional "energy detect"
interrupt source that can be used to signal link-up if aneg is disabled.
We can safely ignore this interrupt source if aneg is enabled.
This patch was tested on a TX3 Mini TV box with S905W (even though
boot message says it's a S905D).
This issue has been existing longer, but due to changes in phylib and
the driver the patch applies only from the commit marked as fixed.
Fixes: 84c8f773d2dc ("net: phy: meson-gxl: remove the use of .ack_callback()") Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/04cac530-ea1b-850e-6cfa-144a55c4d75d@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
drivers/vdpa/vdpa_user/iova_domain.c:305 vduse_domain_alloc_iova() warn: should 'iova_pfn << shift' be a 64 bit type?
Fixes: 8c773d53fb7b ("vduse: Implement an MMU-based software IOTLB") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Link: https://lore.kernel.org/r/20220121083940.102-1-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
When control vq receives a VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command
request from the driver, presently there is no validation against the
number of queue pairs to configure, or even if multiqueue had been
negotiated or not is unverified. This may lead to kernel panic due to
uninitialized resource for the queues were there any bogus request
sent down by untrusted driver. Tie up the loose ends there.
Fixes: 52893733f2c5 ("vdpa/mlx5: Add multiqueue support") Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com> Link: https://lore.kernel.org/r/1642206481-30721-4-git-send-email-si-wei.liu@oracle.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eli Cohen <elic@nvidia.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
The node in question is receiving activate messages in another
thread after changing bearer status to allow message sending/
receiving in current thread:
Monitoring pointer in thread 2 is dereferenced before monitoring data
is allocated in thread 1. This causes kernel panic.
This commit fixes it by allocating the monitoring data before enabling
the bearer to receive messages.
Fixes: 35c55c9877f8 ("tipc: add neighbor monitoring framework") Reported-by: Shuang Li <shuali@redhat.com> Acked-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
The driver creates the top row map sysfs attribute in input_configured()
method; unfortunately we do not have a callback that is executed when HID
interface is unbound, thus we are leaking these sysfs attributes, for
example when device is disconnected.
To fix it let's switch to managed version of adding sysfs attributes which
will ensure that they are destroyed when the driver is unbound.
Fixes: 14c9c014babe ("HID: add vivaldi HID driver") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
On SC7180 we observe black screens because the gdsc is being
enabled/disabled very rapidly and the GDSC FSM state does not work as
expected. This is due to the fact that the GDSC reset value is being
updated from SW.
The recommended transition delay for mdss core gdsc updated for
SC7180/SC7280/SM8250.
Fixes: dd3d06622138 ("clk: qcom: Add display clock controller driver for SC7180") Fixes: 1a00c962f9cd ("clk: qcom: Add display clock controller driver for SC7280") Fixes: 80a18f4a8567 ("clk: qcom: Add display clock controller driver for SM8150 and SM8250") Signed-off-by: Taniya Das <tdas@codeaurora.org> Link: https://lore.kernel.org/r/20220223185606.3941-2-tdas@codeaurora.org Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[sboyd@kernel.org: lowercase hex] Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
GDSCs have multiple transition delays which are used for the GDSC FSM
states. Older targets/designs required these values to be updated from
gdsc code to certain default values for the FSM state to work as
expected. But on the newer targets/designs the values updated from the
GDSC driver can hamper the FSM state to not work as expected.
On SC7180 we observe black screens because the gdsc is being
enabled/disabled very rapidly and the GDSC FSM state does not work as
expected. This is due to the fact that the GDSC reset value is being
updated from SW.
Thus add support to update the transition delay from the clock
controller gdscs as required.
Fixes: 45dd0e55317cc ("clk: qcom: Add support for GDSCs) Signed-off-by: Taniya Das <tdas@codeaurora.org> Link: https://lore.kernel.org/r/20220223185606.3941-1-tdas@codeaurora.org Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
While the HVS has the same context memory size in the BCM2711 than in
the previous SoCs, the range allocated to the registers doubled and it
now takes 16k + 16k, compared to 8k + 16k before.
The KMS driver will use the whole context RAM though, eventually
resulting in a pointer dereference error when we access the higher half
of the context memory since it hasn't been mapped.
Fixes: 4564363351e2 ("ARM: dts: bcm2711: Enable the display pipeline") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Syzbot reported an slab-out-of-bounds Read in thrustmaster_probe() bug.
The root case is in missing validation check of actual number of endpoints.
Code should not blindly access usb_host_interface::endpoint array, since
it may contain less endpoints than code expects.
Fix it by adding missing validaion check and print an error if
number of endpoints do not match expected number
Fixes: c49c33637802 ("HID: support for initialization of some Thrustmaster wheels") Reported-and-tested-by: syzbot+35eebd505e97d315d01c@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Commit 817b8b9c539 ("HID: elo: fix memory leak in elo_probe") introduced
memory leak on error path, but more importantly the whole USB reference
counting is not needed at all in the first place, as the driver itself
doesn't change the reference counting in any way, and the associated
usb_device is guaranteed to be kept around by USB core as long as the
driver binding exists.
Reported-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: fbf42729d0e ("HID: elo: update the reference count of the usb device structure") Fixes: 817b8b9c539 ("HID: elo: fix memory leak in elo_probe") Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
The introduction of '9a61f813fcc8 ("clk: qcom: regmap-mux: fix parent
clock lookup")' broke UFS support on SM8350.
The cause for this is that the symbol clocks have a specified rate in
the "freq-table-hz" table in the UFS node, which causes the UFS code to
request a rate change, for which the "bi_tcxo" happens to provide the
closest rate. Prior to the change in regmap-mux it was determined
(incorrectly) that no change was needed and everything worked.
The rates of 75 and 300MHz matches the documentation for the symbol
clocks, but we don't represent the parent clocks today. So let's mimic
the configuration found in other platforms, by omitting the rate for the
symbol clocks as well to avoid the rate change.
While at it also fill in the dummy symbol clocks that was dropped from
the GCC driver as it was upstreamed.
When calling gnttab_end_foreign_access_ref() the returned value must
be tested and the reaction to that value should be appropriate.
In case of failure in xennet_get_responses() the reaction should not be
to crash the system, but to disable the network device.
The calls in setup_netfront() can be replaced by calls of
gnttab_end_foreign_access(). While at it avoid double free of ring
pages and grant references via xennet_disconnect_backend() in this case.
This is CVE-2022-23042 / part of XSA-396.
Reported-by: Demi Marie Obenour <demi@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
gnttab_end_foreign_access() is used to free a grant reference and
optionally to free the associated page. In case the grant is still in
use by the other side processing is being deferred. This leads to a
problem in case no page to be freed is specified by the caller: the
caller doesn't know that the page is still mapped by the other side
and thus should not be used for other purposes.
The correct way to handle this situation is to take an additional
reference to the granted page in case handling is being deferred and
to drop that reference when the grant reference could be freed
finally.
This requires that there are no users of gnttab_end_foreign_access()
left directly repurposing the granted page after the call, as this
might result in clobbered data or information leaks via the not yet
freed grant reference.
This is part of CVE-2022-23041 / XSA-396.
Reported-by: Simon Gaiser <simon@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Instead of __get_free_pages() and free_pages() use alloc_pages_exact()
and free_pages_exact(). This is in preparation of a change of
gnttab_end_foreign_access() which will prohibit use of high-order
pages.
This is part of CVE-2022-23041 / XSA-396.
Reported-by: Simon Gaiser <simon@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Instead of __get_free_pages() and free_pages() use alloc_pages_exact()
and free_pages_exact(). This is in preparation of a change of
gnttab_end_foreign_access() which will prohibit use of high-order
pages.
By using the local variable "order" instead of ring->intf->ring_order
in the error path of xen_9pfs_front_alloc_dataring() another bug is
fixed, as the error path can be entered before ring->intf->ring_order
is being set.
By using alloc_pages_exact() the size in bytes is specified for the
allocation, which fixes another bug for the case of
order < (PAGE_SHIFT - XEN_PAGE_SHIFT).
This is part of CVE-2022-23041 / XSA-396.
Reported-by: Simon Gaiser <simon@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Remove gnttab_query_foreign_access(), as it is unused and unsafe to
use.
All previous use cases assumed a grant would not be in use after
gnttab_query_foreign_access() returned 0. This information is useless
in best case, as it only refers to a situation in the past, which could
have changed already.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Using gnttab_query_foreign_access() is unsafe, as it is racy by design.
The use case in the gntalloc driver is not needed at all. While at it
replace the call of gnttab_end_foreign_access_ref() with a call of
gnttab_end_foreign_access(), which is what is really wanted there. In
case the grant wasn't used due to an allocation failure, just free the
grant via gnttab_free_grant_reference().
This is CVE-2022-23039 / part of XSA-396.
Reported-by: Demi Marie Obenour <demi@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
It isn't enough to check whether a grant is still being in use by
calling gnttab_query_foreign_access(), as a mapping could be realized
by the other side just after having called that function.
In case the call was done in preparation of revoking a grant it is
better to do so via gnttab_try_end_foreign_access() and check the
success of that operation instead.
This is CVE-2022-23038 / part of XSA-396.
Reported-by: Demi Marie Obenour <demi@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
It isn't enough to check whether a grant is still being in use by
calling gnttab_query_foreign_access(), as a mapping could be realized
by the other side just after having called that function.
In case the call was done in preparation of revoking a grant it is
better to do so via gnttab_end_foreign_access_ref() and check the
success of that operation instead.
This is CVE-2022-23037 / part of XSA-396.
Reported-by: Demi Marie Obenour <demi@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
It isn't enough to check whether a grant is still being in use by
calling gnttab_query_foreign_access(), as a mapping could be realized
by the other side just after having called that function.
In case the call was done in preparation of revoking a grant it is
better to do so via gnttab_end_foreign_access_ref() and check the
success of that operation instead.
For the ring allocation use alloc_pages_exact() in order to avoid
high order pages in case of a multi-page ring.
If a grant wasn't unmapped by the backend without persistent grants
being used, set the device state to "error".
This is CVE-2022-23036 / part of XSA-396.
Reported-by: Demi Marie Obenour <demi@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Add a new grant table function gnttab_try_end_foreign_access(), which
will remove and free a grant if it is not in use.
Its main use case is to either free a grant if it is no longer in use,
or to take some other action if it is still in use. This other action
can be an error exit, or (e.g. in the case of blkfront persistent grant
feature) some special handling.
This is CVE-2022-23036, CVE-2022-23038 / part of XSA-396.
Reported-by: Demi Marie Obenour <demi@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Letting xenbus_grant_ring() tear down grants in the error case is
problematic, as the other side could already have used these grants.
Calling gnttab_end_foreign_access_ref() without checking success is
resulting in an unclear situation for any caller of xenbus_grant_ring()
as in the error case the memory pages of the ring page might be
partially mapped. Freeing them would risk unwanted foreign access to
them, while not freeing them would leak memory.
In order to remove the need to undo any gnttab_grant_foreign_access()
calls, use gnttab_alloc_grant_references() to make sure no further
error can occur in the loop granting access to the ring pages.
It should be noted that this way of handling removes leaking of
grant entries in the error case, too.
This is CVE-2022-23040 / part of XSA-396.
Reported-by: Demi Marie Obenour <demi@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
The kernel test robot discovered that building without
HARDEN_BRANCH_PREDICTOR issues a warning due to a missing
argument to pr_info().
Add the missing argument.
Reported-by: kernel test robot <lkp@intel.com> Fixes: 9dd78194a372 ("ARM: report Spectre v2 status through sysfs") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
When building arm64 defconfig + CONFIG_LTO_CLANG_{FULL,THIN}=y after
commit 558c303c9734 ("arm64: Mitigate spectre style branch history side
channels"), the following error occurs:
Marc figured out that moving "#include <linux/init.h>" in
include/linux/arm-smccc.h into a !__ASSEMBLY__ block resolves it. The
full include chain with CONFIG_LTO=y from include/linux/arm-smccc.h:
The asm/alternative-macros.h include in asm/rwonce.h only happens when
CONFIG_LTO is set, which ultimately casues asm/assembler.h to be
included before the definition of ARM_SMCCC_ARCH_WORKAROUND_3. As a
result, the preprocessor does not expand ARM_SMCCC_ARCH_WORKAROUND_3 in
__mitigate_spectre_bhb_fw, which results in the error above.
Avoid this problem by just avoiding the CONFIG_LTO=y __READ_ONCE() block
in asm/rwonce.h with assembly files, as nothing in that block is useful
to assembly files, which allows ARM_SMCCC_ARCH_WORKAROUND_3 to be
properly expanded with CONFIG_LTO=y builds.
Fixes: e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y") Cc: <stable@vger.kernel.org> # 5.11.x Link: https://lore.kernel.org/r/20220309155716.3988480-1-maz@kernel.org/ Reported-by: Marc Zyngier <maz@kernel.org> Acked-by: James Morse <james.morse@arm.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20220309191633.2307110-1-nathan@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
ld.lld does not support the NOCROSSREFS directive at the moment, which
breaks the build after commit b9baf5c8c5c3 ("ARM: Spectre-BHB
workaround"):
ld.lld: error: ./arch/arm/kernel/vmlinux.lds:34: AT expected, but got NOCROSSREFS
Support for this directive will eventually be implemented, at which
point a version check can be added. To avoid breaking the build in the
meantime, just define NOCROSSREFS to nothing when using ld.lld, with a
link to the issue for tracking.
In the recent Spectre BHB patches, there was a typo that is only
exposed in certain configurations: mcr p15,0,XX,c7,r5,4 should have
been mcr p15,0,XX,c7,c5,4
Reported-by: kernel test robot <lkp@intel.com> Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
MIPS/IA64 define END as assembly function ending, which conflict
with END definition in slip.h, just undef it at first
Reported-by: lkp@intel.com Signed-off-by: Huang Pei <huangpei@loongson.cn> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
UBUNTU: SAUCE: Audit: Fix incorrect static inline function declration.
The LSM attributes SAUCE patches have incorrect syntax for the case
when AUDIT framework is turned off, such as zfcpdump_defconfig. This
in turn breaks building zfcpdump-kernel from Ubuntu patched sources.
Reproducer:
make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- zfcpdump_defconfig
make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- bzImage
BugLink: https://bugs.launchpad.net/bugs/1965766 Fixes: 558fd844dd ("UBUNTU: SAUCE: Audit: Add a new record for multiple object LSM attributes") Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Wen Gu [Sun, 16 Jan 2022 07:43:42 +0000 (15:43 +0800)]
net/smc: Fix hung_task when removing SMC-R devices
BugLink: https://bugs.launchpad.net/bugs/1929035
A hung_task is observed when removing SMC-R devices. Suppose that
a link group has two active links(lnk_A, lnk_B) associated with two
different SMC-R devices(dev_A, dev_B). When dev_A is removed, the
link group will be removed from smc_lgr_list and added into
lgr_linkdown_list. lnk_A will be cleared and smcibdev(A)->lnk_cnt
will reach to zero. However, when dev_B is removed then, the link
group can't be found in smc_lgr_list and lnk_B won't be cleared,
making smcibdev->lnk_cnt never reaches zero, which causes a hung_task.
This patch fixes this issue by restoring the implementation of
smc_smcr_terminate_all() to what it was before commit 349d43127dac
("net/smc: fix kernel panic caused by race of smc_sock"). The original
implementation also satisfies the intention that make sure QP destroy
earlier than CQ destroy because we will always wait for smcibdev->lnk_cnt
reaches zero, which guarantees QP has been destroyed.
Fixes: 349d43127dac ("net/smc: fix kernel panic caused by race of smc_sock") Signed-off-by: Wen Gu <guwen@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 56d99e81ecbc997a5f984684d0eeb583992b2072)
[picked again from upstream after having to revert due to LP: 1929035] Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Though smc_cdc_tx_handler() checked the existence of smc connection,
smc_release() may have already dismissed and released the smc socket
before smc_cdc_tx_handler() further visits it.
smc_cdc_tx_handler() |smc_release()
if (!conn) |
|
|smc_cdc_tx_dismiss_slots()
| smc_cdc_tx_dismisser()
|
|sock_put(&smc->sk) <- last sock_put,
| smc_sock freed
bh_lock_sock(&smc->sk) (panic) |
To make sure we won't receive any CDC messages after we free the
smc_sock, add a refcount on the smc_connection for inflight CDC
message(posted to the QP but haven't received related CQE), and
don't release the smc_connection until all the inflight CDC messages
haven been done, for both success or failed ones.
Using refcount on CDC messages brings another problem: when the link
is going to be destroyed, smcr_link_clear() will reset the QP, which
then remove all the pending CQEs related to the QP in the CQ. To make
sure all the CQEs will always come back so the refcount on the
smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced
by smc_ib_modify_qp_error().
And remove the timeout in smc_wr_tx_wait_no_pending_sends() since we
need to wait for all pending WQEs done, or we may encounter use-after-
free when handling CQEs.
For IB device removal routine, we need to wait for all the QPs on that
device been destroyed before we can destroy CQs on the device, or
the refcount on smc_connection won't reach 0 and smc_sock cannot be
released.
Fixes: 5f08318f617b ("smc: connection data control (CDC)") Reported-by: Wen Gu <guwen@linux.alibaba.com> Signed-off-by: Dust Li <dust.li@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 349d43127dac00c15231e8ffbcaabd70f7b0e544)
[picked again from upstream after having to revert due to LP: 1929035] Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Karsten Graul [Sat, 16 Oct 2021 09:37:52 +0000 (11:37 +0200)]
net/smc: stop links when their GID is removed
BugLink: https://bugs.launchpad.net/bugs/1929035
With SMC-Rv2 the GID is an IP address that can be deleted from the
device. When an IB_EVENT_GID_CHANGE event is provided then iterate over
all active links and check if their GID is still defined. Otherwise
stop the affected link.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 29397e34c76b57ce596493008176cf374f1cb867) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit b0539f5eddc2eefd24378bda3ee9cbbca916f58d) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Karsten Graul [Sat, 16 Oct 2021 09:37:50 +0000 (11:37 +0200)]
net/smc: extend LLC layer for SMC-Rv2
BugLink: https://bugs.launchpad.net/bugs/1929035
Add support for large v2 LLC control messages in smc_llc.c.
The new large work request buffer allows to combine control
messages into one packet that had to be spread over several
packets before.
Add handling of the new v2 LLC messages.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit b4ba4652b3f8b7c9bbb5786f8acf4724bdab2196) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Karsten Graul [Sat, 16 Oct 2021 09:37:49 +0000 (11:37 +0200)]
net/smc: add v2 support to the work request layer
BugLink: https://bugs.launchpad.net/bugs/1929035
In the work request layer define one large v2 buffer for each link group
that is used to transmit and receive large LLC control messages.
Add the completion queue handling for this buffer.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8799e310fb3f15759824a78b6b93d7e6d5def067) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Karsten Graul [Sat, 16 Oct 2021 09:37:48 +0000 (11:37 +0200)]
net/smc: retrieve v2 gid from IB device
BugLink: https://bugs.launchpad.net/bugs/1929035
In smc_ib.c, scan for RoCE devices that support UDP encapsulation.
Find an eligible device and check that there is a route to the
remote peer.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 24fb68111d4509524b483b2577f1b20a24f5fdfd) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8ade200c269f8530efde05b616801ed0612d7d72) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Karsten Graul [Sat, 16 Oct 2021 09:37:46 +0000 (11:37 +0200)]
net/smc: add listen processing for SMC-Rv2
BugLink: https://bugs.launchpad.net/bugs/1929035
Implement the server side of the SMC-Rv2 processing. Process incoming
CLC messages, find eligible devices and check for a valid route to the
remote peer.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e49300a6bf6218c835403545e9356141a6340181) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Karsten Graul [Sat, 16 Oct 2021 09:37:45 +0000 (11:37 +0200)]
net/smc: add SMC-Rv2 connection establishment
BugLink: https://bugs.launchpad.net/bugs/1929035
Send a CLC proposal message, and the remote side process this type of
message and determine the target GID. Check for a valid route to this
GID, and complete the connection establishment.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e5c4744cfb598f98672f8d21d59ef2c1fa9c9b5f) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Karsten Graul [Sat, 16 Oct 2021 09:37:44 +0000 (11:37 +0200)]
net/smc: prepare for SMC-Rv2 connection
BugLink: https://bugs.launchpad.net/bugs/1929035
Prepare the connection establishment with SMC-Rv2. Detect eligible
RoCE cards and indicate all supported SMC modes for the connection.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 42042dbbc2ebb926e594b22490374d9343c746ef) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Karsten Graul [Sat, 16 Oct 2021 09:37:43 +0000 (11:37 +0200)]
net/smc: save stack space and allocate smc_init_info
BugLink: https://bugs.launchpad.net/bugs/1929035
The struct smc_init_info grew over time, its time to save space on stack
and allocate this struct dynamically.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit ed990df29f5b4ae720a9044958aaf589073eb26d) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Frank Heimes [Fri, 18 Mar 2022 10:34:16 +0000 (11:34 +0100)]
Reverting commits 61005756c824 and cdb0f8e66513 due to a conflict with LP#1929035. Re-pick them afterwards, which will establish the upstream commit content and order again.
Niklas Schnelle [Thu, 17 Mar 2022 15:35:03 +0000 (12:35 -0300)]
s390/pci: implement minimal PCI error recovery
BugLink: https://bugs.launchpad.net/bugs/1959532
When the platform detects an error on a PCI function or a service action
has been performed it is put in the error state and an error event
notification is provided to the OS.
Currently we treat all error event notifications the same and simply set
pdev->error_state = pci_channel_io_perm_failure requiring user
intervention such as use of the recover attribute to get the device
usable again. Despite requiring a manual step this also has the
disadvantage that the device is completely torn down and recreated
resulting in higher level devices such as a block or network device
being recreated. In case of a block device this also means that it may
need to be removed and added to a software raid even if that could
otherwise survive with a temporary degradation.
This is of course not ideal more so since an error notification with PEC
0x3A indicates that the platform already performed error recovery
successfully or that the error state was caused by a service action that
is now finished.
At least in this case we can assume that the error state can be reset
and the function made usable again. So as not to have the disadvantage
of a full tear down and recreation we need to coordinate this recovery
with the driver. Thankfully there is already a well defined recovery
flow for this described in Documentation/PCI/pci-error-recovery.rst.
The implementation of this is somewhat straight forward and simplified
by the fact that our recovery flow is defined per PCI function. As
a reset we use the newly introduced zpci_hot_reset_device() which also
takes the PCI function out of the error state.
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Acked-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 4cdf2f4e24ff0d345fc36ef6d6aec059333a261e) Signed-off-by: Patricia Domingues <patricia.domingues@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Niklas Schnelle [Thu, 17 Mar 2022 15:35:02 +0000 (12:35 -0300)]
PCI: Export pci_dev_lock()
BugLink: https://bugs.launchpad.net/bugs/1959532
Commit e3a9b1212b9d ("PCI: Export pci_dev_trylock() and pci_dev_unlock()")
already exported pci_dev_trylock()/pci_dev_unlock() however in some
circumstances such as during error recovery it makes sense to block
waiting to get full access to the device so also export pci_dev_lock().
Link: https://lore.kernel.org/all/20210928181014.GA713179@bhelgaas/ Acked-by: Pierre Morel <pmorel@linux.ibm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit dfd5bb23ad75bdabde89ac3166705a450bf16acb) Signed-off-by: Patricia Domingues <patricia.domingues@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Niklas Schnelle [Thu, 17 Mar 2022 15:35:01 +0000 (12:35 -0300)]
s390/pci: implement reset_slot for hotplug slot
BugLink: https://bugs.launchpad.net/bugs/1959532
This is done by adding a zpci_hot_reset_device() call which does a low
level reset of the PCI function without changing its higher level
function state. This way it can be used while the zPCI function is bound
to a driver and with DMA tables being controlled either through the
IOMMU or DMA APIs which is prohibited when using zpci_disable_device()
as that drop existing DMA translations.
As this reset, unlike a normal FLR, also calls zpci_clear_irq() we need
to implement arch_restore_msi_irqs() and make sure we re-enable IRQs for
the PCI function if they were previously disabled.
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit da995d538d3a17610d89fea0f5813cf7921b3c2c) Signed-off-by: Patricia Domingues <patricia.domingues@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Niklas Schnelle [Thu, 17 Mar 2022 15:35:00 +0000 (12:35 -0300)]
s390/pci: refresh function handle in iomap
BugLink: https://bugs.launchpad.net/bugs/1959532
The function handle of a PCI function is updated when disabling or
enabling it as well as when the function's availability changes or it
enters the error state.
Until now this only occurred either while there is no struct pci_dev
associated with the function yet or the function became unavailable.
This meant that leaving a stale function handle in the iomap either
didn't happen because there was no iomap yet or it lead to errors on PCI
access but so would the correct disabled function handle.
In the future a CLP Set PCI Function Disable/Enable cycle during PCI
device recovery may be done while the device is bound to a driver. In
this case we must update the iomap associated with the now-stale
function handle to ensure that the resulting zPCI instruction references
an accurate function handle.
Since the function handle is accessed by the PCI accessor helpers
without locking use READ_ONCE()/WRITE_ONCE() to mark this access and
prevent compiler optimizations that would move the load/store.
With that infrastructure in place let's also properly update the
function handle in the existing cases. This makes sure that in the
future debugging of a zPCI function access through the handle will
show an up to date handle reducing the chance of confusion. Also it
makes sure we have one single place where a zPCI function handle is
updated after initialization.
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 4fe204977096e900cb91a3298b05c794ac24f540) Signed-off-by: Patricia Domingues <patricia.domingues@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Niklas Schnelle [Thu, 17 Mar 2022 15:34:59 +0000 (12:34 -0300)]
s390/pci: add simpler s390dbf traces for events
BugLink: https://bugs.launchpad.net/bugs/1959532
We often need to figure out what operations were performed in response
to an error or availability event. The operations are easily accessible
in s390dbf/pci_msg but the events have to be correlated with these from
either the kernel log or s390dbf/pci_err. Improve this situation by
logging the most important data from error and availability events that
is the FID, PEC and FH together with the operations.
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 6526a597a2e856df9ae94512f9903caccd5196d6) Signed-off-by: Patricia Domingues <patricia.domingues@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Niklas Schnelle [Thu, 17 Mar 2022 15:34:58 +0000 (12:34 -0300)]
s390/pci: tolerate inconsistent handle in recover
BugLink: https://bugs.launchpad.net/bugs/1959532
Since commit 8256adda1f44 ("s390/pci: handle FH state mismatch only on
disable") zpci_disable_device() returns -EINVAL when the platform
detects an attempt to disable a PCI function that it sees as already
disabled.
In most situations we want to abort whenever this happens and abort is
possible since it either means that the device vanished but we haven't
gotten an availability event yet, or the FH got out of sync which should
not happen.
Unfortunately there is an inconsistency between the LPAR and z/VM
hypervisors on whether error events for PCI functions contain an
an enabled or a general handle. So under z/VM it can happen that our
most up to date function handle is enabled but trying to disable the
function results in the aforementioned error.
Since recover is designed to be used to recover functions from the error
state let's make it robust to this inconsistency by explicitly treating
it as a successful disable.
Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 1c8174fdc798489159a79466fca782daa231219a) Signed-off-by: Patricia Domingues <patricia.domingues@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Andy Chi [Wed, 16 Mar 2022 15:03:52 +0000 (23:03 +0800)]
ALSA: hda/realtek: fix right sounds and mute/micmute LEDs for HP machines
BugLink: https://bugs.launchpad.net/bugs/1965080
* The HP ProBook 440/450 and EliteBook 640/650 are
using ALC236 codec which used 0x02 to control mute LED
and 0x01 to control micmute LED. Therefore, add a quirk to make it works.
Karsten Graul [Wed, 16 Mar 2022 07:54:29 +0000 (08:54 +0100)]
net/smc: add generic netlink support for system EID
BugLink: https://bugs.launchpad.net/bugs/1929060
With SMC-Dv2 users can configure if the static system EID should be used
during CLC handshake, or if only user EIDs are allowed.
Add generic netlink support to enable and disable the system EID, and
to retrieve the system EID and its current enabled state.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Reviewed-by: Guvenc Gulce <guvenc@linux.ibm.com> Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 3c572145c24e21c24e1cd0fd168011eaba85da8e) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Karsten Graul [Wed, 16 Mar 2022 07:54:28 +0000 (08:54 +0100)]
net/smc: keep static copy of system EID
BugLink: https://bugs.launchpad.net/bugs/1929060
The system EID is retrieved using an registered ISM device each time
when needed. This adds some unnecessary complexity at all places where
the system EID is needed, but no ISM device is at hand.
Simplify the code and save the system EID in a static variable in
smc_ism.c.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Reviewed-by: Guvenc Gulce <guvenc@linux.ibm.com> Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 11a26c59fc510091facd0d80236ac848da844830) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Karsten Graul [Wed, 16 Mar 2022 07:54:27 +0000 (08:54 +0100)]
net/smc: add support for user defined EIDs
BugLink: https://bugs.launchpad.net/bugs/1929060
SMC-Dv2 allows users to define EIDs which allows to create separate
name spaces enabling users to cluster their SMC-Dv2 connections.
Add support for user defined EIDs and extent the generic netlink
interface so users can add, remove and dump EIDs.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Reviewed-by: Guvenc Gulce <guvenc@linux.ibm.com> Signed-off-by: Guvenc Gulce <guvenc@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit fa0866625543b4d8b3d026e4e0ef5ec25a453920) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
2012 signing certificate was already revoked for kexec/kdump purposes.
After this patch is applied, certificates corresponding to CRL serials
01, 02, 03, 04 will not be usable by this kernel for kexec/kdump
purposes. This patch prevents this kernel to kexec/kdump using kernels
signed by those certifictes when lockdown is in place.
05 Ubuntu Core 2019 signing certificate is not included as revoked, as
that certificate signs kernel.efi apps only which linux doesn't know
not know how to use with kexec/kdump.
Kernels that include this patch should be routed via 2021v1 signing,
to preserve kexec/kdump functionality under lockdown.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Halil Pasic [Tue, 14 Dec 2021 14:54:16 +0000 (15:54 +0100)]
s390/airq: use DMA memory for summary indicators
BugLink: https://bugs.launchpad.net/bugs/1959547
Protected virtualization guests have to use shared pages for airq
notifier bit vectors and summary bytes or bits, thus these need to be
allocated as DMA coherent memory. Commit b50623e5db80 ("s390/airq: use
DMA memory for adapter interrupts") took care of the notifier bit
vectors, but omitted to take care of the summary bytes/bits.
In practice this omission is not a big deal, because the summary ain't
necessarily allocated here, but can be supplied by the driver. Currently
all the I/O we have for SE guests is virtio-ccw, and virtio-ccw uses a
self-allocated array of summary indicators.
Let us cover all our bases nevertheless!
Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 9d792ef17f18734bca823910b89254dec37b50c5 linux-next) Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
Jürgen Christ [Mon, 10 Jan 2022 12:33:30 +0000 (13:33 +0100)]
s390/zcrypt: Provide target domain for EP11 cprbs to scheduling function
BugLink: https://bugs.launchpad.net/bugs/1959547
The scheduling function will get an extension which will
process the target_id value from an EP11 cprb. This patch
extracts the value during preparation of the ap message.
Signed-off-by: Jürgen Christ <jchrist@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 1024063effc3ba86d1fec0f2ee0a9259a1065ed5 linux-next) Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1959547
Instead of offering the user space given receive buffer size to
the crypto card firmware as limit for the reply message offer
the internal per queue reply buffer size. As the queue's reply
buffer is always adjusted to the max message size possible for
this card this may offer more buffer space. However, now it is
important to check the user space reply buffer on pushing back
the reply. If the reply does not fit into the user space provided
buffer the ioctl will fail with errno EMSGSIZE.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Jürgen Christ <jchrist@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 252a1ff777639ad13978a614f2cde1f0c43a7c2f linux-next) Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1959547
There is a new CPRB minor version T7 to be supported with
this patch. Together with this the functions which extract
the CPRB data from userspace and prepare the AP message do
now check the CPRB minor version and provide some info in
the flag field of the ap message struct for further processing.
The 3 functions doing this job have been renamed to
prep_cca_ap_msg, prep_ep11_ap_msg and prep_rng_ap_msg to
reflect their job better (old was get..fc).
This patch also introduces two new flags to be used internal
with the flag field of the struct ap_message:
AP_MSG_FLAG_USAGE is set when prep_cca_ap_msg or prep_ep11_ap_msg
come to the conclusion that this is a ordinary crypto load CPRB
(which means T2 for CCA CPRBs and no admin bit for EP11 CPRBs).
AP_MSG_FLAG_ADMIN is set when prep_cca_ap_msg or prep_ep11_ap_msg
think, this is an administrative (control) crypto load CPRB
(which means T3, T5, T6 or T7 for CCA CPRBs and admin bit set
for EP11 CPRBs).
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Jürgen Christ <jchrist@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 383366b58016361cc8a2e4c585b7d581eb76263a linux-next) Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
s390/zcrypt: handle checkstopped cards with new state
BugLink: https://bugs.launchpad.net/bugs/1959547
A crypto card may be in checkstopped state. With this
patch this is handled as a new state in the ap card and
ap queue structs. There is also a new card sysfs attribute
/sys/devices/ap/cardxx/chkstop
and a new queue sysfs attribute
/sys/devices/ap/cardxx/xx.yyyy/chkstop
displaying the checkstop state of the card or queue. Please
note that the queue's checkstop state is only a copy of the
card's checkstop state but makes maintenance much easier.
The checkstop state expressed here is the result of an
RC 0x04 (CHECKSTOP) during an AP command, mostly the
PQAP(TAPQ) command which is 'testing' the queue.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Jürgen Christ <jchrist@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit a7e701dba1234adbfbacad5ce19656c5606728da linux-next) Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1959547
This patch adds CEX8 exploitation support for the AP bus code,
the zcrypt device driver zoo and the vfio device driver.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Jürgen Christ <jchrist@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 985214af939b9935dac94aa6fb56c85039fb77e8 linux-next) Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1959547
This patch adds some debug feature improvements related
to some failures happened in the past. With CEX8 the max
request and response sizes have been extended but the
user space applications did not rework their code and
thus ran into receive buffer issues. This ffdc patch
here helps with additional checks and debug feature
messages in debugging and pointing to the root cause of
some failures related to wrong buffer sizes.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Jürgen Christ <jchrist@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit d64e5e9120a6afc8ebb9e9b46c1302f13b16b68d linux-next) Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1959547
This patch reworks all the debug feature invocations to be
more uniform. All invocations now use the macro with the
level already part of the macro name. All messages now start
with %s filled with __func__ (well there are still some
exceptions), and some message text has been shortened or
reworked.
There is no functional code touched with this patch.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 3f74eb5f78198a88ebbad7b1d8168f7ea34b3f1a) Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
Frank Heimes [Mon, 14 Mar 2022 11:24:17 +0000 (12:24 +0100)]
UBUNTU: SAUCE: Set KVM_CAP_S390_MEM_OP_EXTENSION capability to 211
BugLink: https://bugs.launchpad.net/bugs/1963901
Setting KVM_CAP_S390_MEM_OP_EXTENSION capability to 211 is required
to enable storage key checking for intercepted instruction and
to ensure compatibility with upstream.
The upstream merge request
"Merge branch 'kvm-ppc-cap-210' into kvm-next-5.18."
https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h=next&id=4dfc4ec2b7f5a3a27d166ac42cf8a583fa2d3284
is referenced in LP: 1963901, but it includes and pulls in more changes
than needed - even changes for ppc64el and at the API doc
that are not relevant for s390x.
Hence this UBUNTU SAUCE patch, that limits the modification to the bare
minimum (a single line).
[Avoiding backport of "Merge branch 'kvm-ppc-cap-210' into kvm-next-5.18.",
upstream commit 4dfc4ec2b7f5a3a27d166ac42cf8a583fa2d3284,
and limiting change to the bare minimum.] Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Thomas Lamprecht [Sat, 12 Mar 2022 15:19:10 +0000 (16:19 +0100)]
Ubuntu: remove leftover reference to ubuntu/hio driver
A single reference to the hio driver was forgotten when it was removed
recently. While this reference is not a problem for the build itself, it
breaks the __clean target from 'scripts/Makefile.clean' here, as make
cannot enter the "ubuntu/hio" folder for cleaning due to ENOENT.
Fixes: 4ea6dd9afa0a0d ("UBUNTU: Remove ubuntu/hio driver") Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
UBUNTU: [Packaging] Always catch errors in dkms-build scripts
Enforce `set -e` execution of the dkms-build scripts, even when
overall SHELL is not set to `bash -e`. This enforces that dkms-build
scripts catch errors, even when building without SHELL variable, like
it is done by the LRM packages.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
UBUNTU: [Packaging] Fix bashism in dkms-build script
dkms-build script uses bashism variable and test comparison, replace
them with dash compatible invocations. This allows using dkms-build
scripts without SHELL variable set to "bash -e", like it is done by
LRM packages.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
UBUNTU: [Packaging] mark dkms-build-configure--zfs executable
Mark dkms-build-configure--zfs script executable, such that one
doesn't need to call it with an explicit shell.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Martin Habets [Thu, 10 Mar 2022 20:45:01 +0000 (17:45 -0300)]
UBUNTU: SAUCE: sfc: The size of the RX recycle ring should be more flexible
Buglink: https://bugs.launchpad.net/bugs/1964512
Ideally the size would depend on the link speed, but the recycle
ring is created when the interface is brought up before the driver
knows the link speed. So size it for the maximum speed of a given NIC.
PowerPC is only supported on SFN7xxx and SFN8xxx NICs.
With this patch on a 40G NIC the number of calls to alloc_pages and
friends went down from about 18% to under 2%.
On a 10G NIC the number of calls to alloc_pages and friends went down
from about 15% to 0 (perf did not capture any calls during the 60
second test).
On a 100G NIC the number of calls to alloc_pages and friends went down
from about 23% to 4%.
UBUNTU: SAUCE: ima_policy: fix test for empty rule set
SAUCE commit "LSM: Create and manage the lsmblob data structure."
changes the single audit rule data into an array.
Upstream commit 89677197ae70 ("ima: Do not print policy rule with
inactive LSM labels") adds a test for the rule on ima_rule_entry when
showing in proc files, which use the unsauced rule test.
Use the function ima_lsm_isset introduced by the SAUCE patch to test
whether a rule is set.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Michael Mueller [Wed, 9 Mar 2022 15:51:44 +0000 (16:51 +0100)]
KVM: s390: pv: make use of ultravisor AIV support
BugLink: https://bugs.launchpad.net/bugs/1959977
This patch enables the ultravisor adapter interruption vitualization
support indicated by UV feature BIT_UV_FEAT_AIV. This allows ISC
interruption injection directly into the GISA IPM for PV kvm guests.
Hardware that does not support this feature will continue to use the
UV interruption interception method to deliver ISC interruptions to
PV kvm guests. For this purpose, the ECA_AIV bit for all guest cpus
will be cleared and the GISA will be disabled during PV CPU setup.
In addition a check in __inject_io() has been removed. That reduces the
required instructions for interruption handling for PV and traditional
kvm guests.
Signed-off-by: Michael Mueller <mimu@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Link: https://lore.kernel.org/r/20220209152217.1793281-2-mimu@linux.ibm.com Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
(backported from commit ee6a569d3bf64c9676eee3eecb861fb01cc11311 linux-next)
[Frank Heimes: Resolve minor conflict due to context change.] Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
zouxiaoh [Wed, 23 Feb 2022 02:21:25 +0000 (10:21 +0800)]
UBUNTU: SAUCE: iommu: intel-ipu: use IOMMU passthrough mode for Intel IPUs
BugLink: https://bugs.launchpad.net/bugs/1958004
Intel IPU(Image Processing Unit) has its own (IO)MMU hardware,
The IPU driver allocates its own page table that is not mapped
via the DMA, and thus the Intel IOMMU driver blocks access giving
this error: DMAR: DRHD: handling fault status reg 3 DMAR:
[DMA Read] Request device [00:05.0] PASID ffffffff
fault addr 76406000 [fault reason 06] PTE Read access is not set
As IPU is not an external facing device which is not risky, so use
IOMMU passthrough mode for Intel IPUs.
Change-Id: I6dcccdadac308cf42e20a18e1b593381391e3e6b
Depends-On: Iacd67578e8c6a9b9ac73285f52b4081b72fb68a6
Tracked-On: #JIITL8-411 Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: zouxiaoh <xiaohong.zou@intel.com> Signed-off-by: Xu Chongyang <chongyang.xu@intel.com>
(cherry picked from https://github.com/intel/ipu6-drivers/blob/5d5526d2b2811aa52590c2fa513ba989e7e594ab/patch/IOMMU-passthrough-for-intel-ipu.diff) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
The mitigations for Spectre-BHB are only applied when an exception is
taken from user-space. The mitigation status is reported via the spectre_v2
sysfs vulnerabilities file.
When unprivileged eBPF is enabled the mitigation in the exception vectors
can be avoided by an eBPF program.
When unprivileged eBPF is enabled, print a warning and report vulnerable
via the sysfs vulnerabilities file.
Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Future CPUs may implement a clearbhb instruction that is sufficient
to mitigate SpectreBHB. CPUs that implement this instruction, but
not CSV2.3 must be affected by Spectre-BHB.
Add support to use this instruction as the BHB mitigation on CPUs
that support it. The instruction is in the hint space, so it will
be treated by a NOP as older CPUs.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
KVM allows the guest to discover whether the ARCH_WORKAROUND SMCCC are
implemented, and to preserve that state during migration through its
firmware register interface.
Add the necessary boiler plate for SMCCC_ARCH_WORKAROUND_3.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Speculation attacks against some high-performance processors can
make use of branch history to influence future speculation.
When taking an exception from user-space, a sequence of branches
or a firmware call overwrites or invalidates the branch history.
The sequence of branches is added to the vectors, and should appear
before the first indirect branch. For systems using KPTI the sequence
is added to the kpti trampoline where it has a free register as the exit
from the trampoline is via a 'ret'. For systems not using KPTI, the same
register tricks are used to free up a register in the vectors.
For the firmware call, arch-workaround-3 clobbers 4 registers, so
there is no choice but to save them to the EL1 stack. This only happens
for entry from EL0, so if we take an exception due to the stack access,
it will not become re-entrant.
For KVM, the existing branch-predictor-hardening vectors are used.
When a spectre version of these vectors is in use, the firmware call
is sufficient to mitigate against Spectre-BHB. For the non-spectre
versions, the sequence of branches is added to the indirect vector.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Speculation attacks against some high-performance processors can
make use of branch history to influence future speculation as part of
a spectre-v2 attack. This is not mitigated by CSV2, meaning CPUs that
previously reported 'Not affected' are now moderately mitigated by CSV2.
Update the value in /sys/devices/system/cpu/vulnerabilities/spectre_v2
to also show the state of the BHB mitigation.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
The Spectre-BHB workaround adds a firmware call to the vectors. This
is needed on some CPUs, but not others. To avoid the unaffected CPU in
a big/little pair from making the firmware call, create per cpu vectors.
The per-cpu vectors only apply when returning from EL0.
Systems using KPTI can use the canonical 'full-fat' vectors directly at
EL1, the trampoline exit code will switch to this_cpu_vector on exit to
EL0. Systems not using KPTI should always use this_cpu_vector.
this_cpu_vector will point at a vector in tramp_vecs or
__bp_harden_el1_vectors, depending on whether KPTI is in use.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
The trampoline code needs to use the address of symbols in the wider
kernel, e.g. vectors. PC-relative addressing wouldn't work as the
trampoline code doesn't run at the address the linker expected.
tramp_ventry uses a literal pool, unless CONFIG_RANDOMIZE_BASE is
set, in which case it uses the data page as a literal pool because
the data page can be unmapped when running in user-space, which is
required for CPUs vulnerable to meltdown.
Pull this logic out as a macro, instead of adding a third copy
of it.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Some CPUs affected by Spectre-BHB need a sequence of branches, or a
firmware call to be run before any indirect branch. This needs to go
in the vectors. No CPU needs both.
While this can be patched in, it would run on all CPUs as there is a
single set of vectors. If only one part of a big/little combination is
affected, the unaffected CPUs have to run the mitigation too.
Create extra vectors that include the sequence. Subsequent patches will
allow affected CPUs to select this set of vectors. Later patches will
modify the loop count to match what the CPU requires.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
kpti is an optional feature, for systems not using kpti a set of
vectors for the spectre-bhb mitigations is needed.
Add another set of vectors, __bp_harden_el1_vectors, that will be
used if a mitigation is needed and kpti is not in use.
The EL1 ventries are repeated verbatim as there is no additional
work needed for entry from EL1.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Adding a second set of vectors to .entry.tramp.text will make it
larger than a single 4K page.
Allow the trampoline text to occupy up to three pages by adding two
more fixmap slots. Previous changes to tramp_valias allowed it to reach
beyond a single page.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Spectre-BHB needs to add sequences to the vectors. Having one global
set of vectors is a problem for big/little systems where the sequence
is costly on cpus that are not vulnerable.
Making the vectors per-cpu in the style of KVM's bh_harden_hyp_vecs
requires the vectors to be generated by macros.
Make the kpti re-mapping of the kernel optional, so the macros can be
used without kpti.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
The macros for building the kpti trampoline are all behind
CONFIG_UNMAP_KERNEL_AT_EL0, and in a region that outputs to the
.entry.tramp.text section.
Move the macros out so they can be used to generate other kinds of
trampoline. Only the symbols need to be guarded by
CONFIG_UNMAP_KERNEL_AT_EL0 and appear in the .entry.tramp.text section.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
The tramp_ventry macro uses tramp_vectors as the address of the vectors
when calculating which ventry in the 'full fat' vectors to branch to.
While there is one set of tramp_vectors, this will be true.
Adding multiple sets of vectors will break this assumption.
Move the generation of the vectors to a macro, and pass the start
of the vectors as an argument to tramp_ventry.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-23960 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
projects / mirror_ubuntu-jammy-kernel.git / log