lkml.org 
[lkml]   [2018]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [kernel-hardening] [PATCH 4/6] Protectable Memory
    From
    Date
    On 04/02/18 00:29, Boris Lukashev wrote:
    > On Sat, Feb 3, 2018 at 3:32 PM, Igor Stoppa <igor.stoppa@huawei.com> wrote:

    [...]

    >> 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 ...

    --
    igor

    \
     
     \ /
      Last update: 2018-02-04 16:06    [W:3.845 / U:0.800 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site