Message ID | 20231213163443.70490-4-brgerst@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp7903145dys; Wed, 13 Dec 2023 08:35:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IGGu8q3531U4hT8rIv0Ckp+dDYVCzhsGKnOr4zC2tZseZysEfDp0YPU7Iwz2KGIHezvUCly X-Received: by 2002:a17:902:c20c:b0:1d3:563c:8481 with SMTP id 12-20020a170902c20c00b001d3563c8481mr456089pll.74.1702485305948; Wed, 13 Dec 2023 08:35:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702485305; cv=none; d=google.com; s=arc-20160816; b=luiHPWXvINuwH0k40nwspE93XkC//BkeOF13L/kAzKR1h9qmFnh2qQGnpCX1X2sawx zZ9rLrkKaulKggXt7wDVRf1VL2kxPuhG84VV/wyfAV4BZnUayHkmYONRbKM2aR9yzwNy tV/VGLjFqYs7jwfH5ZKmP+6/Pbl6vF1WxPJIzivyrXb0Dte+zvkoZja3P0YjcagGds8p wM6W+XD1JkjBUVJE8SdPjRjzW3srI81CjvwzUVArgZZ6/bkhhMT2lSoPUE1CJXSBu92U Af82K2BXMiTmhpelFLR+C4BU4V8bynhmKV+U3uX3aKp92q/IX6239ZOzV1H3ThogCah5 Onbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=jyOMuEpj1SBQevcg7f2PgWvrxn60g/AMBaY0W3leFwk=; fh=nSVMSW83lejZbFdTiv+5xB+4w4gGwIIYXzyvCgPKrjo=; b=f5OF84fBWkGz0K1Ed8UpLT65xk8kpI+wkRa0d2yb0KY4DcFz4pC2i4JZHK2eGrrDrv uL5wDYTMHBh3qkpKsyZycfQ8Sq+3moH2ugVg5rHebs7xy+mIkFoQVNifPRiBrM0HzsVq GyQdjG6EVz1vWwuB16aJpKMPk9Pv7cohDMWj/P0op4tu1BJaFouIkZCULsMV756dZxXM 4QbQt0wT2WeUVz1+JrI4Qn/pI/0Rcr6Y/fApFdJWVAcCHcIeUuvh/spy5LFXhtrY7qpQ LulUomLq5REb0en63rsNOm2x6lxVTe1JLT6iNtJPL0po5cK35pdp8ulF8Ct8QyMNTSJw LABg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=m81KjJJ1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id v10-20020a1709029a0a00b001cfdd31f20esi9629138plp.267.2023.12.13.08.35.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 08:35:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=m81KjJJ1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 417CB8030287; Wed, 13 Dec 2023 08:35:04 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233449AbjLMQev (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Wed, 13 Dec 2023 11:34:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233153AbjLMQep (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 13 Dec 2023 11:34:45 -0500 Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7893C8E for <linux-kernel@vger.kernel.org>; Wed, 13 Dec 2023 08:34:51 -0800 (PST) Received: by mail-oo1-xc2d.google.com with SMTP id 006d021491bc7-5913b73b53eso1265510eaf.0 for <linux-kernel@vger.kernel.org>; Wed, 13 Dec 2023 08:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702485290; x=1703090090; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=jyOMuEpj1SBQevcg7f2PgWvrxn60g/AMBaY0W3leFwk=; b=m81KjJJ1PWZsp9wAVgDcEHLyEs9BNpTWYX/Q+7NL3kvYFhxl4LXD9nseLsd0NPQGPD uJew29+9z06vOUhvMa85+SKKRiF3fD9MQKbdJDlEhiCOE9DH/TYDXdIX2Eft7518eUbd 2m6+zFjCopTgKWfOoitYLdGnzY8oFyEx0p3OzDrS1PulwVJ2B5fNzANcWyoK0twOn/Qp sLsULxYAHy/HnSXXg+EOzy1DRKNNeEunfXowqmw547/k1cFDaGwH6byK5/qo1ikueUKv auD/oVRgizQ/Sx8iyxJBonBMCwpJIes5xluw5LysLPnBqy0wy0t12SB9VoJ9KA+mBFLJ 05Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702485290; x=1703090090; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jyOMuEpj1SBQevcg7f2PgWvrxn60g/AMBaY0W3leFwk=; b=YniPh+xF/b8FfsyQBKgm1Q923s82l7e6nIPrnepJHimQ1W7kLVpO4kilFQSU9Hdjlw jkwTvxH8n9ZeHwp5mfKBGjYKMRkDqFxCNk5gc6CetfndDNyQr2rMtaiGoHGfGtLHAGkn RAYu1OTyB2NiY4Pw8LLRXu8EOnqZzpJdRr+LNpD4uhGH1PkKmYRavRNz3I9uGuK+9mCA ybUR8BvJ9EGW2wzoJVAYUzpoWulZPq623uEhBX7p9njY5STgNIZbd8VdPUH7V/Rrud6I 60lX3Q+8lrUOmCaIymuWrNxNtV925qpTYIWeM+Ax7bLUCYR/cGSPy36ZViuiCf6C7bkB /Xnw== X-Gm-Message-State: AOJu0YzelOIwHadvlbwbIApgDOdCUTzgClbrXWSMH71rwfcyZ2iudoIN e2unK9HKBm+9W9QKlfMgXNjpiWPIZQ== X-Received: by 2002:a4a:ab09:0:b0:590:7382:8b92 with SMTP id i9-20020a4aab09000000b0059073828b92mr4978248oon.11.1702485290439; Wed, 13 Dec 2023 08:34:50 -0800 (PST) Received: from citadel.lan ([2600:6c4a:4d3f:6d5c::1019]) by smtp.gmail.com with ESMTPSA id j11-20020a4ad2cb000000b005907ad9f302sm3104901oos.37.2023.12.13.08.34.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 08:34:49 -0800 (PST) From: Brian Gerst <brgerst@gmail.com> To: linux-kernel@vger.kernel.org, x86@kernel.org Cc: Ingo Molnar <mingo@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>, Peter Zijlstra <peterz@infradead.org>, Linus Torvalds <torvalds@linuxfoundation.org>, Brian Gerst <brgerst@gmail.com>, Michal Luczaj <mhal@rbox.co> Subject: [PATCH 3/3] x86/sigreturn: Reject system segements Date: Wed, 13 Dec 2023 11:34:43 -0500 Message-ID: <20231213163443.70490-4-brgerst@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20231213163443.70490-1-brgerst@gmail.com> References: <20231213163443.70490-1-brgerst@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 13 Dec 2023 08:35:04 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785185232535852030 X-GMAIL-MSGID: 1785185232535852030 |
Series |
Reject setting system segments from userspace
|
|
Commit Message
Brian Gerst
Dec. 13, 2023, 4:34 p.m. UTC
Do not allow system segments (TSS and LDT) from being loaded into segment
registers via sigreturn. Loading these segments into a segment register
normally results in a general protection fault. In the case of sigreturn,
setting CS or SS to a system segment will cause IRET to fault. This
then results in the instruction decoder attempting to use the invalid
segment. This can be avoided by rejecting system segments in the
sigreturn() syscall.
Signed-off-by: Brian Gerst <brgerst@gmail.com>
Reported-By: Michal Luczaj <mhal@rbox.co>
Link: https://lore.kernel.org/lkml/20231206004654.2986026-1-mhal@rbox.co/
---
arch/x86/kernel/signal_32.c | 4 ++++
arch/x86/kernel/signal_64.c | 4 ++++
2 files changed, 8 insertions(+)
Comments
On Wed, 13 Dec 2023 at 08:34, Brian Gerst <brgerst@gmail.com> wrote: > > @@ -98,7 +98,11 @@ static bool ia32_restore_sigcontext(struct pt_regs *regs, > > /* Get CS/SS and force CPL3 */ > regs->cs = sc.cs | 0x03; > + if (!valid_user_selector(regs->cs)) > + return false; > regs->ss = sc.ss | 0x03; > + if (!valid_user_selector(regs->ss)) > + return false; Side note: the SS/CS checks could be stricter than the usual selector tests. In particular, normal segments can be Null segments. But CS/SS must not be. Also, since you're now checking the validity, maybe we shouldn't do the "force cpl3" any more, and just make it an error to try to load a non-cpl3 segment at sigreturn.. That forcing was literally just because we weren't checking it for sanity... Linus
On December 13, 2023 10:54:00 AM PST, Linus Torvalds <torvalds@linuxfoundation.org> wrote: >On Wed, 13 Dec 2023 at 08:34, Brian Gerst <brgerst@gmail.com> wrote: >> >> @@ -98,7 +98,11 @@ static bool ia32_restore_sigcontext(struct pt_regs *regs, >> >> /* Get CS/SS and force CPL3 */ >> regs->cs = sc.cs | 0x03; >> + if (!valid_user_selector(regs->cs)) >> + return false; >> regs->ss = sc.ss | 0x03; >> + if (!valid_user_selector(regs->ss)) >> + return false; > >Side note: the SS/CS checks could be stricter than the usual selector tests. > >In particular, normal segments can be Null segments. But CS/SS must not be. > >Also, since you're now checking the validity, maybe we shouldn't do >the "force cpl3" any more, and just make it an error to try to load a >non-cpl3 segment at sigreturn.. > >That forcing was literally just because we weren't checking it for sanity... > > Linus Not to mention that changing a null descriptor to 3 is wrong.
On Sun, 17 Dec 2023 at 13:08, H. Peter Anvin <hpa@zytor.com> wrote: > > On December 13, 2023 10:54:00 AM PST, Linus Torvalds <torvalds@linuxfoundation.org> wrote: ]> >Side note: the SS/CS checks could be stricter than the usual selector tests. > > > >In particular, normal segments can be Null segments. But CS/SS must not be. > > > >Also, since you're now checking the validity, maybe we shouldn't do > >the "force cpl3" any more, and just make it an error to try to load a > >non-cpl3 segment at sigreturn.. > > > >That forcing was literally just because we weren't checking it for sanity... > > > > Linus > > Not to mention that changing a null descriptor to 3 is wrong. I don't think it is. All of 0-3 are "Null selectors". The RPL of the selector simply doesn't matter when the index is zero, afaik. But we obviously only do this for CS/SS, which can't be (any kind of) Null selector and iret will GP on them regardless of the RPL in the selector. Linus
On December 17, 2023 1:40:53 PM PST, Linus Torvalds <torvalds@linuxfoundation.org> wrote: >On Sun, 17 Dec 2023 at 13:08, H. Peter Anvin <hpa@zytor.com> wrote: >> >> On December 13, 2023 10:54:00 AM PST, Linus Torvalds <torvalds@linuxfoundation.org> wrote: >]> >Side note: the SS/CS checks could be stricter than the usual selector tests. >> > >> >In particular, normal segments can be Null segments. But CS/SS must not be. >> > >> >Also, since you're now checking the validity, maybe we shouldn't do >> >the "force cpl3" any more, and just make it an error to try to load a >> >non-cpl3 segment at sigreturn.. >> > >> >That forcing was literally just because we weren't checking it for sanity... >> > >> > Linus >> >> Not to mention that changing a null descriptor to 3 is wrong. > >I don't think it is. All of 0-3 are "Null selectors". The RPL of the >selector simply doesn't matter when the index is zero, afaik. > >But we obviously only do this for CS/SS, which can't be (any kind of) >Null selector and iret will GP on them regardless of the RPL in the >selector. > > Linus Of course not for CS/SS, but I would agree that if the selector is 0 before the signal it shouldn't mysteriously and asynchronously become 3.
> -----Original Message----- > From: H. Peter Anvin <hpa@zytor.com> > Sent: Sunday, December 17, 2023 1:46 PM > To: Linus Torvalds <torvalds@linuxfoundation.org> > Cc: Brian Gerst <brgerst@gmail.com>; linux-kernel@vger.kernel.org; > x86@kernel.org; Ingo Molnar <mingo@kernel.org>; Thomas Gleixner > <tglx@linutronix.de>; Borislav Petkov <bp@alien8.de>; Peter Zijlstra > <peterz@infradead.org>; Michal Luczaj <mhal@rbox.co> > Subject: Re: [PATCH 3/3] x86/sigreturn: Reject system segements > > On December 17, 2023 1:40:53 PM PST, Linus Torvalds > <torvalds@linuxfoundation.org> wrote: > >On Sun, 17 Dec 2023 at 13:08, H. Peter Anvin <hpa@zytor.com> wrote: > >> > >> On December 13, 2023 10:54:00 AM PST, Linus Torvalds > <torvalds@linuxfoundation.org> wrote: > >]> >Side note: the SS/CS checks could be stricter than the usual selector tests. > >> > > >> >In particular, normal segments can be Null segments. But CS/SS must not be. > >> > > >> >Also, since you're now checking the validity, maybe we shouldn't do > >> >the "force cpl3" any more, and just make it an error to try to load > >> >a > >> >non-cpl3 segment at sigreturn.. > >> > > >> >That forcing was literally just because we weren't checking it for sanity... > >> > > >> > Linus > >> > >> Not to mention that changing a null descriptor to 3 is wrong. > > > >I don't think it is. All of 0-3 are "Null selectors". The RPL of the > >selector simply doesn't matter when the index is zero, afaik. > > > >But we obviously only do this for CS/SS, which can't be (any kind of) > >Null selector and iret will GP on them regardless of the RPL in the > >selector. > > > > Linus > > Of course not for CS/SS, but I would agree that if the selector is 0 before the > signal it shouldn't mysteriously and asynchronously become 3. Unfortunately reload_segments() _always_ sets DPL bits of GS/FS/DS/ES to 3, even for 0. And IRET clears DPL bits when loading a NULL selector into GS/FS/DS/ES: https://lore.kernel.org/lkml/20230706052231.2183-1-xin3.li@intel.com/ Thanks! Xin
diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index c12624bc82a3..0e1926b676b0 100644 --- a/arch/x86/kernel/signal_32.c +++ b/arch/x86/kernel/signal_32.c @@ -98,7 +98,11 @@ static bool ia32_restore_sigcontext(struct pt_regs *regs, /* Get CS/SS and force CPL3 */ regs->cs = sc.cs | 0x03; + if (!valid_user_selector(regs->cs)) + return false; regs->ss = sc.ss | 0x03; + if (!valid_user_selector(regs->ss)) + return false; regs->flags = (regs->flags & ~FIX_EFLAGS) | (sc.flags & FIX_EFLAGS); /* disable syscall checks */ diff --git a/arch/x86/kernel/signal_64.c b/arch/x86/kernel/signal_64.c index 23d8aaf8d9fd..666b147bf43a 100644 --- a/arch/x86/kernel/signal_64.c +++ b/arch/x86/kernel/signal_64.c @@ -79,7 +79,11 @@ static bool restore_sigcontext(struct pt_regs *regs, /* Get CS/SS and force CPL3 */ regs->cs = sc.cs | 0x03; + if (!valid_user_selector(regs->cs)) + return false; regs->ss = sc.ss | 0x03; + if (!valid_user_selector(regs->ss)) + return false; regs->flags = (regs->flags & ~FIX_EFLAGS) | (sc.flags & FIX_EFLAGS); /* disable syscall checks */