>>> On 14.02.18 at 17:23, wrote:
> The current XPTI implementation isolates the directmap (and therefore a lot
> of
> guest data), but a large quantity of CPU0's state (including its stack)
> remains visible.
>
> Furthermore, an attacker able to read .text is in a
The current XPTI implementation isolates the directmap (and therefore a lot of
guest data), but a large quantity of CPU0's state (including its stack)
remains visible.
Furthermore, an attacker able to read .text is in a vastly superior position
to normal when it comes to fingerprinting Xen for
On 14/02/18 12:27, Juergen Gross wrote:
> On 14/02/18 13:19, Andrew Cooper wrote:
>> On 14/02/18 12:15, Juergen Gross wrote:
>>> On 14/02/18 13:03, Juergen Gross wrote:
On 14/02/18 12:48, Andrew Cooper wrote:
> On 14/02/18 07:54, Juergen Gross wrote:
>> On 13/02/18 20:45, Andrew
On 14/02/18 09:14, Jan Beulich wrote:
On 13.02.18 at 20:45, wrote:
>> RFC, because I don't think the stubs handling is particularly sensible.
>>
>> We allocate 4k of virtual address space per CPU, but squash loads of CPUs
>> together onto a single MFN. The stubs
On 14/02/18 13:19, Andrew Cooper wrote:
> On 14/02/18 12:15, Juergen Gross wrote:
>> On 14/02/18 13:03, Juergen Gross wrote:
>>> On 14/02/18 12:48, Andrew Cooper wrote:
On 14/02/18 07:54, Juergen Gross wrote:
> On 13/02/18 20:45, Andrew Cooper wrote:
>> The current XPTI implementation
On 14/02/18 12:15, Juergen Gross wrote:
> On 14/02/18 13:03, Juergen Gross wrote:
>> On 14/02/18 12:48, Andrew Cooper wrote:
>>> On 14/02/18 07:54, Juergen Gross wrote:
On 13/02/18 20:45, Andrew Cooper wrote:
> The current XPTI implementation isolates the directmap (and therefore a
>
On 14/02/18 13:03, Juergen Gross wrote:
> On 14/02/18 12:48, Andrew Cooper wrote:
>> On 14/02/18 07:54, Juergen Gross wrote:
>>> On 13/02/18 20:45, Andrew Cooper wrote:
The current XPTI implementation isolates the directmap (and therefore a
lot of
guest data), but a large quantity
On 14/02/18 12:48, Andrew Cooper wrote:
> On 14/02/18 07:54, Juergen Gross wrote:
>> On 13/02/18 20:45, Andrew Cooper wrote:
>>> The current XPTI implementation isolates the directmap (and therefore a lot
>>> of
>>> guest data), but a large quantity of CPU0's state (including its stack)
>>>
On 14/02/18 07:54, Juergen Gross wrote:
> On 13/02/18 20:45, Andrew Cooper wrote:
>> The current XPTI implementation isolates the directmap (and therefore a lot
>> of
>> guest data), but a large quantity of CPU0's state (including its stack)
>> remains visible.
>>
>> Furthermore, an attacker able
>>> On 13.02.18 at 20:45, wrote:
> RFC, because I don't think the stubs handling is particularly sensible.
>
> We allocate 4k of virtual address space per CPU, but squash loads of CPUs
> together onto a single MFN. The stubs ought to be isolated as well (as they
>
On 13/02/18 20:45, Andrew Cooper wrote:
> The current XPTI implementation isolates the directmap (and therefore a lot of
> guest data), but a large quantity of CPU0's state (including its stack)
> remains visible.
>
> Furthermore, an attacker able to read .text is in a vastly superior position
>
The current XPTI implementation isolates the directmap (and therefore a lot of
guest data), but a large quantity of CPU0's state (including its stack)
remains visible.
Furthermore, an attacker able to read .text is in a vastly superior position
to normal when it comes to fingerprinting Xen for
12 matches
Mail list logo