August 2022 - Linux-stable-mirror

[PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it

by Ben Hutchings

The mitigation for PBRSB includes adding LFENCE instructions to the RSB filling sequence. However, RSB filling is done on some older CPUs that don't support the LFENCE instruction. Define and use a BARRIER_NOSPEC macro which makes the LFENCE conditional on X86_FEATURE_LFENCE_RDTSC, like the barrier_nospec() macro defined for C code in <asm/barrier.h>. Reported-by: Martin-Éric Racine <martin-eric.racine(a)iki.fi> References: https://bugs.debian.org/1017425 Cc: stable(a)vger.kernel.org Cc: regressions(a)lists.linux.dev Cc: Daniel Sneddon <daniel.sneddon(a)linux.intel.com> Cc: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> Fixes: 2b1299322016 ("x86/speculation: Add RSB VM Exit protections") Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence") Signed-off-by: Ben Hutchings <benh(a)debian.org> --- arch/x86/include/asm/nospec-branch.h | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h index e64fd20778b6..b1029fd88474 100644 --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -34,6 +34,11 @@ #define RSB_CLEAR_LOOPS 32 /* To forcibly overwrite all entries */ +#ifdef __ASSEMBLY__ + +/* Prevent speculative execution past this barrier. */ +#define BARRIER_NOSPEC ALTERNATIVE "", "lfence", X86_FEATURE_LFENCE_RDTSC + /* * Google experimented with loop-unrolling and this turned out to be * the optimal version - two calls, each with their own speculation @@ -62,9 +67,7 @@ dec reg; \ jnz 771b; \ /* barrier for jnz misprediction */ \ - lfence; - -#ifdef __ASSEMBLY__ + BARRIER_NOSPEC; /* * This should be used immediately before an indirect jump/call. It tells @@ -138,7 +141,7 @@ int3 .Lunbalanced_ret_guard_\@: add $(BITS_PER_LONG/8), %_ASM_SP - lfence + BARRIER_NOSPEC .endm /*

2 years, 5 months

1
0
0 0

Re: [PATCH bpf] bpf: Fix kernel BUG in purge_effective_progs

by Pu Lehui

On 2022/8/17 4:39, Andrii Nakryiko wrote: > On Sat, Aug 13, 2022 at 6:11 AM Pu Lehui <pulehui(a)huawei.com> wrote: >> >> Syzkaller reported kernel BUG as follows: >> >> ------------[ cut here ]------------ >> kernel BUG at kernel/bpf/cgroup.c:925! >> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI >> CPU: 1 PID: 194 Comm: detach Not tainted 5.19.0-14184-g69dac8e431af #8 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >> rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 >> RIP: 0010:__cgroup_bpf_detach+0x1f2/0x2a0 >> Code: 00 e8 92 60 30 00 84 c0 75 d8 4c 89 e0 31 f6 85 f6 74 19 42 f6 84 >> 28 48 05 00 00 02 75 0e 48 8b 80 c0 00 00 00 48 85 c0 75 e5 <0f> 0b 48 >> 8b 0c5 >> RSP: 0018:ffffc9000055bdb0 EFLAGS: 00000246 >> RAX: 0000000000000000 RBX: ffff888100ec0800 RCX: ffffc900000f1000 >> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888100ec4578 >> RBP: 0000000000000000 R08: ffff888100ec0800 R09: 0000000000000040 >> R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100ec4000 >> R13: 000000000000000d R14: ffffc90000199000 R15: ffff888100effb00 >> FS: 00007f68213d2b80(0000) GS:ffff88813bc80000(0000) >> knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: 000055f74a0e5850 CR3: 0000000102836000 CR4: 00000000000006e0 >> Call Trace: >> <TASK> >> cgroup_bpf_prog_detach+0xcc/0x100 >> __sys_bpf+0x2273/0x2a00 >> __x64_sys_bpf+0x17/0x20 >> do_syscall_64+0x3b/0x90 >> entry_SYSCALL_64_after_hwframe+0x63/0xcd >> RIP: 0033:0x7f68214dbcb9 >> Code: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 >> f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 >> f0 ff8 >> RSP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 >> RAX: ffffffffffffffda RBX: 000000000000000b RCX: 00007f68214dbcb9 >> RDX: 0000000000000090 RSI: 00007ffeb487db70 RDI: 0000000000000009 >> RBP: 0000000000000003 R08: 0000000000000012 R09: 0000000b00000003 >> R10: 00007ffeb487db70 R11: 0000000000000246 R12: 00007ffeb487dc20 >> R13: 0000000000000004 R14: 0000000000000001 R15: 000055f74a1011b0 >> </TASK> >> Modules linked in: >> ---[ end trace 0000000000000000 ]--- >> >> Repetition steps: >> For the following cgroup tree, >> >> root >> | >> cg1 >> | >> cg2 >> >> 1. attach prog2 to cg2, and then attach prog1 to cg1, both bpf progs >> attach type is NONE or OVERRIDE. >> 2. write 1 to /proc/thread-self/fail-nth for failslab. >> 3. detach prog1 for cg1, and then kernel BUG occur. >> >> Failslab injection will cause kmalloc fail and fall back to >> purge_effective_progs. The problem is that cg2 have attached another prog, >> so when go through cg2 layer, iteration will add pos to 1, and subsequent >> operations will be skipped by the following condition, and cg will meet >> NULL in the end. >> >> `if (pos && !(cg->bpf.flags[atype] & BPF_F_ALLOW_MULTI))` >> >> The NULL cg means no link or prog match, this is as expected, and it's not >> a bug. So here just skip the no match situation. >> >> Fixes: 4c46091ee985 ("bpf: Fix KASAN use-after-free Read in compute_effective_progs") >> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> >> --- >> kernel/bpf/cgroup.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c >> index 59b7eb60d5b4..4a400cd63731 100644 >> --- a/kernel/bpf/cgroup.c >> +++ b/kernel/bpf/cgroup.c >> @@ -921,8 +921,10 @@ static void purge_effective_progs(struct cgroup *cgrp, struct bpf_prog *prog, >> pos++; >> } >> } >> + >> + /* no link or prog match, skip the cgroup of this layer */ >> + continue; >> found: >> - BUG_ON(!cg); > > I don't think it's necessary to remove this BUG_ON(), but it also > feels unnecessary for purge_effective_progs, so I don't mind it. > > Acked-by: Andrii Nakryiko <andrii(a)kernel.org> > Hi, Will this patch be accepted? I think we should CC stable. Thanks, Lehui >> progs = rcu_dereference_protected( >> desc->bpf.effective[atype], >> lockdep_is_held(&cgroup_mutex)); >> -- >> 2.25.1 >> > . >

2 years, 5 months

3
2
0 0

[PATCH 1/1] riscv: dts: microchip: correct L2 cache interrupts

by Heinrich Schuchardt

The "PolarFire SoC MSS Technical Reference Manual" documents the following PLIC interrupts: 1 - L2 Cache Controller Signals when a metadata correction event occurs 2 - L2 Cache Controller Signals when an uncorrectable metadata event occurs 3 - L2 Cache Controller Signals when a data correction event occurs 4 - L2 Cache Controller Signals when an uncorrectable data event occurs This differs from the SiFive FU540 which only has three L2 cache related interrupts. The sequence in the device tree is defined by an enum: enum { DIR_CORR = 0, DATA_CORR, DATA_UNCORR, DIR_UNCORR, }; So the correct sequence of the L2 cache interrupts is interrupts = <1>, <3>, <4>, <2>; Fixes: e35b07a7df9b ("riscv: dts: microchip: mpfs: Group tuples in interrupt properties") Fixes: 0fa6107eca41 ("RISC-V: Initial DTS for Microchip ICICLE board") Cc: Conor Dooley <conor.dooley(a)microchip.com> Cc: stable(a)vger.kernel.org Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- arch/riscv/boot/dts/microchip/mpfs.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/boot/dts/microchip/mpfs.dtsi b/arch/riscv/boot/dts/microchip/mpfs.dtsi index 496d3b7642bd..ec1de6344be9 100644 --- a/arch/riscv/boot/dts/microchip/mpfs.dtsi +++ b/arch/riscv/boot/dts/microchip/mpfs.dtsi @@ -169,7 +169,7 @@ cctrllr: cache-controller@2010000 { cache-size = <2097152>; cache-unified; interrupt-parent = <&plic>; - interrupts = <1>, <2>, <3>; + interrupts = <1>, <3>, <4>, <2>; }; clint: clint@2000000 { -- 2.36.1

2 years, 5 months

4
5
0 0

Negative SEO like you never seen before

by Cruz

Tired of trying Negativer plans but that have only partial effect that last only several weeks? Try this complex strategy and get the negative SEO effect to come much faster and last a lot longer than the traditional Negative strategies More info here https://www.creative-digital.co/product/derank-seo-service/ Unsubscribe: in the footer of our site

2 years, 5 months

1
0
0 0

Re: [PATCH net v2] Revert "tcp: change pingpong threshold to 3"

by Jiri Slaby

On 21. 07. 22, 22:44, Wei Wang wrote: > This reverts commit 4a41f453bedfd5e9cd040bad509d9da49feb3e2c. > > This to-be-reverted commit was meant to apply a stricter rule for the > stack to enter pingpong mode. However, the condition used to check for > interactive session "before(tp->lsndtime, icsk->icsk_ack.lrcvtime)" is > jiffy based and might be too coarse, which delays the stack entering > pingpong mode. > We revert this patch so that we no longer use the above condition to > determine interactive session, and also reduce pingpong threshold to 1. > > Fixes: 4a41f453bedf ("tcp: change pingpong threshold to 3") > Reported-by: LemmyHuang <hlm3280(a)163.com> > Suggested-by: Neal Cardwell <ncardwell(a)google.com> > Signed-off-by: Wei Wang <weiwan(a)google.com> This breaks python-eventlet [1] (and was backported to stable trees): ________________ TestHttpd.test_018b_http_10_keepalive_framing _________________ self = <tests.wsgi_test.TestHttpd testMethod=test_018b_http_10_keepalive_framing> def test_018b_http_10_keepalive_framing(self): # verify that if an http/1.0 client sends connection: keep-alive # that we don't mangle the request framing if the app doesn't read the request def app(environ, start_response): resp_body = { '/1': b'first response', '/2': b'second response', '/3': b'third response', }.get(environ['PATH_INFO']) if resp_body is None: resp_body = 'Unexpected path: ' + environ['PATH_INFO'] if six.PY3: resp_body = resp_body.encode('latin1') # Never look at wsgi.input! start_response('200 OK', [('Content-type', 'text/plain')]) return [resp_body] self.site.application = app sock = eventlet.connect(self.server_addr) req_body = b'GET /tricksy HTTP/1.1\r\n' body_len = str(len(req_body)).encode('ascii') sock.sendall(b'PUT /1 HTTP/1.0\r\nHost: localhost\r\nConnection: keep-alive\r\n' b'Content-Length: ' + body_len + b'\r\n\r\n' + req_body) result1 = read_http(sock) self.assertEqual(b'first response', result1.body) self.assertEqual(result1.headers_original.get('Connection'), 'keep-alive') sock.sendall(b'PUT /2 HTTP/1.0\r\nHost: localhost\r\nConnection: keep-alive\r\n' b'Content-Length: ' + body_len + b'\r\nExpect: 100-continue\r\n\r\n') # Client may have a short timeout waiting on that 100 Continue # and basically immediately send its body sock.sendall(req_body) result2 = read_http(sock) self.assertEqual(b'second response', result2.body) self.assertEqual(result2.headers_original.get('Connection'), 'close') > sock.sendall(b'PUT /3 HTTP/1.0\r\nHost: localhost\r\nConnection: close\r\n\r\n') tests/wsgi_test.py:648: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ eventlet/greenio/base.py:407: in sendall tail = self.send(data, flags) eventlet/greenio/base.py:401: in send return self._send_loop(self.fd.send, data, flags) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <eventlet.greenio.base.GreenSocket object at 0x7f5f2f73c9a0> send_method = <built-in method send of socket object at 0x7f5f2f73d520> data = b'PUT /3 HTTP/1.0\r\nHost: localhost\r\nConnection: close\r\n\r\n' args = (0,), _timeout_exc = timeout('timed out'), eno = 32 def _send_loop(self, send_method, data, *args): if self.act_non_blocking: return send_method(data, *args) _timeout_exc = socket_timeout('timed out') while True: try: > return send_method(data, *args) E BrokenPipeError: [Errno 32] Broken pipe eventlet/greenio/base.py:388: BrokenPipeError ==================== Reverting this revert on the top of 5.19 solves the issue. Any ideas? [1] https://github.com/eventlet/eventlet > --- > v2: added Fixes tag > > --- > include/net/inet_connection_sock.h | 10 +--------- > net/ipv4/tcp_output.c | 15 ++++++--------- > 2 files changed, 7 insertions(+), 18 deletions(-) > > diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h > index 85cd695e7fd1..ee88f0f1350f 100644 > --- a/include/net/inet_connection_sock.h > +++ b/include/net/inet_connection_sock.h > @@ -321,7 +321,7 @@ void inet_csk_update_fastreuse(struct inet_bind_bucket *tb, > > struct dst_entry *inet_csk_update_pmtu(struct sock *sk, u32 mtu); > > -#define TCP_PINGPONG_THRESH 3 > +#define TCP_PINGPONG_THRESH 1 > > static inline void inet_csk_enter_pingpong_mode(struct sock *sk) > { > @@ -338,14 +338,6 @@ static inline bool inet_csk_in_pingpong_mode(struct sock *sk) > return inet_csk(sk)->icsk_ack.pingpong >= TCP_PINGPONG_THRESH; > } > > -static inline void inet_csk_inc_pingpong_cnt(struct sock *sk) > -{ > - struct inet_connection_sock *icsk = inet_csk(sk); > - > - if (icsk->icsk_ack.pingpong < U8_MAX) > - icsk->icsk_ack.pingpong++; > -} > - > static inline bool inet_csk_has_ulp(struct sock *sk) > { > return inet_sk(sk)->is_icsk && !!inet_csk(sk)->icsk_ulp_ops; > diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c > index c38e07b50639..d06e72e141ac 100644 > --- a/net/ipv4/tcp_output.c > +++ b/net/ipv4/tcp_output.c > @@ -167,16 +167,13 @@ static void tcp_event_data_sent(struct tcp_sock *tp, > if (tcp_packets_in_flight(tp) == 0) > tcp_ca_event(sk, CA_EVENT_TX_START); > > - /* If this is the first data packet sent in response to the > - * previous received data, > - * and it is a reply for ato after last received packet, > - * increase pingpong count. > - */ > - if (before(tp->lsndtime, icsk->icsk_ack.lrcvtime) && > - (u32)(now - icsk->icsk_ack.lrcvtime) < icsk->icsk_ack.ato) > - inet_csk_inc_pingpong_cnt(sk); > - > tp->lsndtime = now; > + > + /* If it is a reply for ato after last received > + * packet, enter pingpong mode. > + */ > + if ((u32)(now - icsk->icsk_ack.lrcvtime) < icsk->icsk_ack.ato) > + inet_csk_enter_pingpong_mode(sk); > } > > /* Account for an ACK we sent. */ thanks, -- js suse labs

2 years, 5 months

4
10
0 0

Re: [PATCH] binder: fix UAF of ref->proc caused by race condition

by Carlos Llamas

On Mon, Aug 01, 2022 at 06:25:11PM +0000, Carlos Llamas wrote: > A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the > reference for a node. In this case, the target proc normally releases > the failed reference upon close as expected. However, if the target is > dying in parallel the call will race with binder_deferred_release(), so > the target could have released all of its references by now leaving the > cleanup of the new failed reference unhandled. > > The transaction then ends and the target proc gets released making the > ref->proc now a dangling pointer. Later on, ref->node is closed and we > attempt to take spin_lock(&ref->proc->inner_lock), which leads to the > use-after-free bug reported below. Let's fix this by cleaning up the > failed reference on the spot instead of relying on the target to do so. > > ================================================================== > BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 > Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 > > CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 > Hardware name: linux,dummy-virt (DT) > Workqueue: events binder_deferred_func > Call trace: > dump_backtrace.part.0+0x1d0/0x1e0 > show_stack+0x18/0x70 > dump_stack_lvl+0x68/0x84 > print_report+0x2e4/0x61c > kasan_report+0xa4/0x110 > kasan_check_range+0xfc/0x1a4 > __kasan_check_write+0x3c/0x50 > _raw_spin_lock+0xa8/0x150 > binder_deferred_func+0x5e0/0x9b0 > process_one_work+0x38c/0x5f0 > worker_thread+0x9c/0x694 > kthread+0x188/0x190 > ret_from_fork+0x10/0x20 > > Signed-off-by: Carlos Llamas <cmllamas(a)google.com> > --- > drivers/android/binder.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/drivers/android/binder.c b/drivers/android/binder.c > index 362c0deb65f1..9d42afe60180 100644 > --- a/drivers/android/binder.c > +++ b/drivers/android/binder.c > @@ -1361,6 +1361,18 @@ static int binder_inc_ref_for_node(struct binder_proc *proc, > } > ret = binder_inc_ref_olocked(ref, strong, target_list); > *rdata = ref->data; > + if (ret && ref == new_ref) { > + /* > + * Cleanup the failed reference here as the target > + * could now be dead and have already released its > + * references by now. Calling on the new reference > + * with strong=0 and a tmp_refs will not decrement > + * the node. The new_ref gets kfree'd below. > + */ > + binder_cleanup_ref_olocked(new_ref); > + ref = NULL; > + } > + > binder_proc_unlock(proc); > if (new_ref && ref != new_ref) > /* > -- > 2.37.1.455.g008518b4e5-goog > Sorry, I forgot to CC stable. This patch should be applied to all stable kernels starting with 4.14 and higher. Cc: stable(a)vger.kernel.org # 4.14+

2 years, 5 months

2
4
0 0

[PATCH v2 2/4] Input: xpad - fix wireless 360 controller breaking after suspend

by Pavel Rojtberg

From: Cameron Gutman <aicommander(a)gmail.com> Suspending and resuming the system can sometimes cause the out URB to get hung after a reset_resume. This causes LED setting and force feedback to break on resume. To avoid this, just drop the reset_resume callback so the USB core rebinds xpad to the wireless pads on resume if a reset happened. A nice side effect of this change is the LED ring on wireless controllers is now set correctly on system resume. Cc: stable(a)vger.kernel.org Fixes: 4220f7db1e42 ("Input: xpad - workaround dead irq_out after suspend/ resume") Signed-off-by: Cameron Gutman <aicommander(a)gmail.com> Signed-off-by: Pavel Rojtberg <rojtberg(a)gmail.com> --- drivers/input/joystick/xpad.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c index 629646b..4e01056 100644 --- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -1991,7 +1991,6 @@ static struct usb_driver xpad_driver = { .disconnect = xpad_disconnect, .suspend = xpad_suspend, .resume = xpad_resume, - .reset_resume = xpad_resume, .id_table = xpad_table, }; -- 2.34.1

2 years, 5 months

1
0
0 0

[PATCH v2 1/4] Input: xpad - add supported devices as contributed on github

by Pavel Rojtberg

From: Pavel Rojtberg <rojtberg(a)gmail.com> This is based on multiple commits at https://github.com/paroj/xpad Cc: stable(a)vger.kernel.org Signed-off-by: Jasper Poppe <jgpoppe(a)gmail.com> Signed-off-by: Jeremy Palmer <jpalmer(a)linz.govt.nz> Signed-off-by: Ruineka <ruinairas1992(a)gmail.com> Signed-off-by: Cleber de Mattos Casali <clebercasali(a)gmail.com> Signed-off-by: Kyle Gospodnetich <me(a)kylegospodneti.ch> Signed-off-by: Pavel Rojtberg <rojtberg(a)gmail.com> --- drivers/input/joystick/xpad.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c index 53126d9..629646b 100644 --- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -113,6 +113,8 @@ static const struct xpad_device { u8 xtype; } xpad_device[] = { { 0x0079, 0x18d4, "GPD Win 2 X-Box Controller", 0, XTYPE_XBOX360 }, + { 0x03eb, 0xff01, "Wooting One (Legacy)", 0, XTYPE_XBOX360 }, + { 0x03eb, 0xff02, "Wooting Two (Legacy)", 0, XTYPE_XBOX360 }, { 0x044f, 0x0f00, "Thrustmaster Wheel", 0, XTYPE_XBOX }, { 0x044f, 0x0f03, "Thrustmaster Wheel", 0, XTYPE_XBOX }, { 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX }, @@ -244,6 +246,7 @@ static const struct xpad_device { { 0x0f0d, 0x0063, "Hori Real Arcade Pro Hayabusa (USA) Xbox One", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE }, { 0x0f0d, 0x0067, "HORIPAD ONE", 0, XTYPE_XBOXONE }, { 0x0f0d, 0x0078, "Hori Real Arcade Pro V Kai Xbox One", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE }, + { 0x0f0d, 0x00c5, "Hori Fighting Commander ONE", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE }, { 0x0f30, 0x010b, "Philips Recoil", 0, XTYPE_XBOX }, { 0x0f30, 0x0202, "Joytech Advanced Controller", 0, XTYPE_XBOX }, { 0x0f30, 0x8888, "BigBen XBMiniPad Controller", 0, XTYPE_XBOX }, @@ -260,6 +263,7 @@ static const struct xpad_device { { 0x1430, 0x8888, "TX6500+ Dance Pad (first generation)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX }, { 0x1430, 0xf801, "RedOctane Controller", 0, XTYPE_XBOX360 }, { 0x146b, 0x0601, "BigBen Interactive XBOX 360 Controller", 0, XTYPE_XBOX360 }, + { 0x146b, 0x0604, "Bigben Interactive DAIJA Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 }, { 0x1532, 0x0037, "Razer Sabertooth", 0, XTYPE_XBOX360 }, { 0x1532, 0x0a00, "Razer Atrox Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE }, { 0x1532, 0x0a03, "Razer Wildcat", 0, XTYPE_XBOXONE }, @@ -325,6 +329,7 @@ static const struct xpad_device { { 0x24c6, 0x5502, "Hori Fighting Stick VX Alt", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 }, { 0x24c6, 0x5503, "Hori Fighting Edge", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 }, { 0x24c6, 0x5506, "Hori SOULCALIBUR V Stick", 0, XTYPE_XBOX360 }, + { 0x24c6, 0x5510, "Hori Fighting Commander ONE (Xbox 360/PC Mode)", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 }, { 0x24c6, 0x550d, "Hori GEM Xbox controller", 0, XTYPE_XBOX360 }, { 0x24c6, 0x550e, "Hori Real Arcade Pro V Kai 360", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 }, { 0x24c6, 0x551a, "PowerA FUSION Pro Controller", 0, XTYPE_XBOXONE }, @@ -334,6 +339,14 @@ static const struct xpad_device { { 0x24c6, 0x5b03, "Thrustmaster Ferrari 458 Racing Wheel", 0, XTYPE_XBOX360 }, { 0x24c6, 0x5d04, "Razer Sabertooth", 0, XTYPE_XBOX360 }, { 0x24c6, 0xfafe, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 }, + { 0x2563, 0x058d, "OneXPlayer Gamepad", 0, XTYPE_XBOX360 }, + { 0x2dc8, 0x2000, "8BitDo Pro 2 Wired Controller fox Xbox", 0, XTYPE_XBOXONE }, + { 0x31e3, 0x1100, "Wooting One", 0, XTYPE_XBOX360 }, + { 0x31e3, 0x1200, "Wooting Two", 0, XTYPE_XBOX360 }, + { 0x31e3, 0x1210, "Wooting Lekker", 0, XTYPE_XBOX360 }, + { 0x31e3, 0x1220, "Wooting Two HE", 0, XTYPE_XBOX360 }, + { 0x31e3, 0x1300, "Wooting 60HE (AVR)", 0, XTYPE_XBOX360 }, + { 0x31e3, 0x1310, "Wooting 60HE (ARM)", 0, XTYPE_XBOX360 }, { 0x3285, 0x0607, "Nacon GC-100", 0, XTYPE_XBOX360 }, { 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX }, { 0xffff, 0xffff, "Chinese-made Xbox Controller", 0, XTYPE_XBOX }, @@ -419,6 +432,7 @@ static const signed short xpad_abs_triggers[] = { static const struct usb_device_id xpad_table[] = { { USB_INTERFACE_INFO('X', 'B', 0) }, /* X-Box USB-IF not approved class */ XPAD_XBOX360_VENDOR(0x0079), /* GPD Win 2 Controller */ + XPAD_XBOX360_VENDOR(0x03eb), /* Wooting Keyboards (Legacy) */ XPAD_XBOX360_VENDOR(0x044f), /* Thrustmaster X-Box 360 controllers */ XPAD_XBOX360_VENDOR(0x045e), /* Microsoft X-Box 360 controllers */ XPAD_XBOXONE_VENDOR(0x045e), /* Microsoft X-Box One controllers */ @@ -429,6 +443,7 @@ static const struct usb_device_id xpad_table[] = { { USB_DEVICE(0x0738, 0x4540) }, /* Mad Catz Beat Pad */ XPAD_XBOXONE_VENDOR(0x0738), /* Mad Catz FightStick TE 2 */ XPAD_XBOX360_VENDOR(0x07ff), /* Mad Catz GamePad */ + XPAD_XBOX360_VENDOR(0x0c12), /* Zeroplus X-Box 360 controllers */ XPAD_XBOX360_VENDOR(0x0e6f), /* 0x0e6f X-Box 360 controllers */ XPAD_XBOXONE_VENDOR(0x0e6f), /* 0x0e6f X-Box One controllers */ XPAD_XBOX360_VENDOR(0x0f0d), /* Hori Controllers */ @@ -450,8 +465,12 @@ static const struct usb_device_id xpad_table[] = { XPAD_XBOXONE_VENDOR(0x20d6), /* PowerA Controllers */ XPAD_XBOX360_VENDOR(0x24c6), /* PowerA Controllers */ XPAD_XBOXONE_VENDOR(0x24c6), /* PowerA Controllers */ + XPAD_XBOX360_VENDOR(0x2563), /* OneXPlayer Gamepad */ + XPAD_XBOX360_VENDOR(0x260d), /* Dareu H101 */ + XPAD_XBOXONE_VENDOR(0x2dc8), /* 8BitDo Pro 2 Wired Controller for Xbox */ XPAD_XBOXONE_VENDOR(0x2e24), /* Hyperkin Duke X-Box One pad */ XPAD_XBOX360_VENDOR(0x2f24), /* GameSir Controllers */ + XPAD_XBOX360_VENDOR(0x31e3), /* Wooting Keyboards */ XPAD_XBOX360_VENDOR(0x3285), /* Nacon GC-100 */ { } }; -- 2.34.1

2 years, 5 months

1
0
0 0

[RESEND RFC PATCH] x86/bugs: Add "unknown" reporting for MMIO Stale Data

by Pawan Gupta

Older CPUs beyond its Servicing period are not listed in the affected processor list for MMIO Stale Data vulnerabilities. These CPUs currently report "Not affected" in sysfs, which may not be correct. Add support for "Unknown" reporting for such CPUs. Mitigation is not deployed when the status is "Unknown". "CPU is beyond its Servicing period" means these CPUs are beyond their Servicing [1] period and have reached End of Servicing Updates (ESU) [2]. [1] Servicing: The process of providing functional and security updates to Intel processors or platforms, utilizing the Intel Platform Update (IPU) process or other similar mechanisms. [2] End of Servicing Updates (ESU): ESU is the date at which Intel will no longer provide Servicing, such as through IPU or other similar update processes. ESU dates will typically be aligned to end of quarter. Suggested-by: Andrew Cooper <andrew.cooper3(a)citrix.com> Suggested-by: Tony Luck <tony.luck(a)intel.com> Fixes: 8d50cdf8b834 ("x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data") Cc: stable(a)vger.kernel.org Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> --- CPU vulnerability is unknown if, hardware doesn't set the immunity bits and CPU is not in the known-affected-list. In order to report the unknown status, this patch sets the MMIO bug for all Intel CPUs that don't have the hardware immunity bits set. Based on the known-affected-list of CPUs, mitigation selection then deploys the mitigation or sets the "Unknown" status; which is ugly. I will appreciate suggestions to improve this. Thanks, Pawan .../hw-vuln/processor_mmio_stale_data.rst | 3 +++ arch/x86/kernel/cpu/bugs.c | 11 +++++++- arch/x86/kernel/cpu/common.c | 26 +++++++++++++------ arch/x86/kernel/cpu/cpu.h | 1 + 4 files changed, 32 insertions(+), 9 deletions(-) diff --git a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst index 9393c50b5afc..55524e0798da 100644 --- a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst +++ b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst @@ -230,6 +230,9 @@ The possible values in this file are: * - 'Mitigation: Clear CPU buffers' - The processor is vulnerable and the CPU buffer clearing mitigation is enabled. + * - 'Unknown: CPU is beyond its Servicing period' + - The processor vulnerability status is unknown because it is + out of Servicing period. Mitigation is not attempted. If the processor is vulnerable then the following information is appended to the above information: diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 0dd04713434b..dd6e78d370bc 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -416,6 +416,7 @@ enum mmio_mitigations { MMIO_MITIGATION_OFF, MMIO_MITIGATION_UCODE_NEEDED, MMIO_MITIGATION_VERW, + MMIO_MITIGATION_UNKNOWN, }; /* Default mitigation for Processor MMIO Stale Data vulnerabilities */ @@ -426,12 +427,18 @@ static const char * const mmio_strings[] = { [MMIO_MITIGATION_OFF] = "Vulnerable", [MMIO_MITIGATION_UCODE_NEEDED] = "Vulnerable: Clear CPU buffers attempted, no microcode", [MMIO_MITIGATION_VERW] = "Mitigation: Clear CPU buffers", + [MMIO_MITIGATION_UNKNOWN] = "Unknown: CPU is beyond its servicing period", }; static void __init mmio_select_mitigation(void) { u64 ia32_cap; + if (mmio_stale_data_unknown()) { + mmio_mitigation = MMIO_MITIGATION_UNKNOWN; + return; + } + if (!boot_cpu_has_bug(X86_BUG_MMIO_STALE_DATA) || cpu_mitigations_off()) { mmio_mitigation = MMIO_MITIGATION_OFF; @@ -1638,6 +1645,7 @@ void cpu_bugs_smt_update(void) pr_warn_once(MMIO_MSG_SMT); break; case MMIO_MITIGATION_OFF: + case MMIO_MITIGATION_UNKNOWN: break; } @@ -2235,7 +2243,8 @@ static ssize_t tsx_async_abort_show_state(char *buf) static ssize_t mmio_stale_data_show_state(char *buf) { - if (mmio_mitigation == MMIO_MITIGATION_OFF) + if (mmio_mitigation == MMIO_MITIGATION_OFF || + mmio_mitigation == MMIO_MITIGATION_UNKNOWN) return sysfs_emit(buf, "%s\n", mmio_strings[mmio_mitigation]); if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) { diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 736262a76a12..82088410870e 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1286,6 +1286,22 @@ static bool arch_cap_mmio_immune(u64 ia32_cap) ia32_cap & ARCH_CAP_SBDR_SSDP_NO); } +bool __init mmio_stale_data_unknown(void) +{ + u64 ia32_cap = x86_read_arch_cap_msr(); + + if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) + return false; + /* + * CPU vulnerability is unknown when, hardware doesn't set the + * immunity bits and CPU is not in the known affected list. + */ + if (!cpu_matches(cpu_vuln_blacklist, MMIO) && + !arch_cap_mmio_immune(ia32_cap)) + return true; + return false; +} + static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) { u64 ia32_cap = x86_read_arch_cap_msr(); @@ -1349,14 +1365,8 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) cpu_matches(cpu_vuln_blacklist, SRBDS | MMIO_SBDS)) setup_force_cpu_bug(X86_BUG_SRBDS); - /* - * Processor MMIO Stale Data bug enumeration - * - * Affected CPU list is generally enough to enumerate the vulnerability, - * but for virtualization case check for ARCH_CAP MSR bits also, VMM may - * not want the guest to enumerate the bug. - */ - if (cpu_matches(cpu_vuln_blacklist, MMIO) && + /* Processor MMIO Stale Data bug enumeration */ + if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && !arch_cap_mmio_immune(ia32_cap)) setup_force_cpu_bug(X86_BUG_MMIO_STALE_DATA); diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h index 7c9b5893c30a..a2dbfc1bbc49 100644 --- a/arch/x86/kernel/cpu/cpu.h +++ b/arch/x86/kernel/cpu/cpu.h @@ -82,6 +82,7 @@ unsigned int aperfmperf_get_khz(int cpu); extern void x86_spec_ctrl_setup_ap(void); extern void update_srbds_msr(void); +extern bool mmio_stale_data_unknown(void); extern u64 x86_read_arch_cap_msr(void); base-commit: 4a57a8400075bc5287c5c877702c68aeae2a033d -- 2.35.3

2 years, 5 months

7
19
0 0

[PATCH v2 2/2] s390/vfio-ap: fix unlinking of queues from the mdev

by Tony Krowiak

The vfio_ap_mdev_unlink_adapter and vfio_ap_mdev_unlink_domain functions add the associated vfio_ap_queue objects to the hashtable that links them to the matrix mdev to which their APQN is assigned. In order to unlink them, they must be deleted from the hashtable; if not, they will continue to be reset whenever userspace closes the mdev fd or removes the mdev. This patch fixes that issue. Cc: stable(a)vger.kernel.org Fixes: 2838ba5bdcd6 ("s390/vfio-ap: reset queues after adapter/domain unassignment") Reported-by: Tony Krowiak <akrowiak(a)linux.ibm.com> Signed-off-by: Tony Krowiak <akrowiak(a)linux.ibm.com> --- drivers/s390/crypto/vfio_ap_ops.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c index ee82207b4e60..2493926b5dfb 100644 --- a/drivers/s390/crypto/vfio_ap_ops.c +++ b/drivers/s390/crypto/vfio_ap_ops.c @@ -1049,8 +1049,7 @@ static void vfio_ap_mdev_unlink_adapter(struct ap_matrix_mdev *matrix_mdev, if (q && qtable) { if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) && test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm)) - hash_add(qtable->queues, &q->mdev_qnode, - q->apqn); + vfio_ap_unlink_queue_fr_mdev(q); } } } @@ -1236,8 +1235,7 @@ static void vfio_ap_mdev_unlink_domain(struct ap_matrix_mdev *matrix_mdev, if (q && qtable) { if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) && test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm)) - hash_add(qtable->queues, &q->mdev_qnode, - q->apqn); + vfio_ap_unlink_queue_fr_mdev(q); } } } -- 2.31.1

2 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2022