Govindarajulu Varadarajan [Fri, 1 Dec 2017 18:21:40 +0000 (10:21 -0800)]
enic: add sw timestamp support
Add ethtool ops to advertise sw timestamping.
Call skb_tx_timestamp() just before ringing the wq doorbell.
Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 27587345
(cherry picked from commit fb7516d42478ebc8e2f00efb76ef96f7b68fd8d3) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com>
Govindarajulu Varadarajan [Thu, 21 Dec 2017 16:12:28 +0000 (08:12 -0800)]
enic: add wq clean up budget
In case of tx clean up, we set '-1' as budget. This means clean up until
wq is empty or till (1 << 32) pkts are cleaned. Under heavy load this
will run for long time and cause
"watchdog: BUG: soft lockup - CPU#25 stuck for 21s!" warning.
This patch sets wq clean up budget to 256.
Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 27587345
(cherry picked from commit 18feb87105c3c16dc01e6981a6aafb175679b997) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com>
Parvi Kaustubhi [Wed, 1 Nov 2017 15:44:47 +0000 (08:44 -0700)]
enic: Add support for 'ethtool -g/-G'
Add support for displaying and modifying rx and tx ring sizes using
ethtool.
Also, increasing version to 2.3.0.45
Signed-off-by: Parvi Kaustubhi <pkaustub@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 27587345
(cherry picked from commit ed519b7488a42ce549ef7eae8dd13e043dde10a4) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com>
Parvi Kaustubhi [Wed, 1 Nov 2017 15:44:46 +0000 (08:44 -0700)]
enic: reset fetch index
Since we are allowing rx ring size modification, reset fetch index
everytime. Otherwise it could have a stale value that can lead to a null
pointer dereference.
Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by: Parvi Kaustubhi <pkaustub@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 27587345
(cherry picked from commit e6cdfcc581866625980a89391be4e6a8b379d0c5) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com>
Allen Pais [Thu, 21 Sep 2017 17:05:22 +0000 (22:35 +0530)]
drivers: net: enic: use setup_timer() helper.
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais <allen.lkml@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 27587345
(cherry picked from commit 570ba3e82befbba7649e459fedc4aab27510ef44) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com>
Allen Pais [Thu, 21 Sep 2017 17:04:45 +0000 (22:34 +0530)]
drivers: net: enic: use setup_timer() helper.
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Allen Pais <allen.lkml@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 27587345
(cherry picked from commit 7afd516ff75e967873d7bdcb8f9b1180c2400b57) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com>
Govindarajulu Varadarajan [Tue, 21 Mar 2017 22:07:48 +0000 (15:07 -0700)]
enic: update enic maintainers
update enic maintainers
Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 27587345
(cherry picked from commit dd1ef79120e1600cb48320cf80a612ee6510110c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com>
Govindarajulu Varadarajan [Mon, 19 Jun 2017 23:28:44 +0000 (16:28 -0700)]
enic: Fix format truncation warning
With -Wformat-truncation, gcc throws the following warning.
Fix this by increasing the size of devname to accommodate 15 character
netdev interface name and description.
Remove length format precision for %s. We can fit entire name.
Also increment the version.
drivers/net/ethernet/cisco/enic/enic_main.c: In function ‘enic_open’:
drivers/net/ethernet/cisco/enic/enic_main.c:1740:15: warning: ‘%u’ directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 12 [-Wformat-truncation=]
"%.11s-rx-%u", netdev->name, i);
^~
drivers/net/ethernet/cisco/enic/enic_main.c:1740:5: note: directive argument in the range [0, 16]
"%.11s-rx-%u", netdev->name, i);
^~~~~~~~~~~~~
drivers/net/ethernet/cisco/enic/enic_main.c:1738:4: note: ‘snprintf’ output between 6 and 18 bytes into a destination of size 16
snprintf(enic->msix[intr].devname,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(enic->msix[intr].devname),
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%.11s-rx-%u", netdev->name, i);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 27587345
(cherry picked from commit 7044f429e70d987cdc780f26a9b9951970645966) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com>
Govindarajulu Varadarajan [Thu, 9 Feb 2017 00:43:07 +0000 (16:43 -0800)]
enic: add devcmds for vxlan offload
This patch adds devcmds needed for vxlan offload. Implement 3 new devcmd
overlay_offload_ctrl: enable/disable offload
overlay_offload_cfg: update offload udp port number
get_supported_feature_ver: get hw supported offload version. Each
version has different bitmap for csum_ok/encap
Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit ca0291798227a6da0f3ba6c2e3a43d94d5dcf591)
Orabug: 27587345 Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com>
Sandeep Pillai [Wed, 3 Feb 2016 09:10:44 +0000 (14:40 +0530)]
enic: increment devcmd2 result ring in case of timeout
Firmware posts the devcmd result in result ring. In case of timeout, driver
does not increment the current result pointer and firmware could post the
result after timeout has occurred. During next devcmd, driver would be
reading the result of previous devcmd.
Fix this by incrementing result even in case of timeout.
Fixes: 373fb0873d43 ("enic: add devcmd2") Signed-off-by: Sandeep Pillai <sanpilla@cisco.com> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 27587345
(cherry picked from commit ca7f41a4957b872577807169bd7464b36aae9b9c)
Conflict in enic.h - avoid reverting version number Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com>
Rasmus Villemoes [Mon, 8 Jan 2018 23:11:15 +0000 (00:11 +0100)]
scsi: fnic: use kzalloc in fnic_fcoe_process_vlan_resp
This saves a little .text and gets rid of the unmotivated line break and
the sizeof(...) style inconsistency.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit dbc1ebe7b0fd43f7d74ba0e87b411eb48c9fdeb2)
Orabug: 27587343 Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
As the literal strings get merged, the function uses %ps instead of the
intended raw %p format. Fix this by inserting a space.
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit f280c77dc9bb850bc49a126ef5a088e7340a61b6)
Orabug: 27587343 Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Vasyl Gomonovych [Tue, 21 Nov 2017 21:15:46 +0000 (22:15 +0100)]
scsi: fnic: Fix coccinelle warnings
Remove the duplicate copies of this simple function and use an
open-coded version.
drivers/scsi/fnic/fnic_debugfs.c:122:11-31: WARNING opportunity for simple_open, see also structure on line 223
Generated by: coccinelle/api/simple_open.cocci
Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit d9462140f7ab0400206041d2732c740dea2d1ff9)
Orabug: 27587343 Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Hannes Reinecke [Fri, 25 Aug 2017 11:57:00 +0000 (13:57 +0200)]
scsi: fnic: do not call host reset from command abort
Command abort already returns FAILED, which will then be escalated to a
host reset. So no need to call host_reset directly.
Signed-off-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 7c3a50bb9b6ec289126085ccfe205ed0cc3c0a85)
Orabug: 27587343 Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
The MSI interrupt name can require 11 bytes in addition to the device name,
for a total of 23 bytes:
drivers/scsi/fnic/fnic_isr.c: In function 'fnic_request_intr':
drivers/scsi/fnic/fnic_isr.c:192:4: error: '-fcs-rq' directive writing 7 bytes into a region of size between 5 and 16 [-Werror=format-overflow=]
"%.11s-fcs-rq", fnic->name);
drivers/scsi/fnic/fnic_isr.c:206:3: note: 'sprintf' output between 12 and 23 bytes into a destination of size 16
sprintf(fnic->msix[FNIC_MSIX_ERR_NOTIFY].devname,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%.11s-err-notify", fnic->name);
This extends the buffer to fit any possible value.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 514e59c1195f2634dab025d952242f5e69e052c7)
Orabug: 27587343 Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Satish Kharat [Tue, 27 Jun 2017 00:48:08 +0000 (17:48 -0700)]
scsi: fnic: added timestamp reporting in fnic debug stats
Added the timestamps for
1. current timestamp
2. last fnic stats read timestamp
3. last fnic stats reset timestamp
and the deltas since last stats read and last reset in fnic stats.
fnic stats uses debugfs
Signed-off-by: Sesidhar Baddela <sebaddel@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 43caa03fec79d062c5f7a959a823770d72717b24)
Orabug: 27587343 Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Satish Kharat [Tue, 27 Jun 2017 00:46:23 +0000 (17:46 -0700)]
scsi: fnic: Zero io_cmpl_skip on fw reset completion
io_cmpl_skip keep track of number of completions to skip when stats are
reset. If a fw_reset happens immediately after stats reset it could put
it out of sync so need to reset io_cmpl_skip when fw reset is completed.
Signed-off-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Sesidhar Baddela <sebaddel@cisco.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 1cdf8bc18f1ee43a39e543506fff8d5db3020ae1)
Orabug: 27587343 Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Maurizio Lombardi [Wed, 16 Mar 2016 13:44:08 +0000 (14:44 +0100)]
fnic: move printk()s outside of the critical code section.
This patch moves a printk() outside of the code section where interrupt
are disabled. In some cases a flood of error messages may cause a kernel
panic. It also removes one of the printk()s because the same error
message was printed twice.
Maurizio Lombardi [Wed, 12 Aug 2015 15:00:23 +0000 (17:00 +0200)]
fnic: check pci_map_single() return value
the kernel prints some warnings when compiled with CONFIG_DMA_API_DEBUG.
This is because the fnic driver doesn't check the return value of
pci_map_single().
[ 11.942770] scsi host12: fnic
[ 11.950811] ------------[ cut here ]------------
[ 11.950818] WARNING: at lib/dma-debug.c:937 check_unmap+0x47b/0x920()
[ 11.950821] fnic 0000:0c:00.0: DMA-API: device driver failed to check map error[device address=0x0000002020a30040] [size=44 bytes] [mapped as single]
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed By: Tomas Henzl <thenzl@redhat.com> Signed-off-by: James Bottomley <JBottomley@Odin.com>
(cherry picked from commit fd6ddfa4c1ddfb4a149b31845144b4cf3cbef54d)
Orabug: 27587343 Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Chuck Anderson [Mon, 26 Feb 2018 09:40:58 +0000 (01:40 -0800)]
retpoline: set IBRS and IBPB in use only on the boot CPU call to init_scattered_cpuid_features()
Setting IBRS and IBPB in use is a system wide issue, not a per-CPU
issue. Set them only on the boot CPU's call to
init_scattered_cpuid_features().
Orabug: 27625404 Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Conflicts:
arch/x86/kernel/cpu/scattered.c
(merged with be596ab27 ("x86/speculation: Use IBRS if available before
calling into firmware"))
Chuck Anderson [Mon, 26 Feb 2018 09:27:37 +0000 (01:27 -0800)]
retpoline: display IBPB feature status along with IBRS status
retpoline_enabled() lists if the IBRS mitigation is in use and if the
kernel was compiled with retpoline. Add whether IBPB is in use to the
list.
Orabug: 27625404 Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Chuck Anderson [Mon, 26 Feb 2018 08:59:51 +0000 (00:59 -0800)]
retpoline: move lock/unlock of spec_ctrl_mutex to check_modinfo()
Testing has found that check_modinfo() will call disable_retpoline()
concurrently for the same module. Serialization through
spec_ctrl_mutex in disable_retpoline() keeps the retpoline state sane
but misleading messages are issued during the duplicate call.
Move the lock/unlock of spec_ctrl_mutex to check_modinfo() so that the
first call to disable_retpoline() will disable retpoline before the
duplicate call checks to see if retpoline is disabled.
Orabug: 27625404 Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Chuck Anderson [Mon, 26 Feb 2018 08:33:53 +0000 (00:33 -0800)]
retpoline: call clear_retpoline_fallback() with boot parm spectre_v2_heuristics=off
retpoline_fallback=off is one of the spectre_v2_heuristics boot parm
settings. Disable retpoline fallback when boot parameter
spectre_v2_heuristics=off is specified.
Orabug: 27625404 Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Chuck Anderson [Mon, 26 Feb 2018 08:20:30 +0000 (00:20 -0800)]
retpoline: add brackets to check_ibrs_inuse() and clear_ibpb_inuse()
Add brackets to the "else" clause in both check_ibrs_inuse() and
clear_ibpb_inuse() to match indentations. The brackets are not
required but may prevent a bug when indented code is mistakenly added
without adding brackets.
Orabug: 27625404 Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Chuck Anderson [Thu, 22 Feb 2018 22:01:24 +0000 (14:01 -0800)]
retpoline/module: do not enable IBRS/IPBP if SPEC_CTRL_IBRS_ADMIN_DISABLED/SPEC_CTRL_IBPB_ADMIN_DISABLED is set
The retpoline fallback code in disable_retpoline() attempts to enable
the Spectre IBRS and IPBP mitigations by calling set_ibrs_inuse() and
set_ibpb_inuse(). SPEC_CTRL_IBRS_INUSE should not be set unless
SPEC_CTRL_IBRS_SUPPORTED is set and SPEC_CTRL_IBRS_ADMIN_DISABLED is not
set. Otherwise, the kernel boot parameter noibrs, which sets
SPEC_CTRL_IBRS_ADMIN_DISABLED, is ignored and IBRS is incorrectly
enabled during retpoline fallback.
Same for set_ibpb_inuse(): it should respect
SPEC_CTRL_IBPB_ADMIN_DISABLED.
Orabug: 27625353 Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Chuck Anderson [Thu, 22 Feb 2018 22:01:24 +0000 (14:01 -0800)]
retpoline: microcode incorrectly reported as broken during early boot
init_scattered_cpuid_features() is called on each CPU to set its
capabilities based on features enumerated by the cpuid instruction.
If the CPU supports IBRS or STIBP, a call is made through
bad_spectre_microcode() to detect a microcode level that makes it
unsafe to use IBRS as a mitigation for Spectre. A warning is issued
if the microcode is unsafe:
init_scattered_cpuid_features() may be called early during boot on the
boot CPU. The microcode level from BIOS may be broken, triggering the
message above. A subsequent microcode update made during early boot
could install a level that is IBRS/STIBP/IPBP safe making the warning
message misleading. This patch skips the microcode check during early
boot. The check is made during a subsequent call to
init_scattered_cpuid_features() after a potential microcode update.
Orabug: 27625404 Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Chuck Anderson [Mon, 26 Feb 2018 07:58:47 +0000 (23:58 -0800)]
retpoline: move lock/unlock of spec_ctrl_mutex into init_scattered_cpuid_features()
init_scattered_cpuid_features() changes spectre mitigation state.
Not all callers obtained spec_ctrl_mutex. Move the lock/unlock of
spec_ctrl_mutex to init_scattered_cpuid_features() rather than have
the callers obtain it. That also allows init_scattered_cpuid_features()
to serialize just the spectre state changes instead of the entire
function.
Orabug: 27625404 Signed-off-by: Chuck Anderson <chuck.anderson@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Chuck Anderson [Mon, 12 Feb 2018 07:49:30 +0000 (23:49 -0800)]
retpoline/module: fall back to another spectre mitigation when disabling retpoline
Commit ("retpoline/module: Taint kernel for missing retpoline in module")
calls the new function disable_retpoline() when check_modinfo() determines
that a LKM being loaded was not compiled with retpoline.
This commit adds code to disable_retpoline() that attempts to fall back to
the Spectre v2 mitigations IBRS/IBPB when disabling retpoline.
Pseudocode for disable_retpoline():
if retpoline is not enabled
No messages/changes
return
if we are allowed to fall back to another mitigation
if IBRS is not in use
if we enabled it
spectre_v2_enabled = SPECTRE_V2_IBRS
pr_err("Spectre v2 mitigation set to IBRS.\n")
if we enabled IBPB mitigation
pr_err("Spectre v2 mitigation IBPB enabled.\n")
else
pr_err("Could not enable IBRS.\n")
spectre_v2_enabled = SPECTRE_V2_NONE
pr_err("No Spectre v2 mitigation to fall back to.\n")
else
spectre_v2_enabled = SPECTRE_V2_IBRS;
pr_err("Spectre v2 mitigation IBRS is set.\n")
else
spectre_v2_enabled = SPECTRE_V2_NONE;
pr_err("Cannot choose another Spectre v2 mitigation because retpoline_fallback is off.\n")
if spectre_v2_enabled == SPECTRE_V2_NONE
pr_err("system may be vulnerable to spectre\n")
The attempt to fall back can be disabled with the new kernel boot parameter
spectre_v2_heuristics=[retpoline_fallback=off]
Disabling retpoline fallback can also be done through debugfs
"retpoline_fallback".
Change comment block describing use_ibrs flags to use symbolic values.
Remove duplicate comment block describing flag values in use_ibrs and use_ibpb.
Cosmetic change to defs for sysctl_ibrs_enabled, sysctl_ibpb_enabled and
sysctl_lfence_enabled in preparation for adding additional sysctl_* values.
Konrad Rzeszutek Wilk [Mon, 26 Feb 2018 14:35:01 +0000 (09:35 -0500)]
x86/spectre_v2: Don't check bad microcode versions when running under hypervisors.
As:
1) We know they lie about the env anyhow (host mismatch)
2) Even if the hypervisor (Xen, KVM, VMWare, etc) provided
a valid "correct" value, it all gets to be very murky
when migration happens (do you provide the "new"
microcode of the machine?).
And in reality the cloud vendors are the ones that should make
sure that the microcode that is running is correct and we should
just sing lalalala and believe them.
Orabug: 27601736 Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Allen Pais <allen.pais@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
We need to be more dynamic. We may have retpoline disabled for some time and
then when somebody loads an proprietary module (say nvidia.ko) we can stop making
these calls (as we would be doing IBRS calls now).
As such we we use a new bit on the ibrs global value - which on bootup is set
to be enabled (if IBRS firmware is detected), and then if retpoline is selected
it is still used. But if 'spectre_v2=off' is off, then it is disabled.
The original feature uses a CPU feature, but we are much more dynamic
thanks to the SysFS and retpoline-module-check.]
Orabug: 27516477 Signed-off-by: Krish Sadhukhan <krish.sadhukhan@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Ignacio Alvarado [Wed, 28 Feb 2018 11:09:31 +0000 (11:09 +0000)]
KVM: Disable irq while unregistering user notifier
Function user_notifier_unregister should be called only once for each
registered user notifier.
Function kvm_arch_hardware_disable can be executed from an IPI context
which could cause a race condition with a VCPU returning to user mode
and attempting to unregister the notifier.
Signed-off-by: Ignacio Alvarado <ikalvarado@google.com> Cc: stable@vger.kernel.org Fixes: 18863bdd60f8 ("KVM: x86 shared msr infrastructure") Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
(cherry picked from commit 1650b4ebc99da4c137bfbfc531be4a2405f951dd)
OraBug: 27623575 Signed-off-by: Allan Xavier <allan.x.xavier@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Kris Van Hees [Thu, 18 Jan 2018 22:56:56 +0000 (17:56 -0500)]
dtrace: increase instruction limit for FBT entry probe detection
The logic used to detect whether we can place a FBT entry probe on
a function has a limit on how many instructions should be looked
at. With the occurrence of longer function prologues, that limit
must be increased. This commit changes it from 2 to 10.
Orabug: 27410742 Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Reviewed-by: Tomas Jedlicka <tomas.jedlicka@oracle.com> Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Todd Vierling [Wed, 21 Feb 2018 15:55:39 +0000 (10:55 -0500)]
trace: declare blk_add_trace_rq non-static on OL6
In an external module, there is a reference to this function done
via explicit symbol lookup. The newer compiler used for retpoline
support on OL6 changes the symbol's asm name, which causes this lookup
to fail.
While it doesn't guarantee kABI compatibility, remove the "static"
qualifier for this function, on OL6 only, to allow continuing usage of
this code in the short term.
Orabug: 27578618 Signed-off-by: Todd Vierling <todd.vierling@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Ankur Arora [Sat, 10 Feb 2018 03:25:21 +0000 (22:25 -0500)]
x86/ia32/syscall: RESTORE_EXTRA_REGS when returning from syscall
EXTRA_REGS (callee saved regs) are saved on kernel stack at entry and
zero'd. Some of these registers might be potentially used in the syscall
entry path and contain kernel state; to avoid leaking this state we
restore these registers as we exit to user-space.
Ankur Arora [Thu, 8 Feb 2018 01:05:18 +0000 (20:05 -0500)]
x86/ia32/syscall: don't do RESTORE_EXTRA_REGS prematurely
With the recent spectre mitigation changes we save the full pt_regs on
the stack and zero the extra regs. This means that for the sysenter
(and cstar) calling conventions, the pt_regs state for %ebp contains
the user %esp instead of the 6th argument.
For the straight syscall (non-tracing) path we load the real %ebp from
the user-stack and all is well. In the tracing/seccomp path, however, we
do RESTORE_EXTRA_REGS before the syscall, thus clobbering the 6th
argument (which gets replaced with the old %ebp value.)
The fix is to RESTORE_EXTRA_REGS only if we are done with syscall
handling. A side benefit is that this mitigation now also extends to
the tracing path.
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.
So this patch creates dmi/tables and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as
proposed by Jean Delvare.
Tested-by: Roy Franz <roy.franz@linaro.org> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@globallogic.com> Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Dan Duval <dan.duval@oracle.com>
(cherry picked from commit d7f96f97c4031fa4ffdb7801f9aae23e96170a6f) Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Conflict:
MAINTAINERS
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
(cherry picked from commit b9f88fe1e80c6b0178502ac52ba56251824e0e4a) Signed-off-by: Dan Duval <dan.duval@oracle.com>
Neil Horman [Mon, 22 Jan 2018 21:06:37 +0000 (16:06 -0500)]
vmxnet3: repair memory leak
with the introduction of commit b0eb57cb97e7837ebb746404c2c58c6f536f23fa, it appears that rq->buf_info
is improperly handled. While it is heap allocated when an rx queue is
setup, and freed when torn down, an old line of code in
vmxnet3_rq_destroy was not properly removed, leading to rq->buf_info[0]
being set to NULL prior to its being freed, causing a memory leak, which
eventually exhausts the system on repeated create/destroy operations
(for example, when the mtu of a vmxnet3 interface is changed
frequently.
Fix is pretty straight forward, just move the NULL set to after the
free.
Tested by myself with successful results
Applies to net, and should likely be queued for stable, please
Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Reported-By: boyang@redhat.com CC: boyang@redhat.com CC: Shrikrishna Khare <skhare@vmware.com> CC: "VMware, Inc." <pv-drivers@vmware.com> CC: David S. Miller <davem@davemloft.net> Acked-by: Shrikrishna Khare <skhare@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 27479086
(cherry picked from commit 848b159835ddef99cc4193083f7e786c3992f580) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Jarod Wilson [Tue, 4 Apr 2017 21:32:42 +0000 (17:32 -0400)]
bonding: attempt to better support longer hw addresses
People are using bonding over Infiniband IPoIB connections, and who knows
what else. Infiniband has a hardware address length of 20 octets
(INFINIBAND_ALEN), and the network core defines a MAX_ADDR_LEN of 32.
Various places in the bonding code are currently hard-wired to 6 octets
(ETH_ALEN), such as the 3ad code, which I've left untouched here. Besides,
only alb is currently possible on Infiniband links right now anyway, due
to commit 1533e7731522, so the alb code is where most of the changes are.
One major component of this change is the addition of a bond_hw_addr_copy
function that takes a length argument, instead of using ether_addr_copy
everywhere that hardware addresses need to be copied about. The other
major component of this change is converting the bonding code from using
struct sockaddr for address storage to struct sockaddr_storage, as the
former has an address storage space of only 14, while the latter is 128
minus a few, which is necessary to support bonding over device with up to
MAX_ADDR_LEN octet hardware addresses. Additionally, this probably fixes
up some memory corruption issues with the current code, where it's
possible to write an infiniband hardware address into a sockaddr declared
on the stack.
Lightly tested on a dual mlx4 IPoIB setup, which properly shows a 20-octet
hardware address now:
Bonding Mode: fault-tolerance (active-backup) (fail_over_mac active)
Primary Slave: mlx4_ib0 (primary_reselect always)
Currently Active Slave: mlx4_ib0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 100
Down Delay (ms): 100
Slave Interface: mlx4_ib0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr:
80:00:02:08:fe:80:00:00:00:00:00:00:e4:1d:2d:03:00:1d:67:01
Slave queue ID: 0
Slave Interface: mlx4_ib1
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr:
80:00:02:09:fe:80:00:00:00:00:00:01:e4:1d:2d:03:00:1d:67:02
Slave queue ID: 0
Also tested with a standard 1Gbps NIC bonding setup (with a mix of
e1000 and e1000e cards), running LNST's bonding tests.
CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: netdev@vger.kernel.org Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit faeeb317a5615076dff1ff44b51e862e6064dbd0)
Gerd Rausch traced the stack corruption from 27535442 to this patch, so
I'm rolling it in with my other retpoline fix ("x86/spectre: move
microcode check before kernel ibrs flags are set").
Suggested-by: Gerd Rausch <gerd.rausch@oracle.com> Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com>
Bart Van Assche [Fri, 2 Jun 2017 21:21:57 +0000 (14:21 -0700)]
scsi: Make __scsi_remove_device go straight from BLOCKED to DEL
If a device is blocked, make __scsi_remove_device() cause it to
transition to the DEL state. This means that all the commands issued in
.shutdown() will error in the mid-layer, thus making the removal proceed
without being stopped.
This patch is a slightly modified version of a patch from James
Bottomley. This patch avoids that the following lockup occurs:
Reported-by: Israel Rukshin <israelr@mellanox.com> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Israel Rukshin <israelr@mellanox.com> Cc: Max Gurtovoy <maxg@mellanox.com> Cc: Benjamin Block <bblock@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Orabug: 27546768
(cherry picked from commit 255ee9320e5dc46173bb94dbcd68e32f11fc10a9) Signed-off-by: Kyle Fortin <kyle.fortin@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Conflicts:
drivers/scsi/scsi_sysfs.c
Bart Van Assche [Fri, 2 Jun 2017 21:21:55 +0000 (14:21 -0700)]
scsi: Protect SCSI device state changes with a mutex
Serializing SCSI device state changes avoids that two state changes can
occur concurrently, e.g. the state changes in scsi_target_block() and
__scsi_remove_device(). This serialization is essential to make patch
"Make __scsi_remove_device go straight from BLOCKED to DEL" work
reliably.
Enable this mechanism for all scsi_target_*block() callers but not for
the scsi_internal_device_unblock() calls from the mpt3sas driver because
that driver can call scsi_internal_device_unblock() from atomic context.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Orabug: 27546768
(cherry picked from commit 0db6ca8a5e1ea585795db3643ec7d50fc8cb1aff) Signed-off-by: Kyle Fortin <kyle.fortin@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Conflicts:
drivers/scsi/scsi_error.c
drivers/scsi/scsi_lib.c
include/scsi/scsi_device.h
Use kmalloc'd state_mutex_kabi in scsi_device to fit new field
state_mutex in KABI reserved space.
Bart Van Assche [Fri, 2 Jun 2017 21:21:56 +0000 (14:21 -0700)]
scsi: Introduce scsi_start_queue()
This patch does not change any functionality.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Cc: Israel Rukshin <israelr@mellanox.com> Cc: Max Gurtovoy <maxg@mellanox.com> Cc: Benjamin Block <bblock@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Orabug: 27546768
(cherry picked from commit 66483a4a9f34427e3d6ec87d8e583f5d2a7cbb76) Signed-off-by: Kyle Fortin <kyle.fortin@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Wei Fang [Tue, 13 Dec 2016 01:25:21 +0000 (09:25 +0800)]
scsi: avoid a permanent stop of the scsi device's request queue
A race between scanning and fc_remote_port_delete() may result in a
permanent stop if the device gets blocked before scsi_sysfs_add_sdev()
and unblocked after. The reason is that blocking a device sets both the
SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED. However,
scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the
device to be ignored by scsi_target_unblock() and thus never have its
QUEUE_FLAG_STOPPED cleared leading to a device which is apparently
running but has a stopped queue.
We actually have two places where SDEV_RUNNING is set: once in
scsi_add_lun() which respects the blocked flag and once in
scsi_sysfs_add_sdev() which doesn't. Since the second set is entirely
spurious, simply remove it to fix the problem.
Cc: <stable@vger.kernel.org> Reported-by: Zengxi Chen <chenzengxi@huawei.com> Signed-off-by: Wei Fang <fangwei1@huawei.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Orabug: 27546768
(cherry picked from commit d2a145252c52792bc59e4767b486b26c430af4bb) Signed-off-by: Kyle Fortin <kyle.fortin@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Ka-Cheong Poon [Mon, 12 Feb 2018 16:39:21 +0000 (08:39 -0800)]
IB/ipoib: ioctls IPOIBACLNADD and IPOIBACLNGET do not work correctly
There is a problem in using the ips pointer in ipoib_do_ioctl(). It
does incorrect pointer arithmetic for the new ioctls since ips is an
u32 pointer. It should use a struct in6_addr pointer instead of using
the ips pointer directly. The end result is that it does not work
correctly if a list of ACLs are modified.
Daniel Jordan [Tue, 13 Feb 2018 14:52:59 +0000 (06:52 -0800)]
x86/spectre: move microcode check before kernel ibrs flags are set
The check for bad spectre microcode, which prints "disabling
SPEC_CTRL/IBRS", happens after the kernel turns on its flags for "IBRS
supported" and "IBRS in use"
When the microcode check runs, it disables the CPU capability but the
kernel flags have already been set based on the disabled capability.
So to fix it, we should move the microcode check to before the kernel
flags are set.
Orabug: 27542331
CVE: CVE-2017-5715 Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Todd Vierling [Tue, 13 Feb 2018 15:26:57 +0000 (10:26 -0500)]
x86: make HAVE_FENTRY dependent on !SIMULATE_GCC44_KABI
Something about the uek-rpm build doesn't always bubble config lines
down into the built RPMs properly. So force the issue by making use of
the special kABI flag introduced for OL6; if _not_ present, set
HAVE_FENTRY in its original place in arch/x86/Kconfig.
Orabug: 27540463 Signed-off-by: Todd Vierling <todd.vierling@oracle.com> Reviewed-by: Victor Erminpour <victor.erminpour@oracle.com>
Todd Vierling [Fri, 9 Feb 2018 21:58:34 +0000 (16:58 -0500)]
kernel: on OL6 only, simulate the gcc 4.4 kABI for __stack_chk_fail()
The __visible linkage changes st_value calculation for genksyms on newer
compilers such as OL7's 4.8 and SCL's 4.9. However, this symbol is in
the kABI whitelist and needs to retain its old st_value, even though the
guts of the compiled function have not changed.
Add a special directive, CONFIG_SIMULATE_GCC44_KABI, which will mask the
__visible qualifier at genksyms time; and use it only on OL6 builds.
Orabug: 27509351 Signed-off-by: Todd Vierling <todd.vierling@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Todd Vierling [Fri, 9 Feb 2018 20:34:50 +0000 (15:34 -0500)]
uek-rpm: configs: Don't set HAVE_FENTRY on OL6 builds.
CONFIG_HAVE_FENTRY turns on a *conditional* addition of compile time
flags in the top level Makefile (-mfentry -DCC_USES_FENTRY). The OL6
stock gcc-4.4 code doesn't support this, but gcc 4.8+ does. This
changes the way function trace preambles work on the newer compilers,
which breaks kABI.
To do this effectively, the option needs to be removed from
arch/x86/Kconfig ("select HAVE_FENTRY if X86_64") so that it can be
set optionally in the RPM build configs. The OL7 configs properly
contain CONFIG_HAVE_FENTRY=y, so those will continue to build the same.
Orabug: 27509351 Signed-off-by: Todd Vierling <todd.vierling@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
KarimAllah Ahmed [Thu, 1 Feb 2018 21:59:45 +0000 (22:59 +0100)]
KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL
[ Based on a patch from Ashok Raj <ashok.raj@intel.com> ]
Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for
guests that will only mitigate Spectre V2 through IBRS+IBPB and will not
be using a retpoline+IBPB based approach.
To avoid the overhead of saving and restoring the MSR_IA32_SPEC_CTRL for
guests that do not actually use the MSR, only start saving and restoring
when a non-zero is written to it.
No attempt is made to handle STIBP here, intentionally. Filtering STIBP
may be added in a future patch, which may require trapping all writes
if we don't want to pass it through directly to the guest.
[dwmw2: Clean up CPUID bits, save/restore manually, handle reset]
Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Jim Mattson <jmattson@google.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Jun Nakajima <jun.nakajima@intel.com> Cc: kvm@vger.kernel.org Cc: Dave Hansen <dave.hansen@intel.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Ashok Raj <ashok.raj@intel.com> Link: https://lkml.kernel.org/r/1517522386-18410-5-git-send-email-karahmed@amazon.de
(cherry picked from commit d28b387fb74da95d69d2615732f50cceb38e9a4d)
Orabug: 27525575 Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[Backport:
There is a lot that this patch does not pick up - but the most important we need
to pick up is the wrmsr(0x48, 0) when the retpoline is used. That is we cannot leave
the MSR048 hanging around with the guest value. The reason is that on a particular
CPU we may schedule another guest vCPU (a different) one, and the check on whether
to write the MSR0x48 is if 'vmx->spec_ctrl' (the vmx is tied to a specific VCPU).
Which means we may not write the prpoer guest vCPU MSR value in and have the
stale one in the guest.!]
Konrad Rzeszutek Wilk [Fri, 9 Feb 2018 22:19:01 +0000 (17:19 -0500)]
x86/spectre_v2: Disable IBRS if spectre_v2=off
We found some interesting behaviors when booting on IBRS enabled
hardware where 'spectre_v2=off' did not disable IBRS completely.
That is during the bootup we received some interrupts which
meant that we set the MSR 0x48 to 1.. and then when we got
to the code that handles 'spectre_v2=off' we would just
call 'set_ibrs_disabled' which would clear the in_use parameter.
But that would not clear the wedged MSR 048 being set to 1.
Which means we would continue on with both retpoline and IBRS on!
The fix is rather simple - clear the MSR as well.
Note that if 'noibrs' was used - then we would have disabled the
IBRS _before_ we got the interrupt, as 'noibrs' is an early parameter.
OraBug: 27525754 Reported-by: Yao-Min Chen <yaomin.chen@oracle.com> Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com> Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Joao Martins [Fri, 2 Feb 2018 17:42:33 +0000 (17:42 +0000)]
xenbus: track caller request id
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses") optimized xenbus concurrent accesses but in doing so
broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in
charge of xenbus message exchange with the correct header and body. Now,
after the mentioned commit the replies received by application will no
longer have the header req_id echoed back as it was on request (see
specification below for reference), because that particular field is being
overwritten by kernel.
struct xsd_sockmsg
{
uint32_t type; /* XS_??? */
uint32_t req_id;/* Request identifier, echoed in daemon's response. */
uint32_t tx_id; /* Transaction id (0 if not related to a transaction). */
uint32_t len; /* Length of data following this. */
/* Generally followed by nul-terminated string(s). */
};
Before there was only one request at a time so req_id could simply be
forwarded back and forth. To allow simultaneous requests we need a
different req_id for each message thus kernel keeps a monotonic increasing
counter for this field and is written on every request irrespective of
userspace value.
Forwarding again the req_id on userspace requests is not a solution because
we would open the possibility of userspace-generated req_id colliding with
kernel ones. So this patch instead takes another route which is to
artificially keep user req_id while keeping the xenbus logic as is. We do
that by saving the original req_id before xs_send(), use the private kernel
counter as req_id and then once reply comes and was validated, we restore
back the original req_id.
Darren Kenny [Fri, 9 Feb 2018 14:17:04 +0000 (14:17 +0000)]
x86/spectre_v2: Remove 0xc2 from spectre_bad_microcodes
According to the latest microcode update from Intel (on Feb 8, 2018) on
Skylake we should be using the microcode revisions 0xC2***, so we need
to remove that from the blacklist now.
Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tim Chen [Thu, 8 Feb 2018 21:52:42 +0000 (16:52 -0500)]
x86/speculation: Use Indirect Branch Prediction Barrier in context switch
This patch is a subset of the changes in the upstream commit 18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7. Since we don't have 'ctx_id' in
mm_context_t in UEK4, we can't check whether the context ID of the new
task is the same as that of the previous one. In this patch, we flush indirect
branches when switching into a process that marked itself non-dumpable.
This protects high value processes like gpg better, without having too high
performance overhead.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: ak@linux.intel.com Cc: karahmed@amazon.de Cc: arjan@linux.intel.com Cc: torvalds@linux-foundation.org Cc: linux@dominikbrodowski.net Cc: peterz@infradead.org Cc: bp@alien8.de Cc: luto@kernel.org Cc: pbonzini@redhat.com Cc: gregkh@linux-foundation.org Link: https://lkml.kernel.org/r/1517263487-3708-1-git-send-email-dwmw@amazon.co.uk
Orabug: 27524608 Signed-off-by: Krish Sadhukhan <krish.sadhukhan@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Konrad Rzeszutek Wilk [Mon, 5 Feb 2018 19:34:55 +0000 (14:34 -0500)]
x86/spectre_v2: Add spectre_v2_heuristics=
As we have one already in the tree:
x86/spectre: Favor IBRS on Skylake over retpoline
But we may want a knob to turn that off altgoether. The
hard to remember spectre_v2_heuristics=off or
spectre_v2_heuristics=skylake=off
will take care of disabling that optimization.
Orabug: 27477743
CVE: CVE-2017-5715 Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Darren Kenny [Fri, 2 Feb 2018 19:12:20 +0000 (19:12 +0000)]
x86/speculation: Fix typo IBRS_ATT, which should be IBRS_ALL
Fixes: 117cc7a908c83 ("x86/retpoline: Fill return stack buffer on vmexit") Signed-off-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Link: https://lkml.kernel.org/r/20180202191220.blvgkgutojecxr3b@starbug-vm.ie.oracle.com
(cherry picked from commit af189c95a371b59f493dbe0f50c0a09724868881)
Orabug: 27477743
CVE: CVE-2017-5715 Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
David Woodhouse [Fri, 2 Feb 2018 18:59:51 +0000 (13:59 -0500)]
x86/cpufeatures: Clean up Spectre v2 related CPUID flags
We want to expose the hardware features simply in /proc/cpuinfo as "ibrs",
"ibpb" and "stibp". Since AMD has separate CPUID bits for those, use them
as the user-visible bits.
When the Intel SPEC_CTRL bit is set which indicates both IBRS and IBPB
capability, set those (AMD) bits accordingly. Likewise if the Intel STIBP
bit is set, set the AMD STIBP that's used for the generic hardware
capability.
Hide the rest from /proc/cpuinfo by putting "" in the comments. Including
RETPOLINE and RETPOLINE_AMD which shouldn't be visible there. There are
patches to make the sysfs vulnerabilities information non-readable by
non-root, and the same should apply to all information about which
mitigations are actually in use. Those *shouldn't* appear in /proc/cpuinfo.
The feature bit for whether IBPB is actually used, which is needed for
ALTERNATIVEs, is renamed to X86_FEATURE_USE_IBPB.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Conflicts:
arch/x86/include/asm/cpufeatures.h
arch/x86/kernel/cpu/bugs.c
arch/x86/kernel/cpu/intel.c
[Backport: The majority of the changes are to make 'retpoline' and friends
not show up. Also fix so that instead of 'spec_ctrl' we have 'ibrs'.
The rest we had already]
Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Conflicts:
arch/x86/include/asm/cpufeatures.h
arch/x86/kernel/cpu/bugs.c
[The original version of this patch doesn't set X86_FEATURE_IBPB, so do
it ourselves. Given X86_FEATURE_SPEC_CTRL (i.e. CPUID.07.[EDX.26])[*],
always set X86_FEATURE_IBPB in scattered.c. This omission did not
impact the actual IBPB functionality as the code uses 'ibpb_inuse': the
only thing missing was the 'ibpb' string in /proc/cpuinfo.
Since we already have code to enable IBPB (e.g. switch_mm_irqs_off),
there is no point in backporting indirect_branch_prediction_barrier from
this patch.]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
David Woodhouse [Thu, 25 Jan 2018 16:14:14 +0000 (16:14 +0000)]
x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 microcodes
This doesn't refuse to load the affected microcodes; it just refuses to
use the Spectre v2 mitigation features if they're detected, by clearing
the appropriate feature bits.
The AMD CPUID bits are handled here too, because hypervisors *may* have
been exposing those bits even on Intel chips, for fine-grained control
of what's available.
It is non-trivial to use x86_match_cpu() for this table because that
doesn't handle steppings. And the approach taken in commit bd9240a18
almost made me lose my lunch.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Conflicts:
arch/x86/kernel/cpu/intel.c
[Our resolution to 5d10cbc91d9e x86/cpufeatures: Add AMD feature bits for Speculation Control
is different, so we still clear the right bits if there (or would be)are AMD machines
with bad microcode]
Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
David Woodhouse [Thu, 25 Jan 2018 16:14:13 +0000 (16:14 +0000)]
x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
Also, for CPUs which don't speculate at all, don't report that they're
vulnerable to the Spectre variants either.
Leave the cpu_no_meltdown[] match table with just X86_VENDOR_AMD in it
for now, even though that could be done with a simple comparison, on the
assumption that we'll have more to add.
Based on suggestions from Dave Hansen and Alan Cox.
[Backport:
s/X86_FEATURE_ARCH_CAPABILITIES/X86_FEATURE_IA32_ARCH_CAPS/
Fix compiler warnings by removing __init/__initdata from
cpu_no_speculation, cpu_no_meltdown, and cpu_vulnerable_to_meltdown
] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
David Woodhouse [Thu, 25 Jan 2018 16:14:11 +0000 (16:14 +0000)]
x86/cpufeatures: Add AMD feature bits for Speculation Control
AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel.
See http://lkml.kernel.org/r/2b3e25cc-286d-8bd0-aeaf-9ac4aae39de8@amd.com
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: gnomes@lxorguk.ukuu.org.uk Cc: ak@linux.intel.com Cc: ashok.raj@intel.com Cc: dave.hansen@intel.com Cc: karahmed@amazon.de Cc: arjan@linux.intel.com Cc: torvalds@linux-foundation.org Cc: peterz@infradead.org Cc: bp@alien8.de Cc: pbonzini@redhat.com Cc: tim.c.chen@linux.intel.com Cc: gregkh@linux-foundation.org Link: https://lkml.kernel.org/r/1516896855-7642-4-git-send-email-dwmw@amazon.co.uk
Conflicts:
arch/x86/include/asm/cpufeatures.h
[Upstream has the NCAPINTS raised so there is another array to stuff all the
0x80000008 cpuid leaf in. But we don't have that so we just toggle the global
ones]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Konrad Rzeszutek Wilk [Fri, 2 Feb 2018 03:56:00 +0000 (22:56 -0500)]
x86/spectre_v2: Add VMEXIT_FILL_RSB instead of RETPOLINE
The backport of "x86/retpoline: Fill return stack buffer on vmexit"
made the full stuffing of RSB only enabled if the kernel had
selected X86_FEATURE_RETPOLINE.
But if we are using IBRS we still want the full RSB stuffing
as it was prior to the backport.
Since we have both retpoline and ibrs wanting it we introduce
a new feature to enable the common mitigation that both of them
need.
Konrad Rzeszutek Wilk [Thu, 1 Feb 2018 21:20:54 +0000 (16:20 -0500)]
x86/spectre: If IBRS is enabled disable "Filling RSB on context switch"
As that is only needed if the machine is running IBRS and !SMEP.
The comment above the conditional says it all:
Skylake era CPUs have a separate issue with *underflow* of the
RSB, when they will predict 'ret' targets from the generic BTB.
The proper mitigation for this is IBRS. If IBRS is not supported
or deactivated in favour of retpolines the RSB fill on context
.. and if we have IBRS then we should ignore this conditional.
Note that the check (!SMEP) and using the STUFF_RSB is already
done in:
x86/spectre_v2: Figure out if STUFF_RSB macro needs to be used.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Konrad Rzeszutek Wilk [Thu, 1 Feb 2018 20:47:19 +0000 (15:47 -0500)]
KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL
This is an adopation of what is being posted upstream.
The issue here is that guest kernels such as Windows
needs IBRS to solve their spectre_v2 mitigation.
And since our kernel can do either IBRS or retpoline
we need to be aware of both.
(We are ignoring for right now the situation in which
the microcode is not loaded and we want to emulate IBRS)
In short:
1) If the CPU has microcode, and host uses IBRS we need
to save the MSR during VMEXIT and write our IBRS value.
Also before VMENTER we need to write the guest MSR value.
2) If the host kernel uses retpoline we need to WRMSR the
guest MSR value on VMENTER, but we are optimizing by only
doing it if it a non-zero value.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Konrad Rzeszutek Wilk [Thu, 1 Feb 2018 16:45:41 +0000 (11:45 -0500)]
x86/spectre: Update sysctl values if toggled only by set_{ibrs,ibpb}_disabled
As otherwise we will report the wrong values in the
/sys/kernel/debug/x86/{ibrs,ipbp}_enabled at first
bootup - that is if you have 'noibrs' on the command line.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Andi Kleen [Thu, 4 Jan 2018 14:37:08 +0000 (14:37 +0000)]
retpoline/module: Taint kernel for missing retpoline in module
There's a risk that a kernel that has full retpoline mitigations
becomes vulnerable when a module gets loaded that hasn't been
compiled with the right compiler or the right option.
We cannot fix it, but should at least warn the user when that
happens.
Add a flag to each module if it has been compiled with RETPOLINE
When the a module hasn't been compiled with a retpoline
aware compiler, print a warning and set a taint flag.
For modules it is checked at compile time, however it cannot
check assembler or other non compiled objects used in the module link.
Due to lack of better letter it uses taint option 'Z'
We only set the taint flag for incorrectly compiled modules
now, not for the main kernel, which already has other
report mechanisms.
Also make sure to report vulnerable for spectre if such a module
has been loaded.
v2: Change warning message
v3: Port to latest tree Cc: jeyu@kernel.org Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
(cherry picked from commit abc01f3c4bbd927f5e47cc6dff99a76a393d1bbe)
Orabug: 27477743
CVE: CVE-2017-5715 Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Conflicts:
Documentation/oops-tracing.txt
(dmj: patch had Documentation/admin-guide/tainted-kernels.rst)
arch/x86/kernel/cpu/bugs_64.c
(dmj: patch had arch/x86/kernel/cpu/bugs.c)
include/linux/kernel.h
kernel/module.c
kernel/panic.c Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
On context switch from a shallow call stack to a deeper one, as the CPU
does 'ret' up the deeper side it may encounter RSB entries (predictions for
where the 'ret' goes to) which were populated in userspace.
This is problematic if neither SMEP nor KPTI (the latter of which marks
userspace pages as NX for the kernel) are active, as malicious code in
userspace may then be executed speculatively.
Overwrite the CPU's return prediction stack with calls which are predicted
to return to an infinite loop, to "capture" speculation if this
happens. This is required both for retpoline, and also in conjunction with
IBRS for !SMEP && !KPTI.
On Skylake+ the problem is slightly different, and an *underflow* of the
RSB may cause errant branch predictions to occur. So there it's not so much
overwrite, as *filling* the RSB to attempt to prevent it getting
empty. This is only a partial solution for Skylake+ since there are many
other conditions which may result in the RSB becoming empty. The full
solution on Skylake+ is to use IBRS, which will prevent the problem even
when the RSB becomes empty. With IBRS, the RSB-stuffing will not be
required on context switch.
[ tglx: Added missing vendor check and slighty massaged comments and
changelog ]
[js] backport to 4.4 -- __switch_to_asm does not exist there, we
have to patch the switch_to macros for both x86_32 and x86_64.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel <riel@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: thomas.lendacky@amd.com Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Kees Cook <keescook@google.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Cc: Paul Turner <pjt@google.com> Link: https://lkml.kernel.org/r/1515779365-9032-1-git-send-email-dwmw@amazon.co.uk Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 18bb117d1b7690181346e6365c6237b6ceaac4c4)
Orabug: 27477743
CVE: CVE-2017-5715 Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Conflicts:
arch/x86/include/asm/cpufeature.h
(dmj: bumped all uek4-specific microcode features up one)
arch/x86/include/asm/switch_to.h
arch/x86/kernel/cpu/bugs_64.c
(dmj:
- patch had arch/x86/kernel/cpu/bugs.c
- preserved X86_FEATURE_RSB_CTXSW check in case of IBRS) Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Since indirect jump instructions will be replaced by jump
to __x86_indirect_thunk_*, those jmp instruction must be
treated as an indirect jump. Since optprobe prohibits to
optimize probes in the function which uses an indirect jump,
it also needs to find out the function which jump to
__x86_indirect_thunk_* and disable optimization.
Add a check that the jump target address is between the
__indirect_thunk_start/end when optimizing kprobe.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Cc: Andi Kleen <ak@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Link: https://lkml.kernel.org/r/151629212062.10241.6991266100233002273.stgit@devbox Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6cb73eb8045157ea280f0a047777ea1f56547375)
Orabug: 27477743
CVE: CVE-2017-5715 Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Mark __x86_indirect_thunk_* functions as blacklist for kprobes
because those functions can be called from anywhere in the kernel
including blacklist functions of kprobes.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Cc: Andi Kleen <ak@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Link: https://lkml.kernel.org/r/151629209111.10241.5444852823378068683.stgit@devbox Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9b8bd0d3586842716f5673e7a0922a9c9e1fcbfd)
Orabug: 27477743
CVE: CVE-2017-5715 Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Introduce start/end markers of __x86_indirect_thunk_* functions.
To make it easy, consolidate .text.__x86.indirect_thunk.* sections
to one .text.__x86.indirect_thunk section and put it in the
end of kernel text section and adds __indirect_thunk_start/end
so that other subsystem (e.g. kprobes) can identify it.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Cc: Andi Kleen <ak@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Link: https://lkml.kernel.org/r/151629206178.10241.6828804696410044771.stgit@devbox Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 799dc737680a8074a0c7c2d3426b85f4c439377f)
Orabug: 27477743
CVE: CVE-2017-5715 Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Allow architectures to create asm/asm-prototypes.h file that
provides C prototypes for exported asm functions, which enables
proper CRC versions to be generated for them.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
[jkosina@suse.cz: folded cc6acc11cad1 fixup in as well ] Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ff535919c1366b0218113f95c447d92c3aac0c1f)
Orabug: 27477743
CVE: CVE-2017-5715 Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
The PAUSE instruction is currently used in the retpoline and RSB filling
macros as a speculation trap. The use of PAUSE was originally suggested
because it showed a very, very small difference in the amount of
cycles/time used to execute the retpoline as compared to LFENCE. On AMD,
the PAUSE instruction is not a serializing instruction, so the pause/jmp
loop will use excess power as it is speculated over waiting for return
to mispredict to the correct target.
The RSB filling macro is applicable to AMD, and, if software is unable to
verify that LFENCE is serializing on AMD (possible when running under a
hypervisor), the generic retpoline support will be used and, so, is also
applicable to AMD. Keep the current usage of PAUSE for Intel, but add an
LFENCE instruction to the speculation trap for AMD.
The same sequence has been adopted by GCC for the GCC generated retpolines.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov <bp@alien8.de> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Cc: Rik van Riel <riel@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Paul Turner <pjt@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Cc: Kees Cook <keescook@google.com> Link: https://lkml.kernel.org/r/20180113232730.31060.36287.stgit@tlendack-t1.amdoffice.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit fba063e6dfb413e06b9daa5d45b164761172f5ed)
Orabug: 27477743
CVE: CVE-2017-5715 Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Remove the compile time warning when CONFIG_RETPOLINE=y and the compiler
does not have retpoline support. Linus rationale for this is:
It's wrong because it will just make people turn off RETPOLINE, and the
asm updates - and return stack clearing - that are independent of the
compiler are likely the most important parts because they are likely the
ones easiest to target.
And it's annoying because most people won't be able to do anything about
it. The number of people building their own compiler? Very small. So if
their distro hasn't got a compiler yet (and pretty much nobody does), the
warning is just annoying crap.
It is already properly reported as part of the sysfs interface. The
compile-time warning only encourages bad things.
Fixes: 76b043848fd2 ("x86/retpoline: Add initial retpoline support") Requested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel <riel@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: thomas.lendacky@amd.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Kees Cook <keescook@google.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Link: https://lkml.kernel.org/r/CA+55aFzWgquv4i6Mab6bASqYXg3ErV3XDFEYf=GEcCDQg5uAtw@mail.gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 451725c3e785dfc3ede6c65184b96c213181995a)
Orabug: 27477743
CVE: CVE-2017-5715 Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
In accordance with the Intel and AMD documentation, we need to overwrite
all entries in the RSB on exiting a guest, to prevent malicious branch
target predictions from affecting the host kernel. This is needed both
for retpoline and for IBRS.
[ak: numbers again for the RSB stuffing labels]
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel <riel@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: thomas.lendacky@amd.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Kees Cook <keescook@google.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Cc: Paul Turner <pjt@google.com> Link: https://lkml.kernel.org/r/1515755487-8524-1-git-send-email-dwmw@amazon.co.uk Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Razvan Ghitulete <rga@amazon.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit eebc3f8adee0a6f43a4789ef0bf5c5b35de8cfe4)
Removed now-unused stuff_RSB function from uek4's 60f856955c1b
("x86/kvm: Pad RSB on VM transition").
Orabug: 27477743
CVE: CVE-2017-5715 Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Conflicts:
arch/x86/kvm/svm.c
arch/x86/kvm/vmx.c Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com>
projects / users / jedix / linux-maple.git / log