[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8818bfd4-dd9f-f279-0432-69b59531bd41@huawei.com>
Date: Sat, 3 Feb 2018 22:32:48 +0200
From: Igor Stoppa <igor.stoppa@...wei.com>
To: Boris Lukashev <blukashev@...pervictus.com>
CC: Christopher Lameter <cl@...ux.com>, Matthew Wilcox <willy@...radead.org>,
Jann Horn <jannh@...gle.com>, Jerome Glisse <jglisse@...hat.com>, Kees Cook
<keescook@...omium.org>, Michal Hocko <mhocko@...nel.org>, Laura Abbott
<labbott@...hat.com>, Christoph Hellwig <hch@...radead.org>,
linux-security-module <linux-security-module@...r.kernel.org>, Linux-MM
<linux-mm@...ck.org>, kernel list <linux-kernel@...r.kernel.org>, "Kernel
Hardening" <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH 4/6] Protectable Memory
On 03/02/18 22:12, Boris Lukashev wrote:
> Regarding the notion of validated protected memory, is there a method
> by which the resulting checksum could be used in a lookup
> table/function to resolve the location of the protected data?
What I have in mind is a checksum at page/vmap_area level, so there
would be no 1:1 mapping between a specific allocation and the checksum.
An extreme case would be the one where an allocation crosses one or more
page boundaries, while the checksum refers to a (partially) overlapping
memory area.
Code accessing a pool could perform one (relatively expensive)
validation. But still something that would require a more sophisticated
attack, to subvert.
> Effectively a hash table of protected allocations, with a benefit of
> dedup since any data matching the same key would be the same data
> (multiple identical cred structs being pushed around). Should leave
> the resolver address/csum in recent memory to check against, right?
I see where you are trying to land, but I do not see how it would work
without a further intermediate step.
pmalloc dishes out virtual memory addresses, when called.
It doesn't know what the user of the allocation will put in it.
The user, otoh, has the direct address of the memory it got.
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.
If I misunderstood, then I'd need a step by step description of what
happens, because it's not clear to me how else the data would be
accessed if not through the address that was obtained when pmalloc was
invoked.
--
igor
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.
