- 13 Mar, 2018 40 commits
-
-
Tom Lendacky authored
CVE-2017-5753 (Spectre v1 Intel -> upstream) BugLink: http://bugs.launchpad.net/bugs/1754375 commit e4d0e84e upstream. To aid in speculation control, make LFENCE a serializing instruction since it has less overhead than MFENCE. This is done by setting bit 1 of MSR 0xc0011029 (DE_CFG). Some families that support LFENCE do not have this MSR. For these families, the LFENCE instruction is already serializing. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Paul Turner <pjt@google.com> Link: https://lkml.kernel.org/r/20180108220921.12580.71694.stgit@tlendack-t1.amdoffice.netSigned-off-by:
Razvan Ghitulete <rga@amazon.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Stefan Bader authored
CVE-2017-5753 (Spectre v1 Intel -> upstream) BugLink: http://bugs.launchpad.net/bugs/1754375 This reverts commit b9d71080 to be replaced by upstream changes. Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1754375 commit cc622420 upstream. Enabling gcov is counterproductive to compile testing: it significantly increases the kernel image size, compile time, and it produces lots of false positive "may be used uninitialized" warnings as the result of missed optimizations. This is in line with how UBSAN_SANITIZE_ALL and PROFILE_ALL_BRANCHES work, both of which have similar problems. With an ARM allmodconfig kernel, I see the build time drop from 283 minutes CPU time to 225 minutes, and the vmlinux size drops from 43MB to 26MB. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Signed-off-by:
Michal Marek <mmarek@suse.com> Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1754076 The error message: [Fri Feb 16 13:42:13 2018] i2c-thunderx 0000:01:09.4: unhandled state: 0 is mis-leading as state 0 (bus error) is not an unknown state. Return -EIO as before but avoid printing the message. Also rename STAT_ERROR to STATE_BUS_ERROR. Signed-off-by:
Jan Glauber <jglauber@cavium.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> (cherry picked from commit 7c424679) Signed-off-by:
dann frazier <dann.frazier@canonical.com> Acked-by:
-
Ursula Braun authored
BugLink: http://bugs.launchpad.net/bugs/1750810 For a memory range/skb where the last byte falls onto a page boundary (ie. 'end' is of the form xxx...xxx001), the PFN_UP() part of the calculation currently doesn't round up to the next PFN due to an off-by-one error. Thus qeth believes that the skb occupies one page less than it actually does, and may select a IO buffer that doesn't have enough spare buffer elements to fit all of the skb's data. HW detects this as a malformed buffer descriptor, and raises an exception which then triggers device recovery. Fixes: 2863c613 ("qeth: refactor calculation of SBALE count") Signed-off-by:
Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by:
Julian Wiedmann <jwi@linux.vnet.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (back ported from commit 89271c65) [jwi: backport to older kernels, so that it also Fixes: 51aa165c ("qeth: fix page breaks in hw headers")] Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
-
Michał Kępień authored
BugLink: http://bugs.launchpad.net/bugs/1745130 Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any, which may be useful on laptops with a single "radio LED" and multiple radio transmitters. The trigger is meant to turn a LED on whenever there is at least one radio transmitter active and turn it off otherwise. Signed-off-by:
Michał Kępień <kernel@kempniu.pl> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> (back ported from commit 9b8e34e2) Signed-off-by:
-
Sanjay Kumar Konduri authored
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1753438 BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1753439 We are redownloading the firmware after S4 resume. We observed in stress test that mac80211 sometimes gives power save request after resume which causes the firmware in bad state. mac_ops_resumed flag is added to skip that request until initialisation is done. Signed-off-by:
Sanjay Kumar Konduri <sanjay.konduri@redpinesignals.com> Signed-off-by:
Amitkumar Karwar <amit.karwar@redpinesignals.com> Acked-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Signed-off-by:
-
Sanjay Kumar Konduri authored
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1753438 BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1753439 As in coex mode radio will be shared between BT and WLAN, we need enable deep sleep before scan. Before scan deep sleep can be disabled and re-enabed after scan. For any TX frame before assoc, deep sleep shall be disable. Signed-off-by:
-
Prameela Rani Garnepudi authored
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1753438 BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1753439 In S4 regressions, at times card write failure issue is observed. This is because of sending vap delete frame before peer delete. Root cause of the issue is, adding peer notify frame to the head of management queue. This is corrected and S4 is working fine. Signed-off-by:
Prameela Rani Garnepudi <prameela.garnepudi@redpinesignals.com> Signed-off-by:
-
Prameela Rani Garnepudi authored
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1753438 BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1753439 At SDIO restore ieee80211_restart_hw() is getting called to restart all MAC operations. This step is not required. eturning 1 from mac80211_resume() will serve this purpose. Above method adding up some races in calling functions because of timing issues. Signed-off-by:
-
Ursula Braun authored
BugLink: http://bugs.launchpad.net/bugs/1750568 af_iucv socket programs with HiperSockets as transport make use of the qdio completion queue. Running such an af_iucv socket program may result in a crash: [90341.677709] Oops: 0038 ilc:2 [#1] SMP [90341.677743] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.6.0-20160720.0.0e86ec7.5e62689.fc23.s390xperformance #1 [90341.677744] Hardware name: IBM 2964 N96 703 (LPAR) [90341.677746] task: 00000000edb79f00 ti: 00000000edb84000 task.ti: 00000000edb84000 [90341.677748] Krnl PSW : 0704d00180000000 000000000075bc50 (qeth_qdio_input_handler+0x258/0x4e0) [90341.677756] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 000003d10391e900 0000000000000001 00000000e61e6000 0000000000000005 [90341.677759] 0000000000a9e6ec 5420040001a77400 0000000000000001 000000000000006f [90341.677761] 00000000e0d83f00 0000000000000003 0000000000000010 5420040001a77400 [90341.677784] 000000007ba8b000 0000000000943fd0 000000000075bc4e 00000000ed3b3c10 [90341.677793] Krnl Code: 000000000075bc42: e320cc180004 lg %r2,3096(%r12) 000000000075bc48: c0e5ffffc5cc brasl %r14,7547e0 #000000000075bc4e: 1816 lr %r1,%r6 >000000000075bc50: ba19b008 cs %r1,%r9,8(%r11) 000000000075bc54: ec180041017e cij %r1,1,8,75bcd6 000000000075bc5a: 5810b008 l %r1,8(%r11) 000000000075bc5e: ec16005c027e cij %r1,2,6,75bd16 000000000075bc64: 5090b008 st %r9,8(%r11) [90341.677807] Call Trace: [90341.677810] ([<000000000075bbc0>] qeth_qdio_input_handler+0x1c8/0x4e0) [90341.677812] ([<000000000070efbc>] qdio_kick_handler+0x124/0x2a8) [90341.677814] ([<0000000000713570>] __tiqdio_inbound_processing+0xf0/0xcd0) [90341.677818] ([<0000000000143312>] tasklet_action+0x92/0x120) [90341.677823] ([<00000000008b6e72>] __do_softirq+0x112/0x308) [90341.677824] ([<0000000000142bce>] irq_exit+0xd6/0xf8) [90341.677829] ([<000000000010b1d2>] do_IRQ+0x6a/0x88) [90341.677830] ([<00000000008b6322>] io_int_handler+0x112/0x220) [90341.677832] ([<0000000000102b2e>] enabled_wait+0x56/0xa8) [90341.677833] ([<0000000000000000>] (null)) [90341.677835] ([<0000000000102e32>] arch_cpu_idle+0x32/0x48) [90341.677838] ([<000000000018a126>] cpu_startup_entry+0x266/0x2b0) [90341.677841] ([<0000000000113b38>] smp_start_secondary+0x100/0x110) [90341.677843] ([<00000000008b68a6>] restart_int_handler+0x62/0x78) [90341.677845] ([<00000000008b6588>] psw_idle+0x3c/0x40) [90341.677846] Last Breaking-Event-Address: [90341.677848] [<00000000007547ec>] qeth_dbf_longtext+0xc/0xc0 [90341.677849] [90341.677850] Kernel panic - not syncing: Fatal exception in interrupt qeth_qdio_cq_handler() analyzes SBALs on this completion queue, but does not observe the limit of 16 SBAL elements per SBAL. This patch adds the additional check to process not more than 16 SBAL elements. Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Acked-by:
-
Julian Wiedmann authored
BugLink: http://bugs.launchpad.net/bugs/1750813 On L3, the qeth_hdr struct needs to be filled with the next-hop IP address. The current code accesses rtable->rt_gateway without checking that rtable is a valid address. The accidental access to a lowcore area results in a random next-hop address in the qeth_hdr. rtable (or more precisely, skb_dst(skb)) can be NULL in rare cases (for instance together with AF_PACKET sockets). This patch adds the missing NULL-ptr checks. Signed-off-by:
-
Aleksey Makarov authored
BugLink: https://bugs.launchpad.net/bugs/1744754 This patch adds function pl011_console_match() that implements method match of struct console. It allows to match consoles against data specified in a string, for example taken from command line or compiled by ACPI SPCR table handler. This patch was merged to tty-next but then reverted because of conflict with commit 46e36683 ("serial: earlycon: Extend earlycon command line option to support 64-bit addresses") Now it is fixed. Signed-off-by:
Aleksey Makarov <aleksey.makarov@linaro.org> Reviewed-by:
Peter Hurley <peter@hurleysoftware.com> Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Tested-by:
Christopher Covington <cov@codeaurora.org> Signed-off-by:
-
Aleksey Makarov authored
BugLink: https://bugs.launchpad.net/bugs/1744754 SBBR mentions SPCR as a mandatory ACPI table. So enable it for ARM64 Earlycon should be set up as early as possible. ACPI boot tables are mapped in arch/arm64/kernel/acpi.c:acpi_boot_table_init() that is called from setup_arch() and that's where we parse SPCR. So it has to be opted-in per-arch. When ACPI_SPCR_TABLE is defined initialization of DT earlycon is deferred until the DT/ACPI decision is done. Initialize DT earlycon if ACPI is disabled. Acked-by:
Will Deacon <will.deacon@arm.com> Acked-by:
Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Tested-by:
-
dann frazier authored
BugLink: https://bugs.launchpad.net/bugs/1744754Signed-off-by:
-
Aleksey Makarov authored
BugLink: https://bugs.launchpad.net/bugs/1744754 'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port Console Redirection Table) [2] as a mandatory ACPI table that specifies the configuration of serial console. Defer initialization of DT earlycon until ACPI/DT decision is made. Parse the ACPI SPCR table, setup earlycon if required, enable specified console. Thanks to Peter Hurley for explaining how this should work. [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html [2] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspxSigned-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
-
Leif Lindholm authored
BugLink: https://bugs.launchpad.net/bugs/1744754 We have multiple "earlycon" early_param handlers - merge the DT one into the main earlycon one. It's a cleanup that also will be useful to defer setting up DT console until ACPI/DT decision is made. Rename the exported function to avoid clashing with the function from arch/microblaze/kernel/prom.c Signed-off-by:
Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
-
Aleksey Makarov authored
BugLink: https://bugs.launchpad.net/bugs/1744754 ACPICA commit 1607b69238df9c1b2940262a17aa94ec49033278 Link: https://github.com/acpica/acpica/commit/1607b692 Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>. Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1744754 gicv3_init_bases() is the only caller for its_init(), also it is a __init function, so mark its_init() as __init too, then recursively mark the functions called as __init. This will help to introduce ITS initialization using ACPI tables as we will use acpi_table_parse_entries family functions there which belong to __init section as well. Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Tomasz Nowicki <tn@semihalf.com> Signed-off-by:
-
Hanjun Guo authored
BugLink: https://bugs.launchpad.net/bugs/1744754 The gic_root_node variable defined in ITS driver is not actually used, so just remove it. Acked-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1744754 Following ACPI spec: On systems supporting GICv3 and above, GICR Base Address in MADT GICC structure holds the 64-bit physical address of the associated Redistributor. If all of the GIC Redistributors are in the always-on power domain, GICR structures should be used to describe the Redistributors instead, and this field must be set to 0. It means that we have two ways to initialize registirbutors map. 1. via GICD structure which can accommodate many redistributors as a region 2. via GICC which is able to describe single redistributor This patch is going to add support for second option. Considering redistributors, GICD and GICC subtables have be mutually exclusive. While discovering and mapping redistributor, we need to know its size in advance. For the GICC case, redistributor can be in a power-domain that is off, thus we cannot relay on GICR TYPER register. Therefore, we get GIC version from distributor register and map 2xSZ_64K for GICv3 and 4xSZ_64K for GICv4. Acked-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1744754 With the refator of gic_of_init(), GICv3/4 can be initialized by gic_init_bases() with gic distributor base address and gic redistributor region(s). So get the redistributor region base addresses from MADT GIC redistributor subtable, and the distributor base address from GICD subtable to init GICv3 irqchip in ACPI way. Note: GIC redistributor base address may also be provided in GICC structures on systems supporting GICv3 and above if the GIC Redistributors are not in the always-on power domain, this patch didn't implement such feature yet. Acked-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1744754 Isolate hardware abstraction (FDT) code to gic_of_init(). Rest of the logic goes to gic_init_bases() and expects well defined data to initialize GIC properly. The same solution is used for GICv2 driver. This is needed for ACPI initialization later. Acked-by:
Tomasz Nowicki <tomasz.nowicki@linaro.org> Signed-off-by:
-
Tejun Heo authored
BugLink: https://bugs.launchpad.net/bugs/1747896 Currently, rq->leaf_cfs_rq_list is a traversal ordered list of all live cfs_rqs which have ever been active on the CPU; unfortunately, this makes update_blocked_averages() O(# total cgroups) which isn't scalable at all. This shows up as a small CPU consumption and scheduling latency increase in the load balancing path in systems with CPU controller enabled across most cgroups. In an edge case where temporary cgroups were leaking, this caused the kernel to consume good several tens of percents of CPU cycles running update_blocked_averages(), each run taking multiple millisecs. This patch fixes the issue by taking empty and fully decayed cfs_rqs off the rq->leaf_cfs_rq_list. Signed-off-by:
Tejun Heo <tj@kernel.org> [ Added cfs_rq_is_decayed() ] Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Vincent Guittot <vincent.guittot@linaro.org> Cc: Chris Mason <clm@fb.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Turner <pjt@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170426004350.GB3222@wtj.duckdns.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> (backported from commit a9e7f654) Signed-off-by:
Gavin Guo <gavin.guo@canonical.com> Acked-by:
-
Andy Whitcroft authored
We used to use HAVE_CPLUS_DEMANGLE to disable libbfd. Upstream has changed but the name of this control and its semantics. It now only switches us to use the c++ demangler and only then if libbfd is disabled. Use the newly added HAVE_NO_LIBBFD to switch off libbfd and switch to the new name of the c++ demangle selector. BugLink: http://bugs.launchpad.net/bugs/1748922Signed-off-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> (cherry-picked from commit 3be4ddf4fc06e6dcfef876020b6b4228dea5cfc1 bionic) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Andy Whitcroft authored
We do not want to be linked to libbfd as this is a tightly versioned package which does not maintain its ABI. This prevents us from have multiple tools packages installed. Turn that off and we will fallback to libiberty. BugLink: http://bugs.launchpad.net/bugs/1748922Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1751021Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1751021Signed-off-by:
-
Andy Whitcroft authored
We are extracting all indirect callq/jmpq but in 32bit mode these are call/jmp so we need to allow those as well in our extraction. BugLink: http://bugs.launchpad.net/bugs/1751021Signed-off-by:
-
Daniel Axtens authored
BugLink: https://bugs.launchpad.net/bugs/1715519 CVE-2018-1000026 If a bnx2x card is passed a GSO packet with a gso_size larger than ~9700 bytes, it will cause a firmware error that will bring the card down: bnx2x: [bnx2x_attn_int_deasserted3:4323(enP24p1s0f0)]MC assert! bnx2x: [bnx2x_mc_assert:720(enP24p1s0f0)]XSTORM_ASSERT_LIST_INDEX 0x2 bnx2x: [bnx2x_mc_assert:736(enP24p1s0f0)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43e47 0x00463e01 0x00010052 bnx2x: [bnx2x_mc_assert:750(enP24p1s0f0)]Chip Revision: everest3, FW Version: 7_13_1 ... (dump of values continues) ... Detect when the mac length of a GSO packet is greater than the maximum packet size (9700 bytes) and disable GSO. Signed-off-by:
Daniel Axtens <dja@axtens.net> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Daniel Axtens <daniel.axtens@canonical.com> Acked-by:
-
Daniel Axtens authored
BugLink: https://bugs.launchpad.net/bugs/1715519 CVE-2018-1000026 If you take a GSO skb, and split it into packets, will the MAC length (L2 + L3 + L4 headers + payload) of those packets be small enough to fit within a given length? Move skb_gso_mac_seglen() to skbuff.h with other related functions like skb_gso_network_seglen() so we can use it, and then create skb_gso_validate_mac_len to do the full calculation. Signed-off-by:
-
Kevin Cernekee authored
The capability check in nfnetlink_rcv() verifies that the caller has CAP_NET_ADMIN in the namespace that "owns" the netlink socket. However, nfnl_cthelper_list is shared by all net namespaces on the system. An unprivileged user can create user and net namespaces in which he holds CAP_NET_ADMIN to bypass the netlink_net_capable() check: $ nfct helper list nfct v1.4.4: netlink error: Operation not permitted $ vpnns -- nfct helper list { .name = ftp, .queuenum = 0, .l3protonum = 2, .l4protonum = 6, .priv_data_len = 24, .status = enabled, }; Add capable() checks in nfnetlink_cthelper, as this is cleaner than trying to generalize the solution. Signed-off-by:Kevin Cernekee <cernekee@chromium.org> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> CVE-2017-17448 (backported from commit 4b380c42) Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by:
-
Kamal Mostafa authored
Use the SRCPKGNAME macro instead of hardcoded "linux" in the Depends for linux-headers-PKGVER-ABINUM-FLAVOUR, to provide the correct package name for derivative kernels with a different SRCPKGNAME. Ignore: yes Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
-
Kai-Heng Feng authored
r8153 on Dell TB15/16 dock corrupts rx packets. This change is suggested by Realtek. They guess that the XHCI controller doesn't have enough buffer, and their guesswork is correct, once the RX aggregation gets disabled, the issue is gone. ASMedia is currently working on a real sulotion for this issue. Dell and ODM confirm the bcdDevice and iSerialNumber is unique for TB16. Note that TB15 has different bcdDevice and iSerialNumber, which are not unique values. If you still have TB15, please contact Dell to replace it with TB16. BugLink: https://bugs.launchpad.net/bugs/1729674 Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
David Ahern authored
BugLink: http://bugs.launchpad.net/bugs/1744078 Subash reported that commit 42a7b32b ("xfrm: Add oif to dst lookups") broke a wifi use case that uses fib rules and xfrms. The intent of 42a7b32b was driven by VRFs with IPsec. As a compromise relax the use of oif in xfrm lookups to L3 master devices only (ie., oif is either an L3 master device or is enslaved to a master device). Fixes: 42a7b32b ("xfrm: Add oif to dst lookups") Reported-by:
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> (cherry picked from commit 11d7a0bb) Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by:
-
David Ahern authored
BugLink: http://bugs.launchpad.net/bugs/1744078 Add helper to lookup l3mdev master index given a device index. Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1745266Signed-off-by:
-
Andy Lutomirski authored
BugLink: http://bugs.launchpad.net/bugs/1745266 commit 352909b4 upstream. This tests that the vsyscall entries do what they're expected to do. It also confirms that attempts to read the vsyscall page behave as expected. If changes are made to the vsyscall code or its memory map handling, running this test in all three of vsyscall=none, vsyscall=emulate, and vsyscall=native are helpful. (Because it's easy, this also compares the vsyscall results to their vDSO equivalents.) Note to KAISER backporters: please test this under all three vsyscall modes. Also, in the emulate and native modes, make sure that test_vsyscall_64 agrees with the command line or config option as to which mode you're in. It's quite easy to mess up the kernel such that native mode accidentally emulates or vice versa. Greg, etc: please backport this to all your Meltdown-patched kernels. It'll help make sure the patches didn't regress vsyscalls. CSigned-off-by:
Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Hugh Dickins <hughd@google.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/2b9c5a174c1d60fd7774461d518aa75598b1d8fd.1515719552.git.luto@kernel.orgSigned-off-by:
-
Borislav Petkov authored
BugLink: http://bugs.launchpad.net/bugs/1745266 commit 612e8e93 upstream. The alternatives code checks only the first byte whether it is a NOP, but with NOPs in front of the payload and having actual instructions after it breaks the "optimized' test. Make sure to scan all bytes before deciding to optimize the NOPs in there. Reported-by:
David Woodhouse <dwmw2@infradead.org> Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
-
David Woodhouse authored
BugLink: http://bugs.launchpad.net/bugs/1745266 commit 9ecccfaa upstream. Fixes: 87590ce6 ("sysfs/cpu: Add vulnerability folder") Signed-off-by:
-
