Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Nov 2018 20:33:41 +0200
From: Igor Stoppa <>
To: Andy Lutomirski <>, Nadav Amit <>
CC: Igor Stoppa <>, Kees Cook <>,
	Peter Zijlstra <>, Mimi Zohar <>,
	Matthew Wilcox <>, Dave Chinner <>,
	James Morris <>, Michal Hocko <>, "Kernel
 Hardening" <>, linux-integrity
	<>, LSM List
	<>, Dave Hansen
	<>, Jonathan Corbet <>, Laura Abbott
	<>, Randy Dunlap <>, Mike Rapoport
	<>, "open list:DOCUMENTATION"
	<>, LKML <>, "Thomas
 Gleixner" <>
Subject: Re: [PATCH 10/17] prmem: documentation

I forgot one sentence :-(

On 13/11/2018 20:31, Igor Stoppa wrote:
> On 13/11/2018 19:47, Andy Lutomirski wrote:
>> 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 ?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.