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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ