From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F1F5C433EF for ; Tue, 14 Sep 2021 09:53:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 57ACF604D2 for ; Tue, 14 Sep 2021 09:53:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 57ACF604D2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4294JRJNOzwZZlVAbG37RpJQcsiihy5Y1ouc8dqCTYI=; b=AzjuMeIFPvieDj Av2Mx4k5M3b/SU1nZaD87mztr+qmLbi/YX1HZ0sQZNSPkl9esJA5MJbD2pWWdSxCwoiV8grv9v1o8 hJeW62ldsey0H1TVLuGRsOkn0OrkbyX7e7NbOWxaoebYfCtZrZ1Jzx6GA/liMLs2gA4Qdpevw1tt9 L06fEt+XtVxslxInzmK/SxAaqA6WdH9DUZ45AHu4zI1fCoTA0LPCOJycQYWF5FfWqp7N/5brVBeKe FZAn9uO10v8hII/JoxCQYCkY6U8gnS5k//UgmSIt7wsCFQ91hoGBpafvkVgnLKv/cvisn2oafgc/q dmzoAub0149Jj3ZIr2fg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mQ55Z-0055D4-Ce; Tue, 14 Sep 2021 09:50:53 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mQ55U-0055CE-Ri for linux-arm-kernel@lists.infradead.org; Tue, 14 Sep 2021 09:50:50 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8DF7F6113B for ; Tue, 14 Sep 2021 09:50:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1631613048; bh=zfK1fJW8Yh6+X+h/e2vCvTwWQkzwhMsvLR04tKfAls0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=otvaexDMXT9BkzZkSgAPL6CuMkqR7nNC0+xE10ztTmQcGvdsG1OhdFERKZzi2EySh Z+T6hrnzEpRKfEuR9gp0rUOOnNfG2VFXAHwx6HiUunH3gb/8duutvOnDfMWsvjMYyU HHsFQL5Ob6Fush1xTpJe6+2W3sFoRoHfMkJPFntcSUVl/On3q0oX1IVYWfDqgPWOhG vPa7FYBvpLr2jOtT1hr/wPZ47EwQ3WwzgPJ7O1SltP2lqny8mMyID6NOdkxiT4M8sM XGSFl6n/vQWsBt4CpAN0loV2YsM8lZ77TZh981AKbnnIhV1U+vDDfeOfP3ke7R0cSM TUs8hdpMxjJww== Received: by mail-oi1-f177.google.com with SMTP id n27so18247408oij.0 for ; Tue, 14 Sep 2021 02:50:48 -0700 (PDT) X-Gm-Message-State: AOAM5338XeWDD5DGlkcAntab7c8UkmJ+9eye0Tt0R1DXYcRFFh2Umjdw v3H7cYQN8RSNBzTlM/pKMpuC6tjPGUMzfL7vQ6g= X-Google-Smtp-Source: ABdhPJyFgt9zu8GaFEdGey+pfKF9dE3ao48TnJ1d/kMPHZx0iw3mvlBkVmNeJr0A7CCnP0KxwDEFuWJDCKB+0z48ex8= X-Received: by 2002:a54:418e:: with SMTP id 14mr685262oiy.174.1631613047908; Tue, 14 Sep 2021 02:50:47 -0700 (PDT) MIME-Version: 1.0 References: <20210913104001.3043132-1-ardb@kernel.org> In-Reply-To: From: Ard Biesheuvel Date: Tue, 14 Sep 2021 11:50:36 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 0/5] ARM: support THREAD_INFO_IN_TASK To: Arnd Bergmann Cc: Linux ARM , Keith Packard , Russell King , Kees Cook , Linus Walleij X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210914_025048_971285_09C6A2C3 X-CRM114-Status: GOOD ( 29.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 14 Sept 2021 at 11:44, Arnd Bergmann wrote: > > On Mon, Sep 13, 2021 at 12:39 PM Ard Biesheuvel wrote: > > > > Placing thread_info in the kernel stack leaves it vulnerable to stack > > overflow attacks. This short series addresses that by using the existing > > THREAD_INFO_IN_TASK infrastructure. > > > > This v4 is a follow-up to Keith's v3 [0], which did not address all > > concerns I raised in response to v2. After collaborating with Keith > > off-list, we decided that I should go ahead and post our joint v4. > > > > Changes since v3: > > > > - Leave the CPU field in thread_info, and keep it in sync at context > > switch time. This is by far the easiest and cleanest way to work > > around the fact that it is infeasible to implement > > raw_smp_processor_id() in terms of task_struct::cpu (for reasons of > > header soup). > > > > - Drop the VFP changes, they are no longer necessary given the previous > > point. > > > > - Drop the change to pass the CPU number to secondary_start_kernel(). > > Given that we also need to pass the idle task pointer, which carries > > the CPU number, passing the CPU number directly is redundant. > > > > - Use the TPIDRURO register to carry 'current' while running in the > > kernel, and keep using TPIDRPRW for the per-CPU offset as before. This > > way, there is no need to make any changes to the way the per-CPU offsets > > are programmed. It also avoids the concurrency issues that would > > result from carrying the 'current' pointer in a per-CPU variable. > > > > - Update the per-task stack protector plugin to pull the stack canary > > value directly from the task struct. > > I haven't looked in detail, but it all looks great to me so far. > > On a related note, this reminds me of the CONFIG_IRQSTACK series > that was posted last year[1] and probably attempted before that. > I'd have to get back to understanding all the details of that discussion, > but I have some hope that adding irqstacks would become much > easier after your series. Any thoughts on that? > Yes, not having to rely on the stack pointer for thread_info/current seems to make this a lot easier. And eith mentioned that he is also interested in vmap'ed stacks for ARM, so I have a suspicion that we will end up picking up some IRQ stack changes in the process as well. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel