On Fri, Aug 24, 2018 at 01:47:10PM -0500, Brijesh Singh wrote:
> I am more inclined towards creating a new section with PMD aligned and
> sized. This section will contains the decrypted data. In early
> boot code we will update the mapping with C=0. If caller wants to create
> a shared variable the
On 08/24/2018 11:24 AM, Sean Christopherson wrote:
On Fri, Aug 24, 2018 at 10:41:27AM -0500, Brijesh Singh wrote:
On 08/23/2018 11:16 AM, Paolo Bonzini wrote:
On 23/08/2018 17:29, Sean Christopherson wrote:
On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
On 22/08/2018 22:1
On 08/24/2018 10:50 AM, Paolo Bonzini wrote:
On 24/08/2018 17:41, Brijesh Singh wrote:
Wouldn't that result in exposing/leaking whatever code/data happened
to reside on the same 2M page (or corrupting it if the entire page
isn't decrypted)? Or are you suggesting that we'd also leave the
enc
On Fri, Aug 24, 2018 at 10:41:27AM -0500, Brijesh Singh wrote:
>
>
> On 08/23/2018 11:16 AM, Paolo Bonzini wrote:
> >On 23/08/2018 17:29, Sean Christopherson wrote:
> >>On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
> >>>On 22/08/2018 22:11, Brijesh Singh wrote:
>
> Yes,
On 24/08/2018 17:41, Brijesh Singh wrote:
>>>
>>> Wouldn't that result in exposing/leaking whatever code/data happened
>>> to reside on the same 2M page (or corrupting it if the entire page
>>> isn't decrypted)? Or are you suggesting that we'd also leave the
>>> encrypted mapping intact?
>>
>> Yes
On 08/23/2018 11:16 AM, Paolo Bonzini wrote:
On 23/08/2018 17:29, Sean Christopherson wrote:
On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
On 22/08/2018 22:11, Brijesh Singh wrote:
Yes, this is one of approach I have in mind. It will avoid splitting
the larger pages; I am
On 23/08/2018 17:29, Sean Christopherson wrote:
> On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
>> On 22/08/2018 22:11, Brijesh Singh wrote:
>>>
>>> Yes, this is one of approach I have in mind. It will avoid splitting
>>> the larger pages; I am thinking that early in boot code we c
On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
> On 22/08/2018 22:11, Brijesh Singh wrote:
> >
> > Yes, this is one of approach I have in mind. It will avoid splitting
> > the larger pages; I am thinking that early in boot code we can lookup
> > for this special section and decrypt
On 22/08/2018 22:11, Brijesh Singh wrote:
>
> Yes, this is one of approach I have in mind. It will avoid splitting
> the larger pages; I am thinking that early in boot code we can lookup
> for this special section and decrypt it in-place and probably maps with
> C=0. Only downside, it will increas
Hi Sean,
On 08/22/2018 10:00 AM, Sean Christopherson wrote:
On Wed, Aug 22, 2018 at 10:14:17AM +0200, Borislav Petkov wrote:
Dropping Pavel as it bounces.
On Tue, Aug 21, 2018 at 11:07:38AM -0500, Brijesh Singh wrote:
The tsc_early_init() is called before setup_arch() -> init_mem_mapping.
On Wed, Aug 22, 2018 at 10:14:17AM +0200, Borislav Petkov wrote:
> Dropping Pavel as it bounces.
>
> On Tue, Aug 21, 2018 at 11:07:38AM -0500, Brijesh Singh wrote:
> > The tsc_early_init() is called before setup_arch() -> init_mem_mapping.
>
> Ok, I see it, thanks for explaining.
>
> So back to
Dropping Pavel as it bounces.
On Tue, Aug 21, 2018 at 11:07:38AM -0500, Brijesh Singh wrote:
> The tsc_early_init() is called before setup_arch() -> init_mem_mapping.
Ok, I see it, thanks for explaining.
So back to your original ideas - I'm wondering whether we should define
a chunk of memory wh
On 08/21/2018 10:19 AM, Borislav Petkov wrote:
On Tue, Aug 21, 2018 at 09:37:56AM -0500, Brijesh Singh wrote:
Those variables are accessed immediately by the tsc calibration code
path hence we will not able to delay the allocation.
If you mean, check_tsc_sync_source/_target(), those are cal
On Tue, Aug 21, 2018 at 09:37:56AM -0500, Brijesh Singh wrote:
> Those variables are accessed immediately by the tsc calibration code
> path hence we will not able to delay the allocation.
If you mean, check_tsc_sync_source/_target(), those are called pretty
late, AFAICT.
And I see a setup_arch()
Hi Boris,
On 08/21/2018 03:39 AM, Borislav Petkov wrote:
On Mon, Aug 20, 2018 at 05:11:53PM -0500, Brijesh Singh wrote:
Hi All,
The following commit
"
x86/kvmclock: Remove memblock dependency
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=368a540e0232ad446931f
On Mon, Aug 20, 2018 at 05:11:53PM -0500, Brijesh Singh wrote:
> Hi All,
>
> The following commit
>
> "
> x86/kvmclock: Remove memblock dependency
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=368a540e0232ad446931f5a4e8a5e06f69f21343
>
> "
> broke the SEV sup
Hi All,
The following commit
"
x86/kvmclock: Remove memblock dependency
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=368a540e0232ad446931f5a4e8a5e06f69f21343
"
broke the SEV support in 4.18.
Since the guest physical address holding the wall_clock and
vcpu_time
17 matches
Mail list logo