On Mon, Feb 12, 2018 at 4:40 PM, Laura Abbott [off-list ref] wrote:
On 02/12/2018 03:27 PM, Kees Cook wrote:
quoted
On Sun, Feb 4, 2018 at 7:05 AM, Igor Stoppa [off-list ref]
wrote:
quoted
On 04/02/18 00:29, Boris Lukashev wrote:
quoted
On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa [off-list ref]
wrote:
[...]
quoted
quoted
What you are suggesting, if I have understood it correctly, is that,
when the pool is protected, the addresses already given out, will
become
traps that get resolved through a lookup table that is built based on
the content of each allocation.
That seems to generate a lot of overhead, not to mention the fact that
it might not play very well with the MMU.
That is effectively what i'm suggesting - as a form of protection for
consumers against direct reads of data which may have been corrupted
by some irrelevant means. In the context of pmalloc, it would probably
be a separate type of ro+verified pool
ok, that seems more like an extension though.
ATM I am having problems gaining traction to get even the basic merged
:-)
I would consider this as a possibility for future work, unless it is
said that it's necessary for pmalloc to be accepted ...
I would agree: let's get basic functionality in first. Both
verification and the physmap part can be done separately, IMO.
Skipping over physmap leaves a pretty big area of exposure that could
be difficult to solve later. I appreciate this might block basic
functionality but I don't think we should just gloss over it without
at least some idea of what we would do.
What's our exposure on physmap for other regions? e.g. things that are
executable, or made read-only later (like __ro_after_init)?
-Kees
--
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html