On Thu, Jun 06, 2013 at 12:38:10PM -0700, H. Peter Anvin wrote:
> On 06/06/2013 12:36 PM, Borislav Petkov wrote:
> > On Thu, Jun 06, 2013 at 12:28:20PM -0700, H. Peter Anvin wrote:
> >> Or we could materialize mappings for this specific PGD. However,
> >> adding a read of %cr3 in __do_page_fault so
On 06/06/2013 12:36 PM, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 12:28:20PM -0700, H. Peter Anvin wrote:
>> Or we could materialize mappings for this specific PGD. However,
>> adding a read of %cr3 in __do_page_fault sounds expensive.
>
> Yes, I think we want to make sure all mappings are
On Thu, Jun 06, 2013 at 12:28:20PM -0700, H. Peter Anvin wrote:
> Or we could materialize mappings for this specific PGD. However,
> adding a read of %cr3 in __do_page_fault sounds expensive.
Yes, I think we want to make sure all mappings are there when we do an
EFI runtime call so that we never #
On 06/06/2013 08:58 AM, Borislav Petkov wrote:
> --
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 654be4ae3047..7a6129afdff1 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1021,6 +1021,9 @@ __do_page_fault(struct pt_regs *regs, unsigned long
> error_code)
>
On Thu, Jun 06, 2013 at 03:29:08PM +0200, Borislav Petkov wrote:
> On Thu, Jun 06, 2013 at 02:14:39PM +0100, Matt Fleming wrote:
> > This patch makes my TunnelMountain machine spin in handle_pte_fault()
> > when triggering one of the "firmware makes references to physical
> > addresses" code paths.
On Thu, Jun 06, 2013 at 02:14:39PM +0100, Matt Fleming wrote:
> This patch makes my TunnelMountain machine spin in handle_pte_fault()
> when triggering one of the "firmware makes references to physical
> addresses" code paths.
>
> I'll try and dig into this tomorrow to figure out what's going on.
On Sun, 02 Jun, at 02:56:10PM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Due to the braindead design of EFI, we cannot map runtime services more
> than once for the duration of a booted system. Thus, if we want to use
> EFI runtime services in a kexec'ed kernel, maybe the only possible a
