From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH -v2 0/4] EFI 1:1 mapping Date: Thu, 20 Jun 2013 11:13:21 +0200 Message-ID: <20130620091321.GB6811@gmail.com> References: <1371491416-11037-1-git-send-email-bp@alien8.de> <20130619125243.GD11209@gmail.com> <20130619130225.GA28311@pd.tnic> <20130619130434.GB24957@gmail.com> <20130619160804.GB27832@srcf.ucam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20130619160804.GB27832-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Matthew Garrett Cc: Borislav Petkov , Linux EFI , Matt Fleming , X86 ML , LKML , Borislav Petkov List-Id: linux-efi@vger.kernel.org * Matthew Garrett wrote: > On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote: > > * Borislav Petkov wrote: > > > And yet there are the Macs which reportedly cannot stomach this. > > > > Do we know why? > > I got lost in a maze of pointer arithmetic. There seems to be an > assumption that nvram writes should be forbidden if in runtime mode but > with pointers still below the phys/virt split, which obviously makes no > sense but hey. > > But, as always, the only reliable thing to do here is to behave as much > like Windows as possible. [...] Amen ... > [...] Which means performing the 1:1 mapping but maintaining the high > mapping, and passing the high values via SetVirtualAddressMap. Cool - and supposedly this will work in a Mac environment as well? Would be very nice to avoid fundamentally fragile system specific quirks for something as fundamental as the EFI runtime memory mapping model ... Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965106Ab3FTJN3 (ORCPT ); Thu, 20 Jun 2013 05:13:29 -0400 Received: from mail-ee0-f43.google.com ([74.125.83.43]:34296 "EHLO mail-ee0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755966Ab3FTJNZ (ORCPT ); Thu, 20 Jun 2013 05:13:25 -0400 Date: Thu, 20 Jun 2013 11:13:21 +0200 From: Ingo Molnar To: Matthew Garrett Cc: Borislav Petkov , Linux EFI , Matt Fleming , X86 ML , LKML , Borislav Petkov Subject: Re: [PATCH -v2 0/4] EFI 1:1 mapping Message-ID: <20130620091321.GB6811@gmail.com> References: <1371491416-11037-1-git-send-email-bp@alien8.de> <20130619125243.GD11209@gmail.com> <20130619130225.GA28311@pd.tnic> <20130619130434.GB24957@gmail.com> <20130619160804.GB27832@srcf.ucam.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130619160804.GB27832@srcf.ucam.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Matthew Garrett wrote: > On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote: > > * Borislav Petkov wrote: > > > And yet there are the Macs which reportedly cannot stomach this. > > > > Do we know why? > > I got lost in a maze of pointer arithmetic. There seems to be an > assumption that nvram writes should be forbidden if in runtime mode but > with pointers still below the phys/virt split, which obviously makes no > sense but hey. > > But, as always, the only reliable thing to do here is to behave as much > like Windows as possible. [...] Amen ... > [...] Which means performing the 1:1 mapping but maintaining the high > mapping, and passing the high values via SetVirtualAddressMap. Cool - and supposedly this will work in a Mac environment as well? Would be very nice to avoid fundamentally fragile system specific quirks for something as fundamental as the EFI runtime memory mapping model ... Thanks, Ingo