linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Timofey Titovets <timofey.titovets@synesis.ru>
To: jannh@google.com
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	linux-mm@kvack.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH V3] KSM: allow dedup all tasks memory
Date: Tue, 13 Nov 2018 15:58:20 +0300	[thread overview]
Message-ID: <CAGqmi75MShkwHTiSLPiOoQuYORmYTBJVqMKXm7pKhoNg9PT3yw@mail.gmail.com> (raw)
In-Reply-To: <CAG48ez0VRmRQckOjQhOeaf6bLYkfi45ksdnzuCKPwBYTM+As1g@mail.gmail.com>

вт, 13 нояб. 2018 г. в 14:57, Jann Horn <jannh@google.com>:
>
> On Tue, Nov 13, 2018 at 12:40 PM Timofey Titovets
> <timofey.titovets@synesis.ru> wrote:
> > ksm by default working only on memory that added by
> > madvise().
> >
> > And only way get that work on other applications:
> >   * Use LD_PRELOAD and libraries
> >   * Patch kernel
> >
> > Lets use kernel task list and add logic to import VMAs from tasks.
> >
> > That behaviour controlled by new attributes:
> >   * mode:
> >     I try mimic hugepages attribute, so mode have two states:
> >       * madvise      - old default behaviour
> >       * always [new] - allow ksm to get tasks vma and
> >                        try working on that.
>
> Please don't. And if you really have to for some reason, put some big
> warnings on this, advising people that it's a security risk.
>
> KSM is one of the favorite punching bags of side-channel and hardware
> security researchers:
>
> As a gigantic, problematic side channel:
> http://staff.aist.go.jp/k.suzaki/EuroSec2011-suzaki.pdf
> https://www.usenix.org/system/files/conference/woot15/woot15-paper-barresi.pdf
> https://access.redhat.com/blogs/766093/posts/1976303
> https://gruss.cc/files/dedup.pdf
>
> In particular https://gruss.cc/files/dedup.pdf ("Practical Memory
> Deduplication Attacks in Sandboxed JavaScript") shows that KSM makes
> it possible to use malicious JavaScript to determine whether a given
> page of memory exists elsewhere on your system.
>
> And also as a way to target rowhammer-based faults:
> https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf
> https://thisissecurity.stormshield.com/2017/10/19/attacking-co-hosted-vm-hacker-hammer-two-memory-modules/

I'm very sorry, i'm not a security specialist.
But if i understood correctly, ksm have that security issues _without_
my patch set.
Even more, not only KSM have that type of issue, any memory
deduplication have that problems.
Any guy who care about security must decide on it self. Which things
him use and how he will
defend from others.
Even more on it self he must learn tools, what he use and make some
decision right?

So, if you really care about that problem in general, or only on KSM side,
that your initiative and your duty to warn people about that.

KSM already exists for 10+ years. You know about security implication
of use memory deduplication.
That your duty to send a patches to documentation, and add appropriate warnings.

Sorry for my passive aggressive,
i don't try hurt someone, or humiliate.

That's just my IMHO and i'm just to restricted in my english knowledge,
to write that more gentle.

Thanks!

  reply	other threads:[~2018-11-13 12:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-12 23:13 [PATCH V3] KSM: allow dedup all tasks memory Timofey Titovets
2018-11-13  1:49 ` Matthew Wilcox
2018-11-13 11:25   ` Timofey Titovets
2018-11-13  2:25 ` Pavel Tatashin
2018-11-13 11:40   ` Timofey Titovets
2018-11-13 18:42     ` Pavel Tatashin
2018-11-13 22:55       ` Timofey Titovets
2018-11-13 11:57 ` Jann Horn
2018-11-13 12:58   ` Timofey Titovets [this message]
2018-11-13 13:25     ` Jann Horn
     [not found] <<CAG48ez0ZprqUYGZFxcrY6U3Dnwt77q1NJXzzpsn1XNkRuXVppw@mail.gmail.com>
2018-11-13 14:23 ` Oleksandr Natalenko
2018-11-13 17:59   ` Pavel Tatashin
2018-11-13 18:17     ` Timofey Titovets
2018-11-13 18:35       ` Pavel Tatashin
2018-11-13 18:54         ` Timofey Titovets
2018-11-13 19:16           ` Pavel Tatashin
2018-11-13 22:40             ` Timofey Titovets
2018-11-13 22:53               ` Pavel Tatashin
2018-11-13 23:07                 ` Timofey Titovets
2018-11-13 20:26     ` Jann Horn
2018-11-13 22:35       ` Pavel Tatashin
     [not found] <<20181112231344.7161-1-timofey.titovets@synesis.ru>
2018-11-13 11:06 ` Oleksandr Natalenko
2018-11-13 11:56   ` Timofey Titovets
2018-11-13 16:33 ` Oleksandr Natalenko
2018-11-13 17:10   ` Timofey Titovets
2018-11-13 17:27     ` Oleksandr Natalenko
2018-11-13 17:44       ` Timofey Titovets
2018-11-13 18:20 Timofey Titovets

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGqmi75MShkwHTiSLPiOoQuYORmYTBJVqMKXm7pKhoNg9PT3yw@mail.gmail.com \
    --to=timofey.titovets@synesis.ru \
    --cc=jannh@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).