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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3592C433EF for ; Mon, 6 Dec 2021 21:09:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350074AbhLFVMl (ORCPT ); Mon, 6 Dec 2021 16:12:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229795AbhLFVMk (ORCPT ); Mon, 6 Dec 2021 16:12:40 -0500 Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF349C061746 for ; Mon, 6 Dec 2021 13:09:10 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id c3so14586683iob.6 for ; Mon, 06 Dec 2021 13:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eOK4K4S7Jgnn22bwENxP9eeLDVw5lq+Zz6heR9P+gtQ=; b=CD1fMPDEKBCxndODtqRsbXTz3vws2TAkx518ckSyqOK0qinOz2lWs7dwdfPUR2Q96f 8D0zmV+ENSpmSX3DTg6oqAeda2v9twolMxe/Cc2OnzpxnrfuLzpWNEsx5zRTHX3Ul6kO XN/1bRJbmXQDRL0+XwX3i+aHPRHaM2ecnkGkOr7tYnf9cyoVDuN4/sZHeP7UCa2duFwK TKb41SQNNXZyr5CyMsFrngHhx7foY6Kxd2AHOmX1LExIXBLyP3eAxgH3gIsjI7cdFKON H563Iu6PgFxTct20MCfMEKONwoYLAZ3k+hPvEP0GG2gbSAvB3HnzLRLs8nJdtk9xiJC3 mY/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eOK4K4S7Jgnn22bwENxP9eeLDVw5lq+Zz6heR9P+gtQ=; b=CGW/ir7gcRNb24bNon4JiT6ObsdskGgff4uGE61CbjDao7gik6EyooQG2ReAXbcUyp MtfA+pnIoOrYmmN/q87pFG3tRRIpkR3ZXE4D124G5PvMbJC+IqMzBc9/BRM9ZSMDidza 8Bx38Ddl/aXTfaOsu/8OyJr4aY3EYrN/3Om8m52qEpS10r2ND5s3LyUiJLTrV/fXAI76 fLDyFo7AG/djU6kRIE9ex8eBsnhkUH+9RmS4ygO4TL/9xMPyTe51TLKDihGojUxrjBQQ UdWHRC3H1BidgbD8SMZcZJDf6rWpcZhXqGRm5qaPOv8mwF6ky2YJfOymf5DfG/HbZaSZ 1nQw== X-Gm-Message-State: AOAM5313riMiR8o2lXZQTw2oyo9AvRmOJHzHOuhl3360TdAPOLZ/qNh3 VsmdOjV1VnU6lv6899Z1eF1OLbgwGrwynzsMH/c= X-Google-Smtp-Source: ABdhPJw9EkmCf6QkZW91s5gMVFfWkYgjJogZWLnXjuDYz8eTQxFEDEt9uCWBrQjtqwa7QBLraFvVdJghV1GRrBt3u5I= X-Received: by 2002:a5e:d502:: with SMTP id e2mr38326764iom.118.1638824950346; Mon, 06 Dec 2021 13:09:10 -0800 (PST) MIME-Version: 1.0 References: <4fbc6668845e699bf708aee5c11ad9fd012d4dcd.1638308023.git.andreyknvl@google.com> In-Reply-To: From: Andrey Konovalov Date: Mon, 6 Dec 2021 22:08:59 +0100 Message-ID: Subject: Re: [PATCH 21/31] kasan, fork: don't tag stacks allocated with vmalloc To: Marco Elver Cc: andrey.konovalov@linux.dev, Alexander Potapenko , Vincenzo Frascino , Catalin Marinas , Peter Collingbourne , Dmitry Vyukov , kasan-dev , Andrew Morton , Linux Memory Management List , Will Deacon , Linux ARM , Evgenii Stepanov , LKML , Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 2, 2021 at 3:28 PM Marco Elver wrote: > > On Tue, Nov 30, 2021 at 11:07PM +0100, andrey.konovalov@linux.dev wrote: > > From: Andrey Konovalov > > > > Once tag-based KASAN modes start tagging vmalloc() allocations, > > kernel stacks will start getting tagged if CONFIG_VMAP_STACK is enabled. > > > > Reset the tag of kernel stack pointers after allocation. > > > > For SW_TAGS KASAN, when CONFIG_KASAN_STACK is enabled, the > > instrumentation can't handle the sp register being tagged. > > > > For HW_TAGS KASAN, there's no instrumentation-related issues. However, > > the impact of having a tagged SP pointer needs to be properly evaluated, > > so keep it non-tagged for now. > > Don't VMAP_STACK stacks have guards? So some out-of-bounds would already > be caught. True, linear out-of-bounds accesses are already caught. > What would be the hypothetical benefit of using a tagged stack pointer? > Perhaps wildly out-of-bounds accesses derived from stack pointers? Yes, that's the case that comes to mind. > I agree that unless we understand the impact of using a tagged stack > pointers, it should remain non-tagged for now. Ack. I'll file a KASAN bug for this when the series is merged. > > Note, that the memory for the stack allocation still gets tagged to > > catch vmalloc-into-stack out-of-bounds accesses. > > Will the fact it's tagged cause issues for other code? I think kmemleak > already untags all addresses it scans for pointers. Anything else? Tagging stack memory shouldn't cause any stability issues like conflicts with kmemleak. Tagging memory but not the pointers is not worse than leaving memory tags uninitialized/random with regards to this kind of issues. Thanks! 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 97606C433EF for ; Mon, 6 Dec 2021 21:11:23 +0000 (UTC) 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=+AMvTRTfZUU/Gf7Xb54vEzQZ8ELUXjj2TQg3zS2duX8=; b=Xt5nIg7EaN+rlF KljXqiAQZraAqgYJ+bRFs2+OpE79pJw4R04xQOnBgI9WiYJtPAMiMp2od6P3pQDcxrshvO2QgX0zX VFZOQvXpPa1YlFLKdYiff4TpPFei7Be9NWt0S8aFj1X+LdxtxRQhg3tjveEeUawb2Xq0fPbzfxvqP SPRhm6ttda1JpCRwbGEYq8cIA9Js+BBCwUFdPnXru89uPazJt0rdn8C3rh6D1UTFzKgI1QJSQT0Nl GoFhaFlpiQLovThyms5lO7Js7Jk4Gn2L7AK46H5QpQshDxa3dVoFXv1KFkjjRDHCQdttEPHZhYOL+ Oulo4IGmR1cxo5h94DXA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muLEt-005kMH-9O; Mon, 06 Dec 2021 21:09:35 +0000 Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1muLEV-005kBa-Vp for linux-arm-kernel@lists.infradead.org; Mon, 06 Dec 2021 21:09:13 +0000 Received: by mail-io1-xd35.google.com with SMTP id x6so14449980iol.13 for ; Mon, 06 Dec 2021 13:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eOK4K4S7Jgnn22bwENxP9eeLDVw5lq+Zz6heR9P+gtQ=; b=CD1fMPDEKBCxndODtqRsbXTz3vws2TAkx518ckSyqOK0qinOz2lWs7dwdfPUR2Q96f 8D0zmV+ENSpmSX3DTg6oqAeda2v9twolMxe/Cc2OnzpxnrfuLzpWNEsx5zRTHX3Ul6kO XN/1bRJbmXQDRL0+XwX3i+aHPRHaM2ecnkGkOr7tYnf9cyoVDuN4/sZHeP7UCa2duFwK TKb41SQNNXZyr5CyMsFrngHhx7foY6Kxd2AHOmX1LExIXBLyP3eAxgH3gIsjI7cdFKON H563Iu6PgFxTct20MCfMEKONwoYLAZ3k+hPvEP0GG2gbSAvB3HnzLRLs8nJdtk9xiJC3 mY/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eOK4K4S7Jgnn22bwENxP9eeLDVw5lq+Zz6heR9P+gtQ=; b=O/BgUdIBKLX8aJeTtdEiH+1HHbNA5kWe2teP4Pqjymsi1JJtUBJJgqH5kdp1mtxg1x 8K+KkbmUzwj/B0A92AIzsVo7RyEUtG+Fu6rsGVMbSua77Em79VFk5ve7jscKgX+vVJie SdC+DM3tY2TH2jypEn0gy6M25O6SBQ9DZa71jKsRKSiayOCCSj802ivCX0HRz+IN2l7L h81DRq6XV19oS1az9xGUecUX9S+tepmq4NGWddp3gJcNLXfQLBWW2DtuVBb36GN0yrYo gdcWS0BQcjaLcbVMwnpeD9lejIjLYqakwlNIfVa18gj8T28gbghpf+gBukUQD5ve+Ej1 kf4w== X-Gm-Message-State: AOAM5309ca0E3Cdz84MLL8em2W5La0MEFFEieD7uX+pgMOL9DucYdZU2 Y/b9l5LS5AcF2NyfIjkMg59Nq1Z1YSTF9t4WAM8= X-Google-Smtp-Source: ABdhPJw9EkmCf6QkZW91s5gMVFfWkYgjJogZWLnXjuDYz8eTQxFEDEt9uCWBrQjtqwa7QBLraFvVdJghV1GRrBt3u5I= X-Received: by 2002:a5e:d502:: with SMTP id e2mr38326764iom.118.1638824950346; Mon, 06 Dec 2021 13:09:10 -0800 (PST) MIME-Version: 1.0 References: <4fbc6668845e699bf708aee5c11ad9fd012d4dcd.1638308023.git.andreyknvl@google.com> In-Reply-To: From: Andrey Konovalov Date: Mon, 6 Dec 2021 22:08:59 +0100 Message-ID: Subject: Re: [PATCH 21/31] kasan, fork: don't tag stacks allocated with vmalloc To: Marco Elver Cc: andrey.konovalov@linux.dev, Alexander Potapenko , Vincenzo Frascino , Catalin Marinas , Peter Collingbourne , Dmitry Vyukov , kasan-dev , Andrew Morton , Linux Memory Management List , Will Deacon , Linux ARM , Evgenii Stepanov , LKML , Andrey Konovalov X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211206_130912_069041_EB6F59DD X-CRM114-Status: GOOD ( 19.36 ) 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 Thu, Dec 2, 2021 at 3:28 PM Marco Elver wrote: > > On Tue, Nov 30, 2021 at 11:07PM +0100, andrey.konovalov@linux.dev wrote: > > From: Andrey Konovalov > > > > Once tag-based KASAN modes start tagging vmalloc() allocations, > > kernel stacks will start getting tagged if CONFIG_VMAP_STACK is enabled. > > > > Reset the tag of kernel stack pointers after allocation. > > > > For SW_TAGS KASAN, when CONFIG_KASAN_STACK is enabled, the > > instrumentation can't handle the sp register being tagged. > > > > For HW_TAGS KASAN, there's no instrumentation-related issues. However, > > the impact of having a tagged SP pointer needs to be properly evaluated, > > so keep it non-tagged for now. > > Don't VMAP_STACK stacks have guards? So some out-of-bounds would already > be caught. True, linear out-of-bounds accesses are already caught. > What would be the hypothetical benefit of using a tagged stack pointer? > Perhaps wildly out-of-bounds accesses derived from stack pointers? Yes, that's the case that comes to mind. > I agree that unless we understand the impact of using a tagged stack > pointers, it should remain non-tagged for now. Ack. I'll file a KASAN bug for this when the series is merged. > > Note, that the memory for the stack allocation still gets tagged to > > catch vmalloc-into-stack out-of-bounds accesses. > > Will the fact it's tagged cause issues for other code? I think kmemleak > already untags all addresses it scans for pointers. Anything else? Tagging stack memory shouldn't cause any stability issues like conflicts with kmemleak. Tagging memory but not the pointers is not worse than leaving memory tags uninitialized/random with regards to this kind of issues. Thanks! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel