Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp57075pxj; Wed, 16 Jun 2021 20:11:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2b1/Y7oXY/co65FNfJdeIq+JsYeQh4nEiK3kirkju0ibxCMNxxaZVDD7Y1Mfm61PRsdpD X-Received: by 2002:a05:6602:722:: with SMTP id g2mr1964237iox.118.1623899515279; Wed, 16 Jun 2021 20:11:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623899515; cv=none; d=google.com; s=arc-20160816; b=A5JMduwadHOOGmMcD+r4CxQE1M8bDPlzytmcFVl8ybJj516qHZ98xjsSOrTqS9QRXb w2vj8OrZbsS6QB69WWnlrGWAEKXsLwtjNmdzGmQKs9CblqXdUef7o/Y8V6GhwyoXvKE+ IQluMR4MkAzNVc8QR4fiY9lFcpTGf1mvWXgtDwc4YuBV1LfQlg3yg2I1MDOHQRAm8J2+ R3lZNln0Sokce1LRcx2+JXyah5knCNp5vdFnc38XwK9ez3WE/1t2fUYK04Tnrz9CvFMV KPw6JjJ5pzBLwpyDXQoEO5UeT8wHyWEsz8xFcZsV8avHvaIDg7k5hOHkb0FNgtSYIz3u YjMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:mime-version:user-agent:message-id :in-reply-to:date:references:cc:to:from; bh=3BFr2HOIyFA8KH2Q7RUuazDjYURV3BG4TzyFpwb/HRI=; b=nt13VZD95XNeD0XrwgvvHcHElvSb7us31lqbdeSKyT6ErrcNoB7XczlctmkOQrAJZe ne0ZcG26w+6RSjMZsHyY7DWMw86qnpfNoJS2/S5gKuiOVHp0FG++kjUr/bLXS4z4PzYi ODVdQj24/K0fwEK4GE92hF78gtBw9uE7Kn4dbQoVmQ/CWy4p/I8yF0AmxOwQ6UJinQ7z W11Ltn3z10zAu45v6XU+SmHIqyt5Ll3N6JFcv3K3BzXt+m6RF8RP1iGDnH4KfxjKmUoL 97ruMtVRI8jAI51vvyqDSWqgGeKM/wQUo0xvoUUD8zfYlNC4LPXK3rm+s138TfOx/+g4 sAeQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v7si5043609jas.62.2021.06.16.20.11.43; Wed, 16 Jun 2021 20:11:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231869AbhFPSeI (ORCPT + 99 others); Wed, 16 Jun 2021 14:34:08 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:34156 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231873AbhFPSeH (ORCPT ); Wed, 16 Jun 2021 14:34:07 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1ltaKW-00A8Jk-DK; Wed, 16 Jun 2021 12:32:00 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=email.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1ltaKV-000zav-33; Wed, 16 Jun 2021 12:32:00 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: Michael Schmitz , linux-arch , Jens Axboe , Oleg Nesterov , Al Viro , Linux Kernel Mailing List , Richard Henderson , Ivan Kokshaysky , Matt Turner , alpha , Geert Uytterhoeven , linux-m68k , Arnd Bergmann , Ley Foon Tan , Tejun Heo , Kees Cook References: <87sg1p30a1.fsf@disp2133> <87pmwsytb3.fsf@disp2133> <87sg1lwhvm.fsf@disp2133> <6e47eff8-d0a4-8390-1222-e975bfbf3a65@gmail.com> <924ec53c-2fd9-2e1c-bbb1-3fda49809be4@gmail.com> <87eed4v2dc.fsf@disp2133> <5929e116-fa61-b211-342a-c706dcb834ca@gmail.com> <87fsxjorgs.fsf@disp2133> <87zgvqor7d.fsf_-_@disp2133> <87mtrpg47k.fsf@disp2133> <87pmwlek8d.fsf_-_@disp2133> Date: Wed, 16 Jun 2021 13:31:52 -0500 In-Reply-To: <87pmwlek8d.fsf_-_@disp2133> (Eric W. Biederman's message of "Wed, 16 Jun 2021 13:29:38 -0500") Message-ID: <87k0mtek4n.fsf_-_@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1ltaKV-000zav-33;;;mid=<87k0mtek4n.fsf_-_@disp2133>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/TgZ0Dim61YIRBkDY9kmQTLP1TNitUw5w= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa02.xmission.com X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,XMNoVowels, XMSubLong,XM_B_SpammyWords autolearn=disabled version=3.4.2 X-Spam-Virus: No X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.2 XM_B_SpammyWords One or more commonly used spammy words X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 724 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 3.6 (0.5%), b_tie_ro: 2.5 (0.3%), parse: 0.90 (0.1%), extract_message_metadata: 10 (1.4%), get_uri_detail_list: 3.0 (0.4%), tests_pri_-1000: 11 (1.5%), tests_pri_-950: 1.00 (0.1%), tests_pri_-900: 0.85 (0.1%), tests_pri_-90: 192 (26.6%), check_bayes: 191 (26.4%), b_tokenize: 12 (1.7%), b_tok_get_all: 13 (1.8%), b_comp_prob: 2.8 (0.4%), b_tok_touch_all: 159 (22.0%), b_finish: 0.77 (0.1%), tests_pri_0: 494 (68.3%), check_dkim_signature: 0.47 (0.1%), check_dkim_adsp: 2.4 (0.3%), poll_dns_idle: 0.93 (0.1%), tests_pri_10: 1.83 (0.3%), tests_pri_500: 6 (0.8%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH 1/2] alpha/ptrace: Record and handle the absence of switch_stack X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org While thinking about the information leaks fixed in 77f6ab8b7768 ("don't dump the threads that had been already exiting when zapped.") I realized the problem is much more general than just coredumps and exit_mm. We have io_uring threads, PTRACE_EVENT_FORK, PTRACE_EVENT_VFORK, PTRACE_EVENT_CLONE, PTRACE_EVENT_EXEC and PTRACE_EVENT_EXIT where ptrace is allowed to access userspace registers, but on some architectures has not saved them so they can be modified. The function alpha_switch_to does something reasonable it saves the floating point registers and the caller saved registers and switches to a different thread. Any register the caller is not expected to save it does not save. Meanhile the system call entry point on alpha also does something reasonable. The system call entry point saves all but the caller saved integer registers and doesn't touch the floating point registers as the kernel code does not touch them. This is a nice happy fast path until the kernel wants to access the user space's registers through ptrace or similar. As user spaces's caller saved registers may be saved at an unpredictable point in the kernel code's stack, the routine which may stop and make the userspace registers available must be wrapped by code that will first save a switch stack frame at the bottom of the call stack, call the code that may access those registers and then pop the switch stack frame. The practical problem with this code structure is that this results in a game of whack-a-mole wrapping different kernel system calls. Loosing the game of whack-a-mole results in a security hole where userspace can write arbitrary data to the kernel stack. In general it is not possible to prevent generic code introducing a ptrace_stop or register access not knowing alpha's limitations, that where alpha does not make all of the registers avaliable. Prevent security holes by recording when all of the registers are available so generic code changes do not result in security holes on alpha. Cc: stable@vger.kernel.org Fixes: dbe1bdbb39db ("io_uring: handle signals for IO threads like a normal thread") Fixes: 45c1a159b85b ("Add PTRACE_O_TRACEVFORKDONE and PTRACE_O_TRACEEXIT facilities.") Fixes: a0691b116f6a ("Add new ptrace event tracing mechanism") History-tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Signed-off-by: "Eric W. Biederman" --- arch/alpha/include/asm/thread_info.h | 2 ++ arch/alpha/kernel/entry.S | 38 ++++++++++++++++++++++------ arch/alpha/kernel/ptrace.c | 13 ++++++++-- 3 files changed, 43 insertions(+), 10 deletions(-) diff --git a/arch/alpha/include/asm/thread_info.h b/arch/alpha/include/asm/thread_info.h index 2592356e3215..41e5986ed9c8 100644 --- a/arch/alpha/include/asm/thread_info.h +++ b/arch/alpha/include/asm/thread_info.h @@ -63,6 +63,7 @@ register struct thread_info *__current_thread_info __asm__("$8"); #define TIF_NEED_RESCHED 3 /* rescheduling necessary */ #define TIF_SYSCALL_AUDIT 4 /* syscall audit active */ #define TIF_NOTIFY_SIGNAL 5 /* signal notifications exist */ +#define TIF_ALLREGS_SAVED 6 /* both pt_regs and switch_stack saved */ #define TIF_DIE_IF_KERNEL 9 /* dik recursion lock */ #define TIF_MEMDIE 13 /* is terminating due to OOM killer */ #define TIF_POLLING_NRFLAG 14 /* idle is polling for TIF_NEED_RESCHED */ @@ -73,6 +74,7 @@ register struct thread_info *__current_thread_info __asm__("$8"); #define _TIF_NOTIFY_RESUME (1<ieee_state = ((task_thread_info(task)->ieee_state & ~IEEE_SW_MASK) | (data & IEEE_SW_MASK)); data = (data & FPCR_DYN_MASK) | ieee_swcr_to_fpcr(data); } - *get_reg_addr(task, regno) = data; + addr = get_reg_addr(task, regno); + if (addr != &zero) + *addr = data; return 0; } -- 2.20.1