From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753286AbbCBMTX (ORCPT ); Mon, 2 Mar 2015 07:19:23 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:56680 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751357AbbCBMTV (ORCPT ); Mon, 2 Mar 2015 07:19:21 -0500 Date: Mon, 2 Mar 2015 13:19:19 +0100 From: Pavel Machek To: "Bryan O'Donoghue" Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, dvhart@infradead.org, andy.shevchenko@gmail.com, boon.leong.ong@intel.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/1] x86: Add Isolated Memory Regions for Quark X1000 Message-ID: <20150302121919.GD27317@amd> References: <1422281727-32610-1-git-send-email-pure.logic@nexus-software.ie> <1422281727-32610-2-git-send-email-pure.logic@nexus-software.ie> <20150223221847.GA5285@amd> <54ECFDCF.8040902@nexus-software.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54ECFDCF.8040902@nexus-software.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 2015-02-24 22:40:15, Bryan O'Donoghue wrote: > On 23/02/15 22:18, Pavel Machek wrote: > >On Mon 2015-01-26 14:15:27, Bryan O'Donoghue wrote: > > > > >Do the applications normally need to manipulate IMRs? > > > Applications could in theory manipulate IMRs - you might want to place an > IMR around an EFI capsule in memory for example - before calling a capsule > update. > > This code will place an IMR around the kernel .text - .rodata which ensures > that no unwarranted DMA access can rewrite write-only kernel addresses - > something the MMU would not fault on - on non-IMR enabled processors. > > >Would it be > >possible to do all IMR manipulations in the bootloader? > > > > Possible yes - in practical terms for Galileo or the SMARC+Quark from > Kontron for example - you'd be forcing a bootloader change - which most > users will not pick up. > > > Considering IMRs can reset the system if they aren't sanitized, it's good > practice for the kernel to go and make sure that every unlocked IMR is > torn-down and reset. Ok, makes sense. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html