On 15 September 2017 at 11:53, Stephen Boyd wrote:
> On 09/14, Ard Biesheuvel wrote:
>> The UEFI memory map is a bit vague about how to interpret the
>> EFI_MEMORY_XP attribute when it is combined with EFI_MEMORY_RP and/or
>> EFI_MEMORY_WP, which have retroactively been
On 09/14, Ard Biesheuvel wrote:
> The UEFI memory map is a bit vague about how to interpret the
> EFI_MEMORY_XP attribute when it is combined with EFI_MEMORY_RP and/or
> EFI_MEMORY_WP, which have retroactively been redefined as cacheability
> attributes rather than permission attributes.
>
> So
On 09/15/2017 11:22 AM, Borislav Petkov wrote:
mem_encrypt_init() where everything should be set up already.
Yep, its safe to derefs the static key in mem_encrypt_init(). I've
tried the approach and it seems to be work fine. I will include the
required changes in next rev. thanks
--
To
On Fri, Sep 15, 2017 at 09:48:53AM -0500, Brijesh Singh wrote:
> I see the similar issue with non SEV guest with my simple patch below.
> Guest will reboot as soon as it tries to enable the key.
Can't do it there as the pagetable is not setup yet and you're probably
getting a #PF on any of the
On 09/15/2017 09:40 AM, Borislav Petkov wrote:
I need to figure out the include hell first.
I am working with slightly newer patch sets -- in that patch Tom has
moved the sev_active() definition in arch/x86/mm/mem_encrypt.c and I
have no issue using your recommended (since I no longer need
On Fri, Sep 15, 2017 at 09:13:00AM -0500, Brijesh Singh wrote:
> thanks for the suggestion Boris, it will make patch much simpler.
> I will try this out.
It won't build - this was supposed to show the general idea.
I need to figure out the include hell first.
--
Regards/Gruss,
Boris.
SUSE
On 09/15/2017 07:24 AM, Borislav Petkov wrote:
On Tue, Aug 22, 2017 at 06:52:48PM +0200, Borislav Petkov wrote:
As always, the devil is in the detail.
Ok, actually we can make this much simpler by using a static key. A
conceptual patch below - I only need to fix that crazy include hell I'm