Thread (140 messages) 140 messages, 21 authors, 2018-12-04

Re: [PATCH 10/17] prmem: documentation

From: Andy Lutomirski <luto@kernel.org>
Date: 2018-11-13 18:37:27
Also in: linux-doc, linux-integrity, lkml

On Tue, Nov 13, 2018 at 10:33 AM Igor Stoppa [off-list ref] wrote:
I forgot one sentence :-(

On 13/11/2018 20:31, Igor Stoppa wrote:
quoted
On 13/11/2018 19:47, Andy Lutomirski wrote:
quoted
For general rare-writish stuff, I don't think we want IRQs running
with them mapped anywhere for write.  For AVC and IMA, I'm less sure.
Why would these be less sensitive?

But I see a big difference between my initial implementation and this one.

In my case, by using a shared mapping, visible to all cores, freezing
the core that is performing the write would have exposed the writable
mapping to a potential attack run from another core.

If the mapping is private to the core performing the write, even if it
is frozen, it's much harder to figure out what it had mapped and where,
from another core.

To access that mapping, the attack should be performed from the ISR, I
think.
Unless the secondary mapping is also available to other cores, through
the shared mm_struct ?
I don't think this matters much.  The other cores will only be able to
use that mapping when they're doing a rare write.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help