linux-kernel - Re: Execute in place

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200705072356.51283.a1426z@gawab.com>
Date:	Mon, 7 May 2007 23:56:51 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Dmitry Krivoschekov <dmitry.krivoschekov@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Execute in place

H. Peter Anvin wrote:
> Al Boldi wrote:
> > H. Peter Anvin wrote:
> >> Al Boldi wrote:
> >>> Isn't everything really just temporary?
> >>>
> >>> Would something like an mmap'd tmpfs be possible?
> >>
> >> No.  tmpfs relies on being able to leave data structures in the running
> >> kernel.  In particular, it has no metadata store at all.
> >>
> >> The needs for a persistent filesystem are very different, regardless of
> >> what the underlying medium is.
> >
> > Think Suspend-To-Disk; in that case tmpfs looks pretty persistent to me.
> >
> > So what does STD do?  It pushes memory out to swap.
>
> It pushes ALL of (used) memory out to swap.

Ok.

> > Now, tmpfs could probably do the same thing on its own either to a
> > private swap or an mmap.  I am suggesting mmap, as swap is currently
> > really slow with tmpfs, and switching it to use mmap may buy us 2 for
> > the price of 1.
>
> No.
>
> First of all, it would have to map ALL of kernel memory, or you would
> have to change the way things like dentries, inodes, and namespaces are
> allocated in the kernel itself.

That's probably one way of doing it.

> Second, you still would have no stability across kernel versions.

No problem.  You could probably convince the user to do a tmpfs backup before 
an upgrade.

> Third, you would have to accept total data loss on unclean shutdown,
> because tmpfs doesn't care about coherency, *NOR SHOULD IT*.

I think that's understood.  But this risk could be reduced by instantiating 
the latest sync'd mmap/swap.

> This is
> the fundamental reason why allocating a large swap partition and making
> /tmp a tmpfs can give a *huge* performance boost, even though it still
> hits disk.

Don't know what you mean here.  Do you mean that tmpfs performance is 
dependent on free swap-space being larger than some threshold.  If so, what 
threshold causes a tmpfs slowdown?

> What you're talking about is, *and should be*, a different filesystem.
> You will relatively quickly find that you have to deal with the same
> kind of stuff that you have to in any filesystem.

That's exactly what I want to avoid, as this would introduce a performance 
penalty.

All we need is a periodically synced tmpfs to mmap, with a minimal stream 
into page-cache algo on mount.


Thanks!

--
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/