On Thu, May 30, 2019 at 01:45:16PM +0800, Dianzhang Chen wrote:
>
> Though syscall `getrlimit` , it seems not works after
> check_prlimit_permission.
>
> And the speculation windows are large, as said[1]:
> >> Can the speculation proceed past the task_lock()? Or is the policy to
> >> ignore
Though syscall `getrlimit` , it seems not works after check_prlimit_permission.
And the speculation windows are large, as said[1]:
>> Can the speculation proceed past the task_lock()? Or is the policy to
>> ignore such happy happenstances even if they are available?
>
> Locks are not in the way
On Wed, May 29, 2019 at 10:39:52AM +0800, Dianzhang Chen wrote:
> Hi,
>
> Although when detect it is misprediction and drop the execution, but
> it can not drop all the effects of speculative execution, like the
> cache state. During the speculative execution, the:
>
>
> rlim =
Hi,
Although when detect it is misprediction and drop the execution, but
it can not drop all the effects of speculative execution, like the
cache state. During the speculative execution, the:
rlim = tsk->signal->rlim + resource;// use resource as index
...
*old_rlim = *rlim;
On Tue, May 28, 2019 at 10:37:10AM +0800, Dianzhang Chen wrote:
> Hi,
> Because when i reply your email，i always get 'Message rejected' from
> gmail(get this rejection from all the recipients). I still don't know
> how to deal with it, so i reply your email here:
Hi! This is weird. Next time
On Mon, May 27, 2019 at 03:23:08PM +0800, Dianzhang Chen wrote:
> The `resource` in do_prlimit() is controlled by userspace via syscall:
> setrlimit(defined in kernel/sys.c), hence leading to a potential exploitation
> of the Spectre variant 1 vulnerability.
> The relevant code in do_prlimit()
The `resource` in do_prlimit() is controlled by userspace via syscall:
setrlimit(defined in kernel/sys.c), hence leading to a potential exploitation
of the Spectre variant 1 vulnerability.
The relevant code in do_prlimit() is as below：
if (resource >= RLIM_NLIMITS)
return -EINVAL;
...
7 matches
Mail list logo
