lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 30 May 2019 13:45:16 +0800 From: Dianzhang Chen <dianzhangchen0@...il.com> To: Cyrill Gorcunov <gorcunov@...il.com> Cc: LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] kernel/sys.c: fix possible spectre-v1 in do_prlimit() 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 of speculation. Speculation has almost no limits > except serializing instructions. At least they respect the magic AND > limitation in array_index_nospec(). [1] https://do-db2.lkml.org/lkml/2018/5/15/1056 On Wed, May 29, 2019 at 8:18 PM Cyrill Gorcunov <gorcunov@...il.com> wrote: > > 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 = tsk->signal->rlim + resource; // use resource as index > > > > ... > > > > *old_rlim = *rlim; > > > > > > may read some secret data into cache. > > > > and then the attacker can use side-channel attack to find out what the > > secret data is. > > This code works after check_prlimit_permission call, which means you already > should have a permission granted. And you implies that misprediction gonna > be that deep which involves a number of calls/read/writes/jumps/locks-rb-wb-flushes > and a bunch or other instructions, moreover all conditions are "mispredicted". > This is very bold and actually unproved claim! > > Note that I pointed the patch is fine in cleanup context but seriously I > don't see how this all can be exploitable in sense of spectre.
Powered by blists - more mailing lists