On 01/25/2018 12:20 AM, David Woodhouse wrote:
> On Wed, 2018-01-24 at 16:36 -0800, Tim Chen wrote:
>> It is possible that the last uesr mm that we recorded for a cpu was
>> released, and a new mm with identical address was allocated when we
>> check it again. We could skip IBPB flush here for
On 01/25/2018 12:20 AM, David Woodhouse wrote:
> On Wed, 2018-01-24 at 16:36 -0800, Tim Chen wrote:
>> It is possible that the last uesr mm that we recorded for a cpu was
>> released, and a new mm with identical address was allocated when we
>> check it again. We could skip IBPB flush here for
On Wed, 2018-01-24 at 16:36 -0800, Tim Chen wrote:
> It is possible that the last uesr mm that we recorded for a cpu was
> released, and a new mm with identical address was allocated when we
> check it again. We could skip IBPB flush here for the process with
> the new mm.
>
> It is a difficult
On Wed, 2018-01-24 at 16:36 -0800, Tim Chen wrote:
> It is possible that the last uesr mm that we recorded for a cpu was
> released, and a new mm with identical address was allocated when we
> check it again. We could skip IBPB flush here for the process with
> the new mm.
>
> It is a difficult
It is possible that the last uesr mm that we recorded for a cpu was
released, and a new mm with identical address was allocated when we
check it again. We could skip IBPB flush here for the process with
the new mm.
It is a difficult to exploit case as we have to exit() a process on a
cpu, free
It is possible that the last uesr mm that we recorded for a cpu was
released, and a new mm with identical address was allocated when we
check it again. We could skip IBPB flush here for the process with
the new mm.
It is a difficult to exploit case as we have to exit() a process on a
cpu, free
6 matches
Mail list logo
