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.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 A7F1DC4332B for ; Mon, 1 Feb 2021 14:42:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7B15A6024A for ; Mon, 1 Feb 2021 14:42:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231438AbhBAOmj (ORCPT ); Mon, 1 Feb 2021 09:42:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231226AbhBAOlJ (ORCPT ); Mon, 1 Feb 2021 09:41:09 -0500 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DB47C061797 for ; Mon, 1 Feb 2021 06:39:51 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id z6so16775567wrq.10 for ; Mon, 01 Feb 2021 06:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=b+vMwmkWUJjaj+TgGQx4IfyQcf4QX6ABMPeENh1qYYc=; b=Jp7zN4K6VvzvUN68FSmA9L668KpFR1i/FFujyHS9g7Z874L2MRY7WNhQ2Ti2CLVyI0 CXsMgnMhu7OVtwrqF0OZU+F3f7d5Deq8kwxVfizR8Pn/5IWvg3LR0aZcxzQR88dKXSTV 3iC9lcrOCZZwZFXND3zAW7+G0f9583Xnfc8s5TiWll5zefCRhAlhyp1SoZ2DND7zYCcv wAyCjyEN2y5FY/QdJhKyRghoEAuDUeVlRuV7onEz66v8VS3+RQZSjz6HbqKS+bHB5yMx ahfC0jNLrYtywK9cxBYurMQCtJWsRFIRhKNvO0LrB3MEFdDW0/r4oDAmW2+ek5GJbSKw rW6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=b+vMwmkWUJjaj+TgGQx4IfyQcf4QX6ABMPeENh1qYYc=; b=HKTa14jf9prO5s3uM9ZlM5I+DsO9LdIRPCWSEMzDHrToEkOE4ifTqjS3marennj7Am VXiuLniGnkNUChjKLlEG5eNXgSEQ53bPlKOD2HYrcTFvDqUzRAc4pdjYRjru7gBkbJe+ XSecrsx2ZL/qyCyX8+h1X1fw5X57Fgc7qUdVOr/qehI+Ft7qCaahysFboQbsXBS0wfyo oZu0cSiSNYbVJzTac01BQhaZ9Fnm9TBy5nbPfxcbzAvYcZkRyDKltsNEU80QAXxTlnXj tBZAQj32np7+5qp5mrYfmO08M+OXAJdhIGhwd6bVbMAvMatkVcul/SQ/kzHMUQ1y1YVg 61ew== X-Gm-Message-State: AOAM5329P5VovfYKvaUgb1NWIypLkQNpzZEWqpDJJT9SxZYzb62Mfsgj hlQHkYQt9ryOhNUw1qFFZTc= X-Google-Smtp-Source: ABdhPJxyxUEjlwLDIJDRbBZJqsSGQLUnS1iu3XnDm9EPTJnMTpxjA/oPPbzS/+pRdVxTAGJj6Cth+g== X-Received: by 2002:adf:f782:: with SMTP id q2mr18530058wrp.181.1612190390193; Mon, 01 Feb 2021 06:39:50 -0800 (PST) Received: from p4 (net-93-70-85-165.cust.vodafonedsl.it. [93.70.85.165]) by smtp.gmail.com with ESMTPSA id y17sm16050wmi.21.2021.02.01.06.39.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Feb 2021 06:39:49 -0800 (PST) Date: Mon, 1 Feb 2021 14:39:46 +0000 From: Giancarlo Ferrari To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, rppt@kernel.org, penberg@kernel.org, geert@linux-m68k.org, giancarlo.ferrari@nokia.com Subject: Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated Message-ID: <20210201143943.GA15399@p4> References: <1612140296-12546-1-git-send-email-giancarlo.ferrari89@gmail.com> <20210201124720.GA66060@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210201124720.GA66060@C02TD0UTHF1T.local> User-Agent: Mutt/1.5.24 (2015-08-30) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, Feb 01, 2021 at 12:47:20PM +0000, Mark Rutland wrote: > On Mon, Feb 01, 2021 at 12:44:56AM +0000, Giancarlo Ferrari wrote: > > machine_kexec() need to set rw permission in text and rodata sections > > to assign some variables (e.g. kexec_start_address). To do that at > > the end (after flushing pdm in memory, etc.) it needs to invalidate > > TLB [section] entries. > > It'd be worth noting explicitly that set_kernel_text_rw() alters > current->active_mm... > > > If during the TLB invalidation an interrupt occours, which might cause > > a context switch, there is the risk to inject invalid TLBs, with ro > > permissions. > > ... which is why if there's a context switch things can go wrong, since > active_mm isn't stable, and so it's possible that set_kernel_text_rw() > updates multiple tables, none of which might be the active table at the > point we try to make an access. > Maybe the behaviour causing issue is not completely clear to me, and I do apologize for that (moreover I haven't eougth debug capabilities). However, current-active_mm is switched among context switches. Correct ? So, in principle, the invalidation, if stopped, is carried on where it left. I thought the issue was that the PageTable entry for the section 0x8010_0000 is global, thus not indexed by ASID (Address Space ID). By the fact that each process has its own version of that entry, is the cause of the issue, as the schedule process might bringing a spurious entry (with ro permission) in the MMU cache. If the entry is not global holds the ASID, and the issue cannot happen. Please note that this behaviour was tested on a armv7 arch board. > It would be nice to spell that out rather than saying "invalid TLBs". > > We could disable preemption to prevent that, which is possibly better > than disabling interrupts. > > Overall, it would be much better to avoid having to mess with the kernel > page tables. So rather than going: > > 1. mark kernel RW > 2. alter variables in reloc code > 3. copy reloc code into buffer > 4. branch to buffer > > ... we should be able to go: > > 1. copy reloc code into buffer > 2. alter variables in copy of reloc code > 3. branch to buffer > > ... which would avoid this class of problem too. > > Thanks, > Mark. Thanks, GF 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=-2.2 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 5D7E8C433DB for ; Mon, 1 Feb 2021 14:41:13 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 1E91D61481 for ; Mon, 1 Feb 2021 14:41:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E91D61481 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=C1+w0NAuNVNbLeKf65kQ/EYp9H6yEIeDqW5cOfN3kU0=; b=sv5Si5gCaavMr3xX4z6eFDgcU 91VCPTNtAPHN1BmEzOvd+5k7mkoZAhlp8UA+x/GKiUtj13deJigEMIXascOUtamcFTDZNUBuCUpu+ PRd74JFcZJ0ezGexcep2YwEBDLtka5iOePns/I0lpNCx3KhGNDorkPwcWnslqBwyjjXqV3uc+WP47 ezd8yDEEu2Xq1yHGrKdO5nS1taGkr288TMbZaMlzUs+0onVpzGZsFiiFUOySlN9rYIkiOrUnoH06T DQkOFyfwAQadkDNGVqyOiuUI7q+Xi4fah6WSirVpviiRlRQwSxNagBvlZ+RuG7UQOwnc57Lhkiz3D mRAskfvhA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6aMs-0007Uf-IN; Mon, 01 Feb 2021 14:39:54 +0000 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6aMp-0007UB-PY for linux-arm-kernel@lists.infradead.org; Mon, 01 Feb 2021 14:39:52 +0000 Received: by mail-wr1-x42c.google.com with SMTP id g10so16846782wrx.1 for ; Mon, 01 Feb 2021 06:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=b+vMwmkWUJjaj+TgGQx4IfyQcf4QX6ABMPeENh1qYYc=; b=Jp7zN4K6VvzvUN68FSmA9L668KpFR1i/FFujyHS9g7Z874L2MRY7WNhQ2Ti2CLVyI0 CXsMgnMhu7OVtwrqF0OZU+F3f7d5Deq8kwxVfizR8Pn/5IWvg3LR0aZcxzQR88dKXSTV 3iC9lcrOCZZwZFXND3zAW7+G0f9583Xnfc8s5TiWll5zefCRhAlhyp1SoZ2DND7zYCcv wAyCjyEN2y5FY/QdJhKyRghoEAuDUeVlRuV7onEz66v8VS3+RQZSjz6HbqKS+bHB5yMx ahfC0jNLrYtywK9cxBYurMQCtJWsRFIRhKNvO0LrB3MEFdDW0/r4oDAmW2+ek5GJbSKw rW6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=b+vMwmkWUJjaj+TgGQx4IfyQcf4QX6ABMPeENh1qYYc=; b=Es1HssfwnEjiTCXDEdxiwjS1i1yNYHeN7+cwD9U/6iV5AHhkLOVYNeJ20Rb3ifnibJ o7D4m/aWXy3ir1aKO/0ANnanPBbYGwKkJJ6OuqO241ql4b5lzS8M2PenDb+Kic1R9aR8 YfOCHXsY0vEulFiDzlqQiFjhl+uc1W414pFL2FrQ+qMtlexTaA36RSULUSmtjuwQ1ZC1 SvTNTeUSyBKr4OzcbgtVM4WPUnezsoCXvKThrDHY4UtJ0LGzIL3mQdyt6iqOikO0ewrJ MJaoO+Bqejqump2wNeRSl9hZTueeScvAasYOB4kLEfTSZ015QBwT1KV4fM3lY2vxvgDG GuwA== X-Gm-Message-State: AOAM532oUUJn+530SKHvdbco3pkQ1bDQLDQiMQFm4aKQv4eNfiwsfacu NJpHDwKfrFqdiy21/rjB87U= X-Google-Smtp-Source: ABdhPJxyxUEjlwLDIJDRbBZJqsSGQLUnS1iu3XnDm9EPTJnMTpxjA/oPPbzS/+pRdVxTAGJj6Cth+g== X-Received: by 2002:adf:f782:: with SMTP id q2mr18530058wrp.181.1612190390193; Mon, 01 Feb 2021 06:39:50 -0800 (PST) Received: from p4 (net-93-70-85-165.cust.vodafonedsl.it. [93.70.85.165]) by smtp.gmail.com with ESMTPSA id y17sm16050wmi.21.2021.02.01.06.39.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Feb 2021 06:39:49 -0800 (PST) Date: Mon, 1 Feb 2021 14:39:46 +0000 From: Giancarlo Ferrari To: Mark Rutland Subject: Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated Message-ID: <20210201143943.GA15399@p4> References: <1612140296-12546-1-git-send-email-giancarlo.ferrari89@gmail.com> <20210201124720.GA66060@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210201124720.GA66060@C02TD0UTHF1T.local> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210201_093951_876101_3A704D11 X-CRM114-Status: GOOD ( 25.03 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux@armlinux.org.uk, linux-kernel@vger.kernel.org, penberg@kernel.org, geert@linux-m68k.org, linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, rppt@kernel.org, giancarlo.ferrari@nokia.com 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 Hi, On Mon, Feb 01, 2021 at 12:47:20PM +0000, Mark Rutland wrote: > On Mon, Feb 01, 2021 at 12:44:56AM +0000, Giancarlo Ferrari wrote: > > machine_kexec() need to set rw permission in text and rodata sections > > to assign some variables (e.g. kexec_start_address). To do that at > > the end (after flushing pdm in memory, etc.) it needs to invalidate > > TLB [section] entries. > > It'd be worth noting explicitly that set_kernel_text_rw() alters > current->active_mm... > > > If during the TLB invalidation an interrupt occours, which might cause > > a context switch, there is the risk to inject invalid TLBs, with ro > > permissions. > > ... which is why if there's a context switch things can go wrong, since > active_mm isn't stable, and so it's possible that set_kernel_text_rw() > updates multiple tables, none of which might be the active table at the > point we try to make an access. > Maybe the behaviour causing issue is not completely clear to me, and I do apologize for that (moreover I haven't eougth debug capabilities). However, current-active_mm is switched among context switches. Correct ? So, in principle, the invalidation, if stopped, is carried on where it left. I thought the issue was that the PageTable entry for the section 0x8010_0000 is global, thus not indexed by ASID (Address Space ID). By the fact that each process has its own version of that entry, is the cause of the issue, as the schedule process might bringing a spurious entry (with ro permission) in the MMU cache. If the entry is not global holds the ASID, and the issue cannot happen. Please note that this behaviour was tested on a armv7 arch board. > It would be nice to spell that out rather than saying "invalid TLBs". > > We could disable preemption to prevent that, which is possibly better > than disabling interrupts. > > Overall, it would be much better to avoid having to mess with the kernel > page tables. So rather than going: > > 1. mark kernel RW > 2. alter variables in reloc code > 3. copy reloc code into buffer > 4. branch to buffer > > ... we should be able to go: > > 1. copy reloc code into buffer > 2. alter variables in copy of reloc code > 3. branch to buffer > > ... which would avoid this class of problem too. > > Thanks, > Mark. Thanks, GF _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel