From patchwork Thu Feb 19 18:20:41 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Pali_Roh=C3=A1r?= X-Patchwork-Id: 5853461 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1FD8A9F269 for ; Thu, 19 Feb 2015 18:20:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 43D17202BE for ; Thu, 19 Feb 2015 18:20:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 564292012D for ; Thu, 19 Feb 2015 18:20:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752756AbbBSSUq (ORCPT ); Thu, 19 Feb 2015 13:20:46 -0500 Received: from mail-we0-f181.google.com ([74.125.82.181]:40058 "EHLO mail-we0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752210AbbBSSUp (ORCPT ); Thu, 19 Feb 2015 13:20:45 -0500 Received: by wesx3 with SMTP id x3so1368512wes.7 for ; Thu, 19 Feb 2015 10:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=63cuckNKfLRlpMEsrpexEKuM38yuOFl8r8WbNFtX1sA=; b=fsKiIJxcFKL2tsn/PeAH1FMhFoY9nVRiFhEhIEpWfMHRN06EYFRH5knf2kUX4Cmrfu qo6pJVHY0yJCvG4yxuanna7LvD+j41AqQDnq5nIDqsO5UxcCJN2YfGnXowWLNv4MvA0t IpwcNXxuVBP+QJH4giGMVOi/KrAQphBTjcn3JsMjWrdxf85k4fcmM9SfmIjzogZJQuU3 nI6KMouohPrGGlC1W4cgc9KCrXkBlTI7bmUWkUuAyYOum0+40cy7mJheoFXkVjHsRyS6 PHzcwUiHSNuIOYjnl4y3DlpKiqHGeWioup9rs/LH3dfe7EZWl2Cyne416jpunfubzLQL weIg== X-Received: by 10.194.80.193 with SMTP id t1mr12155197wjx.8.1424370043153; Thu, 19 Feb 2015 10:20:43 -0800 (PST) Received: from pali-latitude.localnet ([2001:718:1e03:a01::1ca]) by mx.google.com with ESMTPSA id fu1sm9098978wic.2.2015.02.19.10.20.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Feb 2015 10:20:42 -0800 (PST) From: Pali =?utf-8?q?Roh=C3=A1r?= To: Matthijs van Duin Subject: Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot) Date: Thu, 19 Feb 2015 19:20:41 +0100 User-Agent: KMail/1.13.7 (Linux/3.13.0-45-generic; KDE/4.14.2; x86_64; ; ) Cc: Tony Lindgren , Sebastian Reichel , linux-omap@vger.kernel.org, Aaro Koskinen , Pavel Machek , Nishanth Menon , "linux-arm-kernel@lists.infradead.org" References: <20131206213613.GA19648@earth.universe> <201502111339.54480@pali> In-Reply-To: MIME-Version: 1.0 Message-Id: <201502191920.41284@pali> Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, T_TVD_MIME_EPI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wednesday 11 February 2015 16:22:51 Matthijs van Duin wrote: > On 11 February 2015 at 13:39, Pali Rohár wrote: > >> Anyhow, since checking the firewalls/APs to see if you have > >> permission will probably only get you yet another fault if > >> things are walled off, the robust way of dealing with this > >> sort of situation is by probing the device with a read > >> while trapping bus faults. This also handles modules that > >> are unreachable for other reasons, e.g. being disabled by > >> eFuse. > > > > It is possible to patch kernel code to mask or ignore that > > fault? Can you help me with something like that? > > As I mentioned, I'm still learning my way around the kernel, > so I don't feel very comfortable suggesting a concrete patch > just yet. I've been browsing arch/arm/mm/ however and my > impression is that all that would be required is editing > fault.c by making a copy of do_bad but containing > return user_mode(regs) || !fixup_exception(regs); > and hook it onto the appropriate fault codes. However, this > really needs the opinion of someone more familiar with this > code. > > I do have an observation to make on the issue of fault > decoding: the list in fsr-2level.c may be "standard ARMv3 and > ARMv4 aborts" but they are quite wrong for ARMv7 which has: > > [ 0] - > [ 1] alignment fault > [ 2] debug event > [ 3] section access flag fault > [ 4] instruction cache maintainance fault (reported via data > abort) [ 5] section translation fault > [ 6] page access flag fault > [ 7] page translation fault > [ 8] bus error on access > [ 9] section domain fault > [10] - > [11] page domain fault > [12] bus error on section table walk > [13] section permission fault > [14] bus error on page table walk > [15] page permission fault > [16] (TLB conflict abort) > [17] - > [18] - > [19] - > [20] (lockdown abort) > [21] - > [22] async bus error (reported via data abort) > [23] - > [24] async parity/ECC error (reported via data abort) > [25] parity/ECC error on access > [26] (coprocessor abort) > [27] - > [28] parity/ECC error on section table walk > [29] - > [30] parity/ECC error on page table walk > [31] - > > Some entries are patched up near the bottom of fault.c but > many bogus messages remain, for example the "on linefetch" vs > "on non-linefetch" is misleading since no such thing can be > inferred from the fault status on v7. Also, the i-cache > maintenance fault handling looks wrong to me: it should fetch > the actual fault status from IFSR (even though the address > still comes from DFSR) and dispatch based on that. > > Async external aborts (async bus error and async parity/ECC > error) give you basically no info. DFAR will contain garbage > hence displaying it will confuse rather than enlighten, a > traceback is pointless since the instruction that caused the > access is long retired, likewise user_mode() doesn't matter > since a transition to kernel space may have happened after > the access that cause the abort. Basically they should be > treated more as an IRQ than as a fault (note they can also be > masked just like irqs). In case of a bus error, it may be > appropriate to just warn about it, or perhaps send a signal > to the current process, although in the latter case it should > have some means to distinguish it from a synchronous bus > error. > > At least on the cortex-a8, a parity/ECC error (whether async > or not) is to be regarded as absolutely fatal. Quoth the > TRM: "No recovery is possible. The abort handler must disable > the caches, communicate the fail directly with the external > system, request a reboot." > > Bit 10 no longer indicates an asynchronous (let alone > imprecise) fault. Apart from the debug events and async > aborts (and possibly some implementation-defined aborts), all > aborts listed are synchronous, and DFAR/IFAR is valid. > There's no technical obstruction to make these trappable via > the kernel exception handling mechanism. (Though at least in > case of parity/ECC errors one shouldn't.) Anyway, in Nokia Harmattan N9/N950 2.6.32 kernel is this patch: Maybe it is related? diff --git a/arch/arm/mm/fsr-2level.c b/arch/arm/mm/fsr-2level.c index 18ca74c..d530d55 100644 --- a/arch/arm/mm/fsr-2level.c +++ b/arch/arm/mm/fsr-2level.c @@ -7,7 +7,12 @@ static struct fsr_info fsr_info[] = { { do_bad, SIGBUS, BUS_ADRALN, "alignment exception" }, { do_bad, SIGKILL, 0, "terminal exception" }, { do_bad, SIGBUS, BUS_ADRALN, "alignment exception" }, +/* Do we need runtime check ? */ +#if __LINUX_ARM_ARCH__ < 6 { do_bad, SIGBUS, 0, "external abort on linefetch" }, +#else + { do_translation_fault, SIGSEGV, SEGV_MAPERR, "I-cache maintenance fault" }, +#endif { do_translation_fault, SIGSEGV, SEGV_MAPERR, "section translation fault" }, { do_bad, SIGBUS, 0, "external abort on linefetch" }, { do_page_fault, SIGSEGV, SEGV_MAPERR, "page translation fault" },