linux-kernel - Re: Fixing NFS over OpenVPN

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] [day] [month] [year] [list]

Message-ID: <m2ehrdodv4.fsf@firstfloor.org>
Date:	Mon, 23 Apr 2012 23:14:39 -0700
From:	Andi Kleen <andi@...stfloor.org>
To:	Toby Goodwin <toby@...hic-beasts.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Fixing NFS over OpenVPN

Toby Goodwin <toby@...hic-beasts.com> writes:
>
> I believe I know how to fix this, but would appreciate some guidance.
> Part of the solution is to specify the "--mlock" flag to openvpn -- this
> exists so that secrets are never written to swap, but as a side effect
> it prevents openvpn from ever page faulting.

mlock does not prevent page faulting. It merely prevents existing pages
getting swapped out, but new pages can be definitely be faulted in.
Your explanation would only make sense if all swappable memory 
in the system is tied up in the openvpn process, which is unlikely.

That said there may be still deadlocks if openvpn needs any new
memory for writing data, but that has nothing to do with mlock.

In fact the mlock should make it more stable under swapping, but you
still have the problem you describe next.

> userland AF_INET socket. (This is the socket through which OpenVPN sends
> its encrypted packets to the remote end of the tunnel.) I haven't
> discovered any way for userland to request a particular allocation
> policy for a socket, please let me know if I've missed something.

Just changing to GFP_NOIO will not fully solve the problem. 

You really would need a preallocated mempool of pages for the socket
(similar to Mel Gorman/ Peter Ziljstra's swap-over-NFS
patchkit). Essentially the whole IO path needs to be able to work
without allocating new memory.
>
> Is there a better way to solve this?

Probably parts of openvpn would need to move into the kernel.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only
--
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/