On Tue, 11 Nov, at 10:59:07PM, Mathias Krause wrote:
>
> Matt, do you mind to take this patch (and only this patch) through the EFI
> tree?
> There were objections to patch 2 and 3 of this series from the x86
> folks so I won't re-do those.
Applied with Borislav's ACK, thanks Mathias.
--
Matt
On 29 October 2014 15:22, Matt Fleming wrote:
> On Tue, 28 Oct, at 08:48:23PM, Mathias Krause wrote:
>> On 28 October 2014 19:57, Borislav Petkov wrote:
>> > [...]
>> >
>> > Ok, thanks for refreshing this for me, your patch is good, so
>> >
>> > Acked-by: Borislav Petkov
>>
>> Thanks. But as
On 29 October 2014 15:22, Matt Fleming m...@console-pimps.org wrote:
On Tue, 28 Oct, at 08:48:23PM, Mathias Krause wrote:
On 28 October 2014 19:57, Borislav Petkov b...@alien8.de wrote:
[...]
Ok, thanks for refreshing this for me, your patch is good, so
Acked-by: Borislav Petkov
On Tue, 11 Nov, at 10:59:07PM, Mathias Krause wrote:
Matt, do you mind to take this patch (and only this patch) through the EFI
tree?
There were objections to patch 2 and 3 of this series from the x86
folks so I won't re-do those.
Applied with Borislav's ACK, thanks Mathias.
--
Matt
On 29 October 2014 15:22, Matt Fleming wrote:
> On Tue, 28 Oct, at 08:48:23PM, Mathias Krause wrote:
>> On 28 October 2014 19:57, Borislav Petkov wrote:
>> > [...]
>> >
>> > Ok, thanks for refreshing this for me, your patch is good, so
>> >
>> > Acked-by: Borislav Petkov
>>
>> Thanks. But as
On 29 October 2014 15:20, Matt Fleming wrote:
> On Tue, 28 Oct, at 10:14:25PM, Mathias Krause wrote:
>>
>> Mapping the kernel into the EFI page table may help ;) Then the
>> kernel's #PF handler would be present and able to print a register
>> dump, at least.
>
> The kernel is already mapped into
On Tue, 28 Oct, at 08:48:23PM, Mathias Krause wrote:
> On 28 October 2014 19:57, Borislav Petkov wrote:
> > [...]
> >
> > Ok, thanks for refreshing this for me, your patch is good, so
> >
> > Acked-by: Borislav Petkov
>
> Thanks. But as you said, the EFI mappings shouldn't be in the kernel's
>
On Tue, 28 Oct, at 10:14:25PM, Mathias Krause wrote:
>
> Mapping the kernel into the EFI page table may help ;) Then the
> kernel's #PF handler would be present and able to print a register
> dump, at least.
The kernel is already mapped into the EFI page table.
> So, assuming you're not
On 28 October 2014 23:07, Borislav Petkov wrote:
> On Tue, Oct 28, 2014 at 10:49:36PM +0100, Mathias Krause wrote:
>> Sync only data or kernel code, too?
>
> Data only should be enough.
No, not really. This is why:
1/ When setting up the virtual mapping via a call to the
SetVirtualAddressMap
On 28 October 2014 23:07, Borislav Petkov b...@alien8.de wrote:
On Tue, Oct 28, 2014 at 10:49:36PM +0100, Mathias Krause wrote:
Sync only data or kernel code, too?
Data only should be enough.
No, not really. This is why:
1/ When setting up the virtual mapping via a call to the
On Tue, 28 Oct, at 10:14:25PM, Mathias Krause wrote:
Mapping the kernel into the EFI page table may help ;) Then the
kernel's #PF handler would be present and able to print a register
dump, at least.
The kernel is already mapped into the EFI page table.
So, assuming you're not mapping the
On Tue, 28 Oct, at 08:48:23PM, Mathias Krause wrote:
On 28 October 2014 19:57, Borislav Petkov b...@alien8.de wrote:
[...]
Ok, thanks for refreshing this for me, your patch is good, so
Acked-by: Borislav Petkov b...@suse.de
Thanks. But as you said, the EFI mappings shouldn't be in
On 29 October 2014 15:20, Matt Fleming m...@console-pimps.org wrote:
On Tue, 28 Oct, at 10:14:25PM, Mathias Krause wrote:
Mapping the kernel into the EFI page table may help ;) Then the
kernel's #PF handler would be present and able to print a register
dump, at least.
The kernel is already
On 29 October 2014 15:22, Matt Fleming m...@console-pimps.org wrote:
On Tue, 28 Oct, at 08:48:23PM, Mathias Krause wrote:
On 28 October 2014 19:57, Borislav Petkov b...@alien8.de wrote:
[...]
Ok, thanks for refreshing this for me, your patch is good, so
Acked-by: Borislav Petkov
On Tue, Oct 28, 2014 at 10:49:36PM +0100, Mathias Krause wrote:
> Sync only data or kernel code, too?
Data only should be enough.
> Really, I'd just map the EFI RT service virtual mappings "somewhere"
> but at pgd[511] and have pgd[511] initially set up as
> init_level4_pgt[511]. Then, thing
On 28 October 2014 22:26, Borislav Petkov wrote:
> On Tue, Oct 28, 2014 at 10:14:25PM +0100, Mathias Krause wrote:
>> Oh, well. Have fun with that! I would take the "map kernel into EFI
>> page table" route instead. ;)
>
> Actually, I want to try to keep them completely separate and sync only
>
On Tue, Oct 28, 2014 at 10:14:25PM +0100, Mathias Krause wrote:
> Oh, well. Have fun with that! I would take the "map kernel into EFI
> page table" route instead. ;)
Actually, I want to try to keep them completely separate and sync only
before an EFI RT call for function arguments. And then
On 28 October 2014 21:13, Borislav Petkov wrote:
> On Tue, Oct 28, 2014 at 08:48:23PM +0100, Mathias Krause wrote:
>> I tried so too but failed early as well. I tried putting the EFI
>> virtual mappings not in trampoline_pgd[511] but trampoline_pgd[510].
>> However, that didn't work out. I got
On Tue, Oct 28, 2014 at 08:48:23PM +0100, Mathias Krause wrote:
> I tried so too but failed early as well. I tried putting the EFI
> virtual mappings not in trampoline_pgd[511] but trampoline_pgd[510].
> However, that didn't work out. I got page faults when trying to invoke
> EFI functions, as,
On 28 October 2014 19:57, Borislav Petkov wrote:
> [...]
>
> Ok, thanks for refreshing this for me, your patch is good, so
>
> Acked-by: Borislav Petkov
Thanks. But as you said, the EFI mappings shouldn't be in the kernel's
page table in the first place, so I'd rather see a patch doing that
On Sun, Oct 12, 2014 at 02:55:15PM +0200, Mathias Krause wrote:
...
> There's a lengthy comment in arch/x86/platform/efi/efi.c that mentions
> the duplication of pgd entries -- and therefore whole hierarchies --
> between trampoline_pgd and init_level4_pgt. And, ironically, that
> comment is
On Sun, Oct 12, 2014 at 02:55:15PM +0200, Mathias Krause wrote:
...
There's a lengthy comment in arch/x86/platform/efi/efi.c that mentions
the duplication of pgd entries -- and therefore whole hierarchies --
between trampoline_pgd and init_level4_pgt. And, ironically, that
comment is yours
On 28 October 2014 19:57, Borislav Petkov b...@alien8.de wrote:
[...]
Ok, thanks for refreshing this for me, your patch is good, so
Acked-by: Borislav Petkov b...@suse.de
Thanks. But as you said, the EFI mappings shouldn't be in the kernel's
page table in the first place, so I'd rather see a
On Tue, Oct 28, 2014 at 08:48:23PM +0100, Mathias Krause wrote:
I tried so too but failed early as well. I tried putting the EFI
virtual mappings not in trampoline_pgd[511] but trampoline_pgd[510].
However, that didn't work out. I got page faults when trying to invoke
EFI functions, as,
On 28 October 2014 21:13, Borislav Petkov b...@alien8.de wrote:
On Tue, Oct 28, 2014 at 08:48:23PM +0100, Mathias Krause wrote:
I tried so too but failed early as well. I tried putting the EFI
virtual mappings not in trampoline_pgd[511] but trampoline_pgd[510].
However, that didn't work out. I
On Tue, Oct 28, 2014 at 10:14:25PM +0100, Mathias Krause wrote:
Oh, well. Have fun with that! I would take the map kernel into EFI
page table route instead. ;)
Actually, I want to try to keep them completely separate and sync only
before an EFI RT call for function arguments. And then remove
On 28 October 2014 22:26, Borislav Petkov b...@alien8.de wrote:
On Tue, Oct 28, 2014 at 10:14:25PM +0100, Mathias Krause wrote:
Oh, well. Have fun with that! I would take the map kernel into EFI
page table route instead. ;)
Actually, I want to try to keep them completely separate and sync
On Tue, Oct 28, 2014 at 10:49:36PM +0100, Mathias Krause wrote:
Sync only data or kernel code, too?
Data only should be enough.
Really, I'd just map the EFI RT service virtual mappings somewhere
but at pgd[511] and have pgd[511] initially set up as
init_level4_pgt[511]. Then, thing should
On Thu, Oct 09, 2014 at 12:26:19AM +0200, Borislav Petkov wrote:
> On Wed, Oct 08, 2014 at 11:58:20PM +0200, Mathias Krause wrote:
> > Well, that is only partly correct. The call chain in efi_map_regions()
> > [ -> efi_map_region() -> __map_region() -> kernel_map_pages_in_pgd()
> > ->
On Thu, Oct 09, 2014 at 12:26:19AM +0200, Borislav Petkov wrote:
On Wed, Oct 08, 2014 at 11:58:20PM +0200, Mathias Krause wrote:
Well, that is only partly correct. The call chain in efi_map_regions()
[ - efi_map_region() - __map_region() - kernel_map_pages_in_pgd()
- ...magic... ] does not
On Wed, Oct 08, 2014 at 11:58:20PM +0200, Mathias Krause wrote:
> Well, that is only partly correct. The call chain in efi_map_regions()
> [ -> efi_map_region() -> __map_region() -> kernel_map_pages_in_pgd()
> -> ..."magic"... ] does not only map the EFI regions in
> trampoline_pgd, but also in
On 8 October 2014 17:17, Borislav Petkov wrote:
> On Tue, Oct 07, 2014 at 07:07:48PM +0200, Mathias Krause wrote:
>> What you can see here are actually the EFI runtime service mappings, not
>> the ESP fix area. Check the addresses and compare them. You should find
>> similarities ;) And, in fact,
On Tue, Oct 07, 2014 at 07:07:48PM +0200, Mathias Krause wrote:
> What you can see here are actually the EFI runtime service mappings, not
> the ESP fix area. Check the addresses and compare them. You should find
> similarities ;) And, in fact, the EFI mappings are incomplete in the
> second dump,
On Tue, Oct 07, 2014 at 07:07:48PM +0200, Mathias Krause wrote:
What you can see here are actually the EFI runtime service mappings, not
the ESP fix area. Check the addresses and compare them. You should find
similarities ;) And, in fact, the EFI mappings are incomplete in the
second dump,
On 8 October 2014 17:17, Borislav Petkov b...@alien8.de wrote:
On Tue, Oct 07, 2014 at 07:07:48PM +0200, Mathias Krause wrote:
What you can see here are actually the EFI runtime service mappings, not
the ESP fix area. Check the addresses and compare them. You should find
similarities ;) And,
On Wed, Oct 08, 2014 at 11:58:20PM +0200, Mathias Krause wrote:
Well, that is only partly correct. The call chain in efi_map_regions()
[ - efi_map_region() - __map_region() - kernel_map_pages_in_pgd()
- ...magic... ] does not only map the EFI regions in
trampoline_pgd, but also in kernel page
On Tue, Oct 07, 2014 at 05:01:32PM +0200, Borislav Petkov wrote:
> On Fri, Oct 03, 2014 at 02:47:07PM +0100, Matt Fleming wrote:
> > Looks OK to me. Borislav?
>
> It needs more work AFAICT because with it, espfix area gets cut off
> prematurely:
>
I don't think so. See below...
> ...
> [
On Fri, Oct 03, 2014 at 02:47:07PM +0100, Matt Fleming wrote:
> Looks OK to me. Borislav?
It needs more work AFAICT because with it, espfix area gets cut off
prematurely:
...
[0.134611] ---[ Vmemmap ]---
[0.135003] 0xea00-0xea000200 32M RW
PSE
On Fri, Oct 03, 2014 at 02:47:07PM +0100, Matt Fleming wrote:
Looks OK to me. Borislav?
It needs more work AFAICT because with it, espfix area gets cut off
prematurely:
...
[0.134611] ---[ Vmemmap ]---
[0.135003] 0xea00-0xea000200 32M RW
PSE GLB
On Tue, Oct 07, 2014 at 05:01:32PM +0200, Borislav Petkov wrote:
On Fri, Oct 03, 2014 at 02:47:07PM +0100, Matt Fleming wrote:
Looks OK to me. Borislav?
It needs more work AFAICT because with it, espfix area gets cut off
prematurely:
I don't think so. See below...
...
[0.134611]
On Sun, 21 Sep, at 05:26:54PM, Mathias Krause wrote:
> In commit 3891a04aafd6 ("x86-64, espfix: Don't leak bits 31:16 of %esp
> returning..") the "ESPFix Area" was added to the page table dump special
> sections. That area, though, has a limited amount of entries printed.
>
> The EFI runtime
On Sun, 21 Sep, at 05:26:54PM, Mathias Krause wrote:
In commit 3891a04aafd6 (x86-64, espfix: Don't leak bits 31:16 of %esp
returning..) the ESPFix Area was added to the page table dump special
sections. That area, though, has a limited amount of entries printed.
The EFI runtime services are,
In commit 3891a04aafd6 ("x86-64, espfix: Don't leak bits 31:16 of %esp
returning..") the "ESPFix Area" was added to the page table dump special
sections. That area, though, has a limited amount of entries printed.
The EFI runtime services are, unfortunately, located in-between the
espfix area and
In commit 3891a04aafd6 (x86-64, espfix: Don't leak bits 31:16 of %esp
returning..) the ESPFix Area was added to the page table dump special
sections. That area, though, has a limited amount of entries printed.
The EFI runtime services are, unfortunately, located in-between the
espfix area and the
44 matches
Mail list logo
