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
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 der
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 th
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
s
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
stepping into with this.
In any case, we were talki
On Wed, Jul 26, 2017 at 03:07:14PM -0500, Brijesh Singh wrote:
> Are you commenting on amount of code duplication ? If so, I can certainly
> improve
> and use the similar macro used into header file to generate the functions
> body.
So the argument about having CONFIG_AMD_MEM_ENCRYPT disabled do
From: Brijesh Singh
> Sent: 26 July 2017 21:07
...
> I am not sure if I understand your concern.
>
> Are you commenting on amount of code duplication ? If so, I can certainly
> improve
> and use the similar macro used into header file to generate the functions
> body.
If you are careful the rea
On 07/26/2017 02:26 PM, H. Peter Anvin wrote:
\
static inline void outs##bwl(int port, const void *addr, unsigned
long count) \
{
This will clash with a fix I did to add a "memory" clobber
for the traditional imp
,Eric Biederman ,Tejun Heo
,Paolo Bonzini ,Andrew Morton
,"Kirill A . Shutemov"
,Lu Baolu
From: h...@zytor.com
Message-ID:
On July 26, 2017 9:24:45 PM GMT+02:00, Brijesh Singh
wrote:
>
>Hi Arnd and David,
>
>On 07/26/2017 05:45 AM, Arnd Bergmann wrote:
>> On Tue, Jul 25, 2017 at 11:51 AM, D
Hi Arnd and David,
On 07/26/2017 05:45 AM, Arnd Bergmann wrote:
On Tue, Jul 25, 2017 at 11:51 AM, David Laight wrote:
From: Brijesh Singh
Sent: 24 July 2017 20:08
From: Tom Lendacky
Secure Encrypted Virtualization (SEV) does not support string I/O, so
unroll the string I/O operation into a
On Tue, Jul 25, 2017 at 11:51 AM, David Laight wrote:
> From: Brijesh Singh
>> Sent: 24 July 2017 20:08
>> From: Tom Lendacky
>>
>> Secure Encrypted Virtualization (SEV) does not support string I/O, so
>> unroll the string I/O operation into a loop operating on one element at
>> a time.
>>
>> Sig
From: Brijesh Singh
> Sent: 24 July 2017 20:08
> From: Tom Lendacky
>
> Secure Encrypted Virtualization (SEV) does not support string I/O, so
> unroll the string I/O operation into a loop operating on one element at
> a time.
>
> Signed-off-by: Tom Lendacky
> Signed-off-by: Brijesh Singh
> ---
From: Tom Lendacky
Secure Encrypted Virtualization (SEV) does not support string I/O, so
unroll the string I/O operation into a loop operating on one element at
a time.
Signed-off-by: Tom Lendacky
Signed-off-by: Brijesh Singh
---
arch/x86/include/asm/io.h | 26 ++
1 fi
14 matches
Mail list logo