From owner-freebsd-jail@FreeBSD.ORG Sun Jun 7 01:39:38 2015 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2B3C6C8; Sun, 7 Jun 2015 01:39:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACE92182D; Sun, 7 Jun 2015 01:39:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by wgme6 with SMTP id e6so79328901wgm.2; Sat, 06 Jun 2015 18:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=KRjVQh4jIuZpxziV/mYVyC5udTp3d7Xp/x59TzSB4AE=; b=YaR0J7OJftBNaJFDeDr/GP+XsvQIF2QmNfLOUItUmrdZWM1a0XDUH4jnRVkTlxA+9q JRmC2pAhQH7OEC71LmP0wS0n5EL+JHz41c/X0ZTEaW1IUOC5A4hy9ZXStbe+Cvc3MK5k fmv1ycMnTfkltCHURNEViwjUg9WOiofWhjvQ9xNYG5GuJpnuk9iO/Jta203MWqoOEubU Ovf6wDDVtbka2HIpRw8k+77XBEMOwajVBqh9LqwH/ZbBWtCn2v3/hTFyLAxK62lLXjme uHhdQCecgn/y+0RoCUyxsflP7v3a6ZFjq2UgFlLrhGyGEq2Osnkl8v23HcjO8Rj7n+as h8KQ== X-Received: by 10.195.13.1 with SMTP id eu1mr19405799wjd.131.1433641174551; Sat, 06 Jun 2015 18:39:34 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id u7sm4758833wif.3.2015.06.06.18.39.32 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 06 Jun 2015 18:39:32 -0700 (PDT) Date: Sun, 7 Jun 2015 03:39:30 +0200 From: Mateusz Guzik To: kikuchan Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [patch] separate SysV IPC namespace for jail Message-ID: <20150607013929.GA9182@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 01:39:38 -0000 On Sun, Jun 07, 2015 at 12:04:17AM +0900, kikuchan wrote: > Sorry for cross-post to freebsd-stable, but I want to get more > feedback for my patch. > (The patch is; http://lists.freebsd.org/pipermail/freebsd-jail/attachments/20150606/7736309b/attachment.bin) > > > I believe this patch FIXES current SysV IPC for jail WITHOUT changing > current kernel architecture. > (so I hope it will be merged into stable/10) > > Let me explain what happens currently, with and without my patch, > since it's little confusing. > > > I use SysV IPC shared memory (SYSVSHM) as an example here, because > it's easy to understand. > Remember shmget / shmat / shmdt / shmctl, are syscalls of SYSVSHM. > > All normal processes have its own virtual memory space, it is done by kernel. > A backend component of virtual memory is a page, is on real memory or > on swap devices. > > SYSVSHM provides a way to share memory segments on the page between > processes on userland. > A process can load the page into its own virtual memory space with > shmat syscall. > Once the page is loaded into the virtual memory space, the page is > accessible until further shmdt syscall or exit of process. > > Another process can obtain the exact same page, by calling shmat syscall. > So, permission of shmat syscall is very important. > > > > Address space can be shared between multiple jails > This was a typo. Let me quote fixed version: "Address space can be shared between multiple PROCESSES, what happens if such a pair ends up in different jails? Preferably such a scenario would be prohibited to avoid future accidents." However, sysvipc namespace sharing is an ok feature esp. with multi-level jails. In the simplest scenario upon jail creation you decide whether it gets its own namespace or inherits it. > > What about existing sysvshm mappings when jailing? > > Real (not jailed) environment is treated as a jail with jid=0 in kernel. > If you create sysvshm memory segment before entering a jail, the > segment simply owned by jid=0. > The point is you get a process with sysvshm segments from 2 different jails. Looks like solid trouble protential. > > > Extending struct prison with relevant pointers and updating the code to > > You don't need to extend the struct to separate IPC namespaces. > The word "namespaces" means a key (key_t) of IPC syscall, here. > > Whether the struct should be extended or not, depends on how we want > to control IPC resources for each jail. > If you want to control SysV IPC resources by changing sysctl > parameters from inside of jail for each jail, > then it might be yes. > But I think per-jail resource control should be done with RACCT, and > it might be applied to my implementation too. > > > The one missing feature is how to export information to userland. > This should be discuss separately, even if my patch is rejected. > (If visibility control is needed for ipcs, maybe it should use similar > technique to ps or netstat?) > > > Conclusion; > I think my patch is better than broken. (SysV IPC + jail is buggy over > 10 years!) > The feature in question is definitely desirable, but your patch is hack, with the "hack" part visible to userspace. As mentioned earlier there are some things to do before any kind of jail-aware ipcs land in the tree. As a minimum this is singlethreading when jailing, prevention of jailing processes with shared virtual address spaces and ones with existing sysvshm mappings. All this is to reduce amount of bugs one would have to deal with. After the work is completed there is no problem whatsoever with providing per-jail sysvipcs. This avoids information leaks (no id list to look at) and conflicts. Exporting is not a problem either - a dedicated sysctl grabs JID and dumps its ipcs. It also gets a 'recursive' flag to know whether ipcs for its own jails should be dumped as well (if different). -- Mateusz Guzik From owner-freebsd-jail@FreeBSD.ORG Sun Jun 7 07:43:21 2015 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3F1A5E6; Sun, 7 Jun 2015 07:43:21 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from smtp01.cm.dti.ne.jp (smtp.ipv6.cm.dream.jp [IPv6:2001:2e8:702::236:70:47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8995A1B88; Sun, 7 Jun 2015 07:43:21 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by smtp01.cm.dti.ne.jp (3.11s) with ESMTP AUTH id t577hHVg015639; Sun, 7 Jun 2015 16:43:17 +0900 (JST) Received: by ykfl8 with SMTP id l8so40446140ykf.1; Sun, 07 Jun 2015 00:43:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.113.132 with SMTP id m126mr9933741ywc.12.1433662996511; Sun, 07 Jun 2015 00:43:16 -0700 (PDT) Received: by 10.13.227.196 with HTTP; Sun, 7 Jun 2015 00:43:16 -0700 (PDT) In-Reply-To: <20150607013929.GA9182@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> <20150607013929.GA9182@dft-labs.eu> Date: Sun, 7 Jun 2015 16:43:16 +0900 Message-ID: Subject: Re: [patch] separate SysV IPC namespace for jail From: kikuchan To: Mateusz Guzik Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 07:43:21 -0000 Hi Mateusz, Thanks for your reply! First of all, I intend to *jail* SysV IPC user completely. (unless user really want to interact with each other between jails) I think SysV IPC is simple but obsolete, so you can design whatever you want for jail system. Also, I want keep everything simple. My design (to be sure): - Each entry of the list (shown in ipcs) belongs to a jail. - Any operation to SHM/SEM/MSG attempted from another jail, will just fail with EACCES. > "Address space can be shared between multiple PROCESSES, what happens if > such a pair ends up in different jails? Preferably such a scenario would > be prohibited to avoid future accidents." > > However, sysvipc namespace sharing is an ok feature esp. with > multi-level jails. In the simplest scenario upon jail creation you > decide whether it gets its own namespace or inherits it. > > > > What about existing sysvshm mappings when jailing? > > > > Real (not jailed) environment is treated as a jail with jid=0 in kernel. > > If you create sysvshm memory segment before entering a jail, the > > segment simply owned by jid=0. > > > > The point is you get a process with sysvshm segments from 2 different > jails. Looks like solid trouble protential. Ok, I think I've got what you'd concerned. In my design, setting up such processes would be difficult. This wouldn't be happend normally, because shared memory segments should be obtained BEFORE entering a jail; 1. Create a segment on jid=0 with shmget() 2. shmat() to attach (get void *ptr) 3. fork() 4. A child process entering to jid=1 with jail_attach() 5. The child process and the parent process can share the address space (via *ptr). 6. If the child process do shmat() on the same ID again, it simply failed with EACCES. It means, there is NO way to obtain a segment created in other jail AFTER jailed (even if you're root or obtaining the segment created on jid=0). This looks like file descriptors. It's also a fool-proof design, because most applications don't use FreeBSD's unique and special jail system directly. At this point, the patch breaks backward-compatibility, so we might need an option in kernel configuration. It's enough by configuration, because I think the current FreeBSD's SysV IPC behavior of jail is a BUG, not a feature. # Who using jail wants this dangerous behavior?! > The feature in question is definitely desirable, but your patch is hack, > with the "hack" part visible to userspace. > As mentioned earlier there are some things to do before any kind of > jail-aware ipcs land in the tree. Thanks. These should be solved. > As a minimum this is singlethreading > when jailing, prevention of jailing processes with shared virtual address > spaces and ones with existing sysvshm mappings. All this is to reduce > amount of bugs one would have to deal with. Virtual memory allocation and related stuff are protected and done by kernel already, because it's an IPC (Inter Process Communication). Moreover, you cannot change an owner of the IPC entry after creation, so we don't need an additional protection in kernel. Regards, Kikuchan On Sun, Jun 7, 2015 at 10:39 AM, Mateusz Guzik wrote: > On Sun, Jun 07, 2015 at 12:04:17AM +0900, kikuchan wrote: >> Sorry for cross-post to freebsd-stable, but I want to get more >> feedback for my patch. >> (The patch is; http://lists.freebsd.org/pipermail/freebsd-jail/attachments/20150606/7736309b/attachment.bin) >> >> >> I believe this patch FIXES current SysV IPC for jail WITHOUT changing >> current kernel architecture. >> (so I hope it will be merged into stable/10) >> >> Let me explain what happens currently, with and without my patch, >> since it's little confusing. >> >> >> I use SysV IPC shared memory (SYSVSHM) as an example here, because >> it's easy to understand. >> Remember shmget / shmat / shmdt / shmctl, are syscalls of SYSVSHM. >> >> All normal processes have its own virtual memory space, it is done by kernel. >> A backend component of virtual memory is a page, is on real memory or >> on swap devices. >> >> SYSVSHM provides a way to share memory segments on the page between >> processes on userland. >> A process can load the page into its own virtual memory space with >> shmat syscall. >> Once the page is loaded into the virtual memory space, the page is >> accessible until further shmdt syscall or exit of process. >> >> Another process can obtain the exact same page, by calling shmat syscall. >> So, permission of shmat syscall is very important. >> >> >> > Address space can be shared between multiple jails >> > > This was a typo. Let me quote fixed version: > > "Address space can be shared between multiple PROCESSES, what happens if > such a pair ends up in different jails? Preferably such a scenario would > be prohibited to avoid future accidents." > > However, sysvipc namespace sharing is an ok feature esp. with > multi-level jails. In the simplest scenario upon jail creation you > decide whether it gets its own namespace or inherits it. > >> > What about existing sysvshm mappings when jailing? >> >> Real (not jailed) environment is treated as a jail with jid=0 in kernel. >> If you create sysvshm memory segment before entering a jail, the >> segment simply owned by jid=0. >> > > The point is you get a process with sysvshm segments from 2 different > jails. Looks like solid trouble protential. > >> >> > Extending struct prison with relevant pointers and updating the code to >> >> You don't need to extend the struct to separate IPC namespaces. >> The word "namespaces" means a key (key_t) of IPC syscall, here. >> >> Whether the struct should be extended or not, depends on how we want >> to control IPC resources for each jail. >> If you want to control SysV IPC resources by changing sysctl >> parameters from inside of jail for each jail, >> then it might be yes. >> But I think per-jail resource control should be done with RACCT, and >> it might be applied to my implementation too. >> >> >> The one missing feature is how to export information to userland. >> This should be discuss separately, even if my patch is rejected. >> (If visibility control is needed for ipcs, maybe it should use similar >> technique to ps or netstat?) >> >> >> Conclusion; >> I think my patch is better than broken. (SysV IPC + jail is buggy over >> 10 years!) >> > > The feature in question is definitely desirable, but your patch is hack, > with the "hack" part visible to userspace. > > As mentioned earlier there are some things to do before any kind of > jail-aware ipcs land in the tree. As a minimum this is singlethreading > when jailing, prevention of jailing processes with shared virtual address > spaces and ones with existing sysvshm mappings. All this is to reduce > amount of bugs one would have to deal with. > > After the work is completed there is no problem whatsoever with > providing per-jail sysvipcs. This avoids information leaks (no id list > to look at) and conflicts. > > Exporting is not a problem either - a dedicated sysctl grabs JID and > dumps its ipcs. It also gets a 'recursive' flag to know whether ipcs > for its own jails should be dumped as well (if different). > > -- > Mateusz Guzik From owner-freebsd-jail@FreeBSD.ORG Sun Jun 7 08:37:40 2015 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6BC7B0E; Sun, 7 Jun 2015 08:37:40 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8B816ED; Sun, 7 Jun 2015 08:37:40 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by wiwd19 with SMTP id d19so56885546wiw.0; Sun, 07 Jun 2015 01:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QB0merXAn2Dx6KcaOqabWMD9r1JS4bxd/YvsvFw7UJ8=; b=F1BZ/+rIXdL5j2hYBg9anIZEi2mwsoAawxYAsMWIx2hHP8KxQtHWTCJ9YIqkdcm2aA P4rbUC93WToyzDEDYtCk8wLla9Sn0CDG5MkkDXYryI2y8757Pa2DeqKSGuAhM1zrHM4f bdk1IgWgv1KAhhsHXwveXHziVVzaLjE/h6ijj26ixOIOUrHlj7u47S+x/GV1nkl78M+g 1eUGqVWJd6Xmup+Zg54fCpkuP4NBx1ujjcVUAy22akB2ExmlWqZlJDqetVUMKxw11Ulj jZUGsCrkEz67y0Pw8Lk5SL2pfy7WnZpWphwK2nD+DX2I+3z5BxRl2tUtRXUO5XJVUSYf 5uyg== X-Received: by 10.180.74.132 with SMTP id t4mr11922677wiv.55.1433666258277; Sun, 07 Jun 2015 01:37:38 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id ch2sm2680033wib.18.2015.06.07.01.37.36 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 07 Jun 2015 01:37:36 -0700 (PDT) Date: Sun, 7 Jun 2015 10:37:34 +0200 From: Mateusz Guzik To: kikuchan Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [patch] separate SysV IPC namespace for jail Message-ID: <20150607083734.GB9182@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> <20150607013929.GA9182@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 08:37:40 -0000 On Sun, Jun 07, 2015 at 04:43:16PM +0900, kikuchan wrote: > Hi Mateusz, > > Thanks for your reply! > > First of all, I intend to *jail* SysV IPC user completely. > (unless user really want to interact with each other between jails) > > I think SysV IPC is simple but obsolete, so you can design whatever > you want for jail system. > Also, I want keep everything simple. > > My design (to be sure): > - Each entry of the list (shown in ipcs) belongs to a jail. > - Any operation to SHM/SEM/MSG attempted from another jail, will just > fail with EACCES. > But why? See below. > > > "Address space can be shared between multiple PROCESSES, what happens if > > such a pair ends up in different jails? Preferably such a scenario would > > be prohibited to avoid future accidents." > > > > However, sysvipc namespace sharing is an ok feature esp. with > > multi-level jails. In the simplest scenario upon jail creation you > > decide whether it gets its own namespace or inherits it. > > > > > > What about existing sysvshm mappings when jailing? > > > > > > Real (not jailed) environment is treated as a jail with jid=0 in kernel. > > > If you create sysvshm memory segment before entering a jail, the > > > segment simply owned by jid=0. > > > > > > > The point is you get a process with sysvshm segments from 2 different > > jails. Looks like solid trouble protential. > > Ok, I think I've got what you'd concerned. > > In my design, setting up such processes would be difficult. > This wouldn't be happend normally, because shared memory segments > should be obtained BEFORE entering a jail; > > 1. Create a segment on jid=0 with shmget() > 2. shmat() to attach (get void *ptr) > 3. fork() > 4. A child process entering to jid=1 with jail_attach() > 5. The child process and the parent process can share the address > space (via *ptr). > 6. If the child process do shmat() on the same ID again, it simply > failed with EACCES. > > It means, there is NO way to obtain a segment created in other jail > AFTER jailed (even if you're root or obtaining the segment created on > jid=0). This is sharing a page, not an address space (see below). This poses serious problems if actual separate namespaces are implemented, otherwise it only leaves a potential for bugs for no real gain. > > As a minimum this is singlethreading > > when jailing, prevention of jailing processes with shared virtual address > > spaces and ones with existing sysvshm mappings. All this is to reduce > > amount of bugs one would have to deal with. > > Virtual memory allocation and related stuff are protected and done by > kernel already, because it's an IPC (Inter Process Communication). > Moreover, you cannot change an owner of the IPC entry after creation, > so we don't need an additional protection in kernel. > Here is an example race: on fork memory mappings are copied first, sysvshm data is updated /later/. What happens if one of the calling threads enters a jail while some other thread is forking? This may be buggy as it is already, but that's roughly the scheme. It looks like we have some weird miscommunication here, so let me restate. I do see great benefit in having jail-aware ipcs. I do not believe the way to achieve it is to add jail-aware permission checks. Support in question should provide support for separate namespaces. The are several upsides, including lack of conflict between jails and plugged infoleaks. In general I don't understand why you insist on your approach, I does not have any advantage over separate namespaces that I could see. -- Mateusz Guzik From owner-freebsd-jail@FreeBSD.ORG Mon Jun 8 17:17:09 2015 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4151F8B5; Mon, 8 Jun 2015 17:17:09 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAE4619BE; Mon, 8 Jun 2015 17:17:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by wgez8 with SMTP id z8so108624513wge.0; Mon, 08 Jun 2015 10:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=cM+WLLwDU4aST7D1BjBpR631KfxU8jZom4piDveOD5Y=; b=SZd+Y0jzH12/O7REeN+r+vufC6lSVoBtirwx9BAOXVqe8gLjPd0KejJpOuBUBxYhwl 61fRgQLtPP1LkrjrJCSw1EElZfqjVDeYvVU5HCKaKWR5DnAu407phqejBWn6gUVJsTXG J0B+Mtr6cSI81RrWD/PYU5lsDocv61fp6P1wtZuoI7PgwFjMEoae/ZSlo0Y1T6bpS8Rl EGhPhMTix2cXxFMo8Aj8WCWccozXeb2unGJIaaF1gKVwSVxqWq/9Yu5P1LG3R4mkwwWB eth/a324Q8Elw1V6VmtGqu3eVK2XHa/eAJj5B6/laB60zN55IsOZRO6KYI29n8h/nXqg bVXg== X-Received: by 10.180.77.102 with SMTP id r6mr82167wiw.87.1433783827306; Mon, 08 Jun 2015 10:17:07 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id gw7sm2032939wib.15.2015.06.08.10.17.05 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 08 Jun 2015 10:17:05 -0700 (PDT) Date: Mon, 8 Jun 2015 19:17:03 +0200 From: Mateusz Guzik To: kikuchan Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [patch] separate SysV IPC namespace for jail Message-ID: <20150608171702.GA15516@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> <20150607013929.GA9182@dft-labs.eu> <20150607083734.GB9182@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 17:17:09 -0000 On Mon, Jun 08, 2015 at 01:42:21AM +0900, kikuchan wrote: > From my curiosity, is my patch a technically bad? > Is there race condition in it? Or, enabling key_t separation for jail > could trigger race condition, perhaps? > I only briefly looked at the patch. The fact that you perform outside of ipcperm looks suspicious but may be harmless, so at best it's a bad style. If you need ipc mechanism-specifc functions, make them call ipcperm instead. The jail check is too simplistic. Jails higher in the hierarchy should be able to access whatever lower jails produced. > > > I do see great benefit in having jail-aware ipcs. > > > > I do not believe the way to achieve it is to add jail-aware permission > > checks. Support in question should provide support for separate > > namespaces. The are several upsides, including lack of conflict between > > jails and plugged infoleaks. > > Sorry but I might misunderstand what your "separate namespaces" means. > What namespace are you going to separate? key_t, shmid, kernel > structure of shm, or others? > What features do your "jail-aware ipcs" provide? > Well, as I said in my first mail the idea is to make ipc code look at structures assigned to given jail, so that we can have multiple jails with only their own objects. No "well, this id is used by other jail", unless the namespace is explicitly shared. I did have a patch with a meh implementation doing this, but I lost it along the way. It is easy to implement it for "private purposes" (i.e. disregarding possible attacks with jailing processes). The real work is making the whole business safe. For instance back then I could not find any reliable mechanism to tell me whether given process has a shared address space. There is only a vm_refcnt counter in vmspace which is modified on various occasions, thus is not suitable. Adding a separate counter sucks and adding a "once set, never cleared flag" sucks as well. Maybe there is a good method. -- Mateusz Guzik From owner-freebsd-jail@FreeBSD.ORG Tue Jun 9 16:56:05 2015 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C14AE93B; Tue, 9 Jun 2015 16:56:05 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from vsmtp06.dti.ne.jp (vsmtp06.dti.ne.jp [202.216.231.141]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF921444; Tue, 9 Jun 2015 16:56:04 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from mail.dream.jp (webmail02.ga.dti.ne.jp [202.216.229.153]) by vsmtp06.dti.ne.jp (3.11v) with ESMTP AUTH id t59GhxZq026990; Wed, 10 Jun 2015 01:43:59 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Date: Wed, 10 Jun 2015 01:43:59 +0900 From: To: Mateusz Guzik Cc: , Subject: Re: [patch] separate SysV IPC namespace for jail In-Reply-To: <20150608171702.GA15516@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> <20150607013929.GA9182@dft-labs.eu> <20150607083734.GB9182@dft-labs.eu> <20150608171702.GA15516@dft-labs.eu> Message-ID: X-Sender: kikuchan@uranus.dti.ne.jp User-Agent: DTI MyMail/0.3-trunk X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 16:56:05 -0000 Hi Mateusz, Thank you for your reply. (and sorry about my ISP mail service jammed...) I still want to resolve sysv ipc confilicts between jails somehow. (It's welcome if someone else do, but I couldn't find any working example yet...) > I only briefly looked at the patch. The fact that you perform outside of > ipcperm looks suspicious but may be harmless, so at best it's a bad > style. If you need ipc mechanism-specifc functions, make them call > ipcperm instead. Sorry, I guess EACCES misled you. I should have chosen other value and/or concealed information for each jail completely. I intended to demonstrate it's enought to achieve IPC key_t space separation (to PostgreSQL work) for each jails without having shmid_kernel struct for each jails. > The jail check is too simplistic. Jails higher in the hierarchy should be > able to access whatever lower jails produced. Yes I thought so, however, I realized that a single key_t space per jail is enough, otherwise user get confused. Hmm, but yes, probably you're right. I can't find any technical reason to forbid the behavior you mentioned. (I think it needs to modify ipcs(1) so that can display JID to avoid confusing) > Well, as I said in my first mail the idea is to make ipc code look at > structures assigned to given jail, so that we can have multiple jails > with only their own objects. No "well, this id is used by other jail", > unless the namespace is explicitly shared. Ok, now I've understood what the idea is, and maybe it's done by Nick once before on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 I'm reading the code (shm so far) and kernel deeply now, and I'm so sorry about confusing you due to less knowledge of kernel code. There are two identifier, ID and KEY (shmid and shmkey for SHM) on SysV IPC object. The KEY space must be separated for each jails I think, but about the ID, is determined by kernel and userland users don't care its value, do you really think it should be managed separately in kernel? I agree that "multiple jails with only their own objects" is good design basically, but especially, if you want to support hierarchical jails, the objects will be referenced by multiple jails. If ID space separation is not so important, separating internal namespace for each jail is too complicate for simple KEY space separation, I think. I really should have implemented to conceal information instead of returning EACCES, sorry. ;/ Before jumping to the conclusion, I want to know that *current* code relative to SHM whether have any problems on sharing underlaying vm page between processes that jailed to different jails each other, especially on fork and jail_attach. multithreaded process perhaps? I'm also trying to port Nick's code to 10/stable, then I've found potentially dangerous behavior happens if a process do jail_attach to other jail, due to the separate namespaces have separate ID space for each jail. I guess it was not happned on 4.8 because lack of jail_attach. For example, a process attached to shmid = 65535 on jid=1, then the process changes its jail to jid=2, and if shmid = 65535 exists on jid=2, the process refers wrong vm mapping unless maintain shmmap_state data for the process every jail_attach. Maybe this behavior is something relative to the race that you mentioned before? > For instance back then I could not find any reliable mechanism to tell > me whether given process has a shared address space. There is only a > vm_refcnt counter in vmspace which is modified on various occasions, Hmm, sorry I can't understand what the problem is here... I'm not good at kernel internals yet, so I don't know details of when the processes share the address space, and I have no idea why you want to know whether the process has a shared address space or not... > It is easy to implement it for "private purposes" (i.e. > disregarding possible attacks with jailing processes). The real work is > making the whole business safe. I agree. Is there any project ongoing for this sysvipc issue? If any, what is needed to be done? P.S. I'm really sorry if you feel bad, due to my bad English skill... Regards, Kikuchan On Mon, 8 Jun 2015 19:17:03 +0200, Mateusz Guzik wrote: > On Mon, Jun 08, 2015 at 01:42:21AM +0900, kikuchan wrote: >> From my curiosity, is my patch a technically bad? >> Is there race condition in it? Or, enabling key_t separation for jail >> could trigger race condition, perhaps? >> > > I only briefly looked at the patch. The fact that you perform outside of > ipcperm looks suspicious but may be harmless, so at best it's a bad > style. If you need ipc mechanism-specifc functions, make them call > ipcperm instead. > > The jail check is too simplistic. Jails higher in the hierarchy should be > able to access whatever lower jails produced. > >> >> > I do see great benefit in having jail-aware ipcs. >> > >> > I do not believe the way to achieve it is to add jail-aware permission >> > checks. Support in question should provide support for separate >> > namespaces. The are several upsides, including lack of conflict between >> > jails and plugged infoleaks. >> >> Sorry but I might misunderstand what your "separate namespaces" means. >> What namespace are you going to separate? key_t, shmid, kernel >> structure of shm, or others? >> What features do your "jail-aware ipcs" provide? >> > > Well, as I said in my first mail the idea is to make ipc code look at > structures assigned to given jail, so that we can have multiple jails > with only their own objects. No "well, this id is used by other jail", > unless the namespace is explicitly shared. > > I did have a patch with a meh implementation doing this, but I lost it > along the way. It is easy to implement it for "private purposes" (i.e. > disregarding possible attacks with jailing processes). The real work is > making the whole business safe. > > For instance back then I could not find any reliable mechanism to tell > me whether given process has a shared address space. There is only a > vm_refcnt counter in vmspace which is modified on various occasions, > thus is not suitable. Adding a separate counter sucks and adding a "once > set, never cleared flag" sucks as well. Maybe there is a good method. From owner-freebsd-jail@FreeBSD.ORG Tue Jun 9 19:26:54 2015 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86F90B42; Tue, 9 Jun 2015 19:26:54 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lb0-x241.google.com (mail-lb0-x241.google.com [IPv6:2a00:1450:4010:c04::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 071AE1983; Tue, 9 Jun 2015 19:26:54 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by lbdu14 with SMTP id u14so3041481lbd.2; Tue, 09 Jun 2015 12:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=a6M9ARDFBs8d3QwPtxVcBi575CaQasE5WZml6rNeQls=; b=RY9EubFcQIXM4aijfYfELaJrB5KM3V9/ZJKoXJYFgWddHOaVYJlxZ+mmqMwAEjxVa+ ft7o5T1fwNpLzqmXXxeVTx9jqjr1b5tg1TmspSVrdU7FcxozqvRuswvVYC55QgyjqdMr igSgkcbIhjaGjDg8yiEBD7LlP3LNaeRmjE1GxnwiuMJGqf9A6Lz64ZAws8AZz6CUbDgy FYaA+TCc/Yj0RJuq6NlbClFUZnc81XRD1J7RYi920/Wyn/VF0KeycJwKcMEvKZWNbWWm oTx7r31WoI9np45iJc9+3hKlDTHf2YqC8rcXcj2M/HfEX92zPustU+GxsGLqUTF7caY1 8LCw== X-Received: by 10.180.95.10 with SMTP id dg10mr707492wib.41.1433878011472; Tue, 09 Jun 2015 12:26:51 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id hm8sm10878031wjc.28.2015.06.09.12.26.48 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 09 Jun 2015 12:26:49 -0700 (PDT) Date: Tue, 9 Jun 2015 21:26:46 +0200 From: Mateusz Guzik To: kikuchan@uranus.dti.ne.jp Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [patch] separate SysV IPC namespace for jail Message-ID: <20150609192646.GC2039@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> <20150607013929.GA9182@dft-labs.eu> <20150607083734.GB9182@dft-labs.eu> <20150608171702.GA15516@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 19:26:54 -0000 On Wed, Jun 10, 2015 at 01:43:59AM +0900, kikuchan@uranus.dti.ne.jp wrote: > > I only briefly looked at the patch. The fact that you perform outside of > > ipcperm looks suspicious but may be harmless, so at best it's a bad > > style. If you need ipc mechanism-specifc functions, make them call > > ipcperm instead. > > Sorry, I guess EACCES misled you. > I should have chosen other value and/or concealed information for each jail completely. > > I intended to demonstrate it's enought to achieve IPC key_t space separation (to PostgreSQL work) for each jails without having shmid_kernel struct for each jails. > There is no technical problem with providing entirely separate ipcs which would not have to be solved with this approach. This approach is actually harder to get right and has no benefit that I would see. One example downside is resource limiting - implementing per-namespace limits is a non-problem. > > Well, as I said in my first mail the idea is to make ipc code look at > > structures assigned to given jail, so that we can have multiple jails > > with only their own objects. No "well, this id is used by other jail", > > unless the namespace is explicitly shared. > > Ok, now I've understood what the idea is, and maybe it's done by Nick once before on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 > > There are two identifier, ID and KEY (shmid and shmkey for SHM) on SysV IPC object. > The KEY space must be separated for each jails I think, but about the ID, is determined by kernel and userland users don't care its value, do you really think it should be managed separately in kernel? > I agree that "multiple jails with only their own objects" is good design basically, but especially, if you want to support hierarchical jails, the objects will be referenced by multiple jails. > If ID space separation is not so important, separating internal namespace for each jail is too complicate for simple KEY space separation, I think. > Not separating stuff is more complicated. > I really should have implemented to conceal information instead of returning EACCES, sorry. ;/ > > Before jumping to the conclusion, I want to know that *current* code relative to SHM whether have any problems on sharing underlaying vm page between processes that jailed to different jails each other, especially on fork and jail_attach. multithreaded process perhaps? > There is definitely no problem sharing /a page/. There may be a problem sharing a page which was obtained from syvshm. > I'm also trying to port Nick's code to 10/stable This patch is old and deals with the mostly mechanical part of the work. In particular, it DOES NOT deal with any concerns I already expressed. This is understanadble to some extent since there were no multilevel jails at the time and some people may have felt securing against host root is not necessary. The patch will likely have a lot of conflicts and it will be way faster to write from scratch. > I guess it was not happned on 4.8 because lack of jail_attach. > For example, a process attached to shmid = 65535 on jid=1, then the process changes its jail to jid=2, and if shmid = 65535 exists on jid=2, the process refers wrong vm mapping unless maintain shmmap_state data for the process every jail_attach. This is an example problem. > Maybe this behavior is something relative to the race that you mentioned before? It is not. > > > > For instance back then I could not find any reliable mechanism to tell > > me whether given process has a shared address space. There is only a > > vm_refcnt counter in vmspace which is modified on various occasions, > > Hmm, sorry I can't understand what the problem is here... > I'm not good at kernel internals yet, so I don't know details of when the processes share the address space, and I have no idea why you want to know whether the process has a shared address space or not... > rfork has a flag which makes the new process share the address space with the parent. So when one of these processes jails somewhere, we can end up with mappings from separate namespaces. > > > It is easy to implement it for "private purposes" (i.e. > > disregarding possible attacks with jailing processes). The real work is > > making the whole business safe. > > I agree. > > Is there any project ongoing for this sysvipc issue? > If any, what is needed to be done? > I am unaware of any work being done in the area. I stated what needs to be done in my first e-mail. -- Mateusz Guzik From owner-freebsd-jail@FreeBSD.ORG Fri Jun 12 01:17:54 2015 Return-Path: Delivered-To: freebsd-jail@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E03513BF; Fri, 12 Jun 2015 01:17:54 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from vsmtp06.dti.ne.jp (vsmtp06.dti.ne.jp [202.216.231.141]) by mx1.freebsd.org (Postfix) with ESMTP id 83EAF17E0; Fri, 12 Jun 2015 01:17:54 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from mail.dream.jp (webmail02.ga.dti.ne.jp [202.216.229.153]) by vsmtp06.dti.ne.jp (3.11v) with ESMTP AUTH id t5C1Hkdb009515; Fri, 12 Jun 2015 10:17:47 +0900 (JST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_63617d2f0e214e52d0427b5986ad3c29" Date: Fri, 12 Jun 2015 10:17:46 +0900 From: To: , Subject: How to implement jail-aware SysV IPC (with my nasty patch) Message-ID: X-Sender: kikuchan@uranus.dti.ne.jp User-Agent: DTI MyMail/0.3-trunk X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 01:17:55 -0000 --=_63617d2f0e214e52d0427b5986ad3c29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-2022-jp Hello, I'm (still) trying to figure out how jail-aware SysV IPC mechanism should be. I want to run PostgreSQL in each jail without changing UID for each jail. If you don't change UID on each jail, it doesn't work due to IPC objects conflict between jails. See also; https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 http://www.freebsddiary.org/jail-multiple.php https://wiki.freebsd.org/Jails https://forums.freebsd.org/threads/postgresql-in-jail.51528/ There is a patch for 4.7-STABLE on bugzilla (see above) to solve the problem by completely separating namespace for each jail in kernel, but I couldn't find any (other) implementation that works on recent FreeBSD. I've also tried to re-write the patch for recent FreeBSD, but I couldn't make it properly due to my limited kernel knowledge ;( Anyway, I created (and update) a patch to trying to solve the problem by simply separating IPC key_t space for each jail. The attached patch can be applied to 10-STABLE (or CURRENT?). After the patch is applied; - IPC objects created on parent jail, are invisible to children. - IPC objects created on neighbor jail, are also invisible each other. - IPC objects craeted on child jail, are VISIBLE from parent. - IPC key_t spaces are separated between jails. If you see the key_t named object from parent, it's shown as IPC_PRIVATE. I choose this design of feature, however, I'm not sure this is the right design for jail-aware IPC. If you prefer the completely separated namespace approach, it's ok. I want to focus on how the IPC mechanism dealing with hierarchical jail system. So I need more feedbacks. Could you help me please? You can dig and play with ipcs(1)/ipcrm(1) to see what happend on each jail. Thanks. -- Kikuchan --=_63617d2f0e214e52d0427b5986ad3c29 Content-Transfer-Encoding: base64 Content-Type: text/x-diff; name=jailed-sysvipc-for-stable10-again.patch; charset=UTF-8 Content-Disposition: attachment; filename=jailed-sysvipc-for-stable10-again.patch ZGlmZiAtLWdpdCBhL3N5cy9rZXJuL2tlcm5famFpbC5jIGIvc3lzL2tlcm4va2Vybl9qYWlsLmMK aW5kZXggZTljNzFjYS4uY2Y2MzE5NiAxMDA2NDQKLS0tIGEvc3lzL2tlcm4va2Vybl9qYWlsLmMK KysrIGIvc3lzL2tlcm4va2Vybl9qYWlsLmMKQEAgLTYwLDYgKzYwLDcgQEAgX19GQlNESUQoIiRG cmVlQlNEJCIpOwogI2luY2x1ZGUgPHN5cy9zeXNjYWxsc3Vici5oPgogI2luY2x1ZGUgPHN5cy9z eXNjdGwuaD4KICNpbmNsdWRlIDxzeXMvdm5vZGUuaD4KKyNpbmNsdWRlIDxzeXMvaXBjLmg+CiAK ICNpbmNsdWRlIDxuZXQvaWYuaD4KICNpbmNsdWRlIDxuZXQvdm5ldC5oPgpAQCAtMjMzMCw2ICsy MzMxLDkgQEAgcHJpc29uX3JlbW92ZV9vbmUoc3RydWN0IHByaXNvbiAqcHIpCiAJCXByLT5wcl9m bGFncyAmPSB+UFJfUEVSU0lTVDsKIAl9CiAKKwkvKiBTeXNWIElQQyBjbGVhbnVwIGZvciB0aGUg cHJpc29uICovCisJaXBjX2NsZWFudXBfZm9yX3ByaXNvbihwcik7CisKIAkvKgogCSAqIGphaWxf cmVtb3ZlIGFkZGVkIGEgcmVmZXJlbmNlLiAgSWYgdGhhdCdzIHRoZSBvbmx5IG9uZSwgcmVtb3Zl CiAJICogdGhlIHByaXNvbiBub3cuCmRpZmYgLS1naXQgYS9zeXMva2Vybi9zeXN2X2lwYy5jIGIv c3lzL2tlcm4vc3lzdl9pcGMuYwppbmRleCBlNDAyY2I1Li45OTg1Yjg3IDEwMDY0NAotLS0gYS9z eXMva2Vybi9zeXN2X2lwYy5jCisrKyBiL3N5cy9rZXJuL3N5c3ZfaXBjLmMKQEAgLTQ3LDkgKzQ3 LDEzIEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxzeXMvcHJpdi5oPgogI2lu Y2x1ZGUgPHN5cy9wcm9jLmg+CiAjaW5jbHVkZSA8c3lzL3VjcmVkLmg+CisjaW5jbHVkZSA8c3lz L2phaWwuaD4KIAogdm9pZCAoKnNobWZvcmtfaG9vaykoc3RydWN0IHByb2MgKiwgc3RydWN0IHBy b2MgKikgPSBOVUxMOwogdm9pZCAoKnNobWV4aXRfaG9vaykoc3RydWN0IHZtc3BhY2UgKikgPSBO VUxMOwordm9pZCAoKnN5c3ZzaG1fY2xlYW51cF9mb3JfcHJpc29uX2hvb2spKHN0cnVjdCBwcmlz b24gKikgPSBOVUxMOwordm9pZCAoKnN5c3Ztc2dfY2xlYW51cF9mb3JfcHJpc29uX2hvb2spKHN0 cnVjdCBwcmlzb24gKikgPSBOVUxMOwordm9pZCAoKnN5c3ZzZW1fY2xlYW51cF9mb3JfcHJpc29u X2hvb2spKHN0cnVjdCBwcmlzb24gKikgPSBOVUxMOwogCiAvKiBjYWxsZWQgZnJvbSBrZXJuX2Zv cmsuYyAqLwogdm9pZApAQCAtNzIsNiArNzYsMTkgQEAgc2htZXhpdChzdHJ1Y3Qgdm1zcGFjZSAq dm0pCiAJcmV0dXJuOwogfQogCisvKiBjYWxsZWQgZnJvbSBrZXJuX2phaWwuYyAqLwordm9pZAor aXBjX2NsZWFudXBfZm9yX3ByaXNvbihzdHJ1Y3QgcHJpc29uICpwcikKK3sKKworCWlmIChzeXN2 c2htX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rICE9IE5VTEwpCisJCXN5c3ZzaG1fY2xlYW51cF9m b3JfcHJpc29uX2hvb2socHIpOworCWlmIChzeXN2bXNnX2NsZWFudXBfZm9yX3ByaXNvbl9ob29r ICE9IE5VTEwpCisJCXN5c3Ztc2dfY2xlYW51cF9mb3JfcHJpc29uX2hvb2socHIpOworCWlmIChz eXN2c2VtX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rICE9IE5VTEwpCisJCXN5c3ZzZW1fY2xlYW51 cF9mb3JfcHJpc29uX2hvb2socHIpOworfQorCiAvKgogICogQ2hlY2sgZm9yIElQQyBwZXJtaXNz aW9uLgogICoKZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3N5c3ZfbXNnLmMgYi9zeXMva2Vybi9zeXN2 X21zZy5jCmluZGV4IGQ1OGNiN2UuLjY4Nzc1YTYgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3N5c3Zf bXNnLmMKKysrIGIvc3lzL2tlcm4vc3lzdl9tc2cuYwpAQCAtNjgsNiArNjgsNyBAQCBfX0ZCU0RJ RCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8c3lzL3N5c2NhbGxzdWJyLmg+CiAjaW5jbHVkZSA8 c3lzL3N5c2VudC5oPgogI2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4KKyNpbmNsdWRlIDxzeXMvc2J1 Zi5oPgogI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KICNpbmNsdWRlIDxzeXMvamFpbC5oPgogCkBA IC04MCw2ICs4MSw5IEBAIHN0YXRpYyBNQUxMT0NfREVGSU5FKE1fTVNHLCAibXNnIiwgIlNWSUQg Y29tcGF0aWJsZSBtZXNzYWdlIHF1ZXVlcyIpOwogc3RhdGljIGludCBtc2dpbml0KHZvaWQpOwog c3RhdGljIGludCBtc2d1bmxvYWQodm9pZCk7CiBzdGF0aWMgaW50IHN5c3Ztc2dfbW9kbG9hZChz dHJ1Y3QgbW9kdWxlICosIGludCwgdm9pZCAqKTsKK3N0YXRpYyBpbnQgY3JfY2Fuc2VlX21zcShz dHJ1Y3QgdWNyZWQgKiwgc3RydWN0IG1zcWlkX2tlcm5lbCAqKTsKK3N0YXRpYyB2b2lkIG1zcV9y ZW1vdmUoc3RydWN0IG1zcWlkX2tlcm5lbCAqKTsKK3N0YXRpYyB2b2lkIHN5c3Ztc2dfY2xlYW51 cF9mb3JfcHJpc29uX215aG9vayhzdHJ1Y3QgcHJpc29uICopOwogCiAKICNpZmRlZiBNU0dfREVC VUcKQEAgLTI1Nyw2ICsyNjEsNyBAQCBtc2dpbml0KCkKICNlbmRpZgogCX0KIAltdHhfaW5pdCgm bXNxX210eCwgIm1zcSIsIE5VTEwsIE1UWF9ERUYpOworCXN5c3Ztc2dfY2xlYW51cF9mb3JfcHJp c29uX2hvb2sgPSAmc3lzdm1zZ19jbGVhbnVwX2Zvcl9wcmlzb25fbXlob29rOwogCiAJZXJyb3Ig PSBzeXNjYWxsX2hlbHBlcl9yZWdpc3Rlcihtc2dfc3lzY2FsbHMpOwogCWlmIChlcnJvciAhPSAw KQpAQCAtMjgyLDYgKzI4Nyw3IEBAIG1zZ3VubG9hZCgpCiAjaWZkZWYgQ09NUEFUX0ZSRUVCU0Qz MgogCXN5c2NhbGwzMl9oZWxwZXJfdW5yZWdpc3Rlcihtc2czMl9zeXNjYWxscyk7CiAjZW5kaWYK KwlzeXN2bXNnX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rID0gTlVMTDsKIAogCWZvciAobXNxaWQg PSAwOyBtc3FpZCA8IG1zZ2luZm8ubXNnbW5pOyBtc3FpZCsrKSB7CiAJCS8qCkBAIC0zNzIsNiAr Mzc4LDY5IEBAIG1zZ19mcmVlaGRyKG1zZ2hkcikKICNlbmRpZgogfQogCitzdGF0aWMgaW50Citj cl9jYW5zZWVfbXNxKHN0cnVjdCB1Y3JlZCAqY3JlZCwgc3RydWN0IG1zcWlkX2tlcm5lbCAqbXNx a3B0cikKK3sKKworCWlmIChtc3FrcHRyLT5jcmVkID09IE5VTEwgfHwgcHJpc29uX2NoZWNrKGNy ZWQsIG1zcWtwdHItPmNyZWQpKQorCQlyZXR1cm4gKEVJTlZBTCk7CisJcmV0dXJuICgwKTsKK30K Kworc3RhdGljIHZvaWQKK21zcV9yZW1vdmUoc3RydWN0IG1zcWlkX2tlcm5lbCAqbXNxa3B0cikK K3sKKwlzdHJ1Y3QgbXNnICptc2doZHI7CisKKwlyYWNjdF9zdWJfY3JlZChtc3FrcHRyLT5jcmVk LCBSQUNDVF9OTVNHUSwgMSk7CisJcmFjY3Rfc3ViX2NyZWQobXNxa3B0ci0+Y3JlZCwgUkFDQ1Rf TVNHUVFVRVVFRCwgbXNxa3B0ci0+dS5tc2dfcW51bSk7CisJcmFjY3Rfc3ViX2NyZWQobXNxa3B0 ci0+Y3JlZCwgUkFDQ1RfTVNHUVNJWkUsIG1zcWtwdHItPnUubXNnX2NieXRlcyk7CisJY3JmcmVl KG1zcWtwdHItPmNyZWQpOworCW1zcWtwdHItPmNyZWQgPSBOVUxMOworCisJLyogRnJlZSB0aGUg bWVzc2FnZSBoZWFkZXJzICovCisJbXNnaGRyID0gbXNxa3B0ci0+dS5tc2dfZmlyc3Q7CisJd2hp bGUgKG1zZ2hkciAhPSBOVUxMKSB7CisJCXN0cnVjdCBtc2cgKm1zZ2hkcl90bXA7CisKKwkJLyog RnJlZSB0aGUgc2VnbWVudHMgb2YgZWFjaCBtZXNzYWdlICovCisJCW1zcWtwdHItPnUubXNnX2Ni eXRlcyAtPSBtc2doZHItPm1zZ190czsKKwkJbXNxa3B0ci0+dS5tc2dfcW51bS0tOworCQltc2do ZHJfdG1wID0gbXNnaGRyOworCQltc2doZHIgPSBtc2doZHItPm1zZ19uZXh0OworCQltc2dfZnJl ZWhkcihtc2doZHJfdG1wKTsKKwl9CisKKwlpZiAobXNxa3B0ci0+dS5tc2dfY2J5dGVzICE9IDAp CisJCXBhbmljKCJtc2dfY2J5dGVzIGlzIHNjcmV3ZWQgdXAiKTsKKwlpZiAobXNxa3B0ci0+dS5t c2dfcW51bSAhPSAwKQorCQlwYW5pYygibXNnX3FudW0gaXMgc2NyZXdlZCB1cCIpOworCisJbXNx a3B0ci0+dS5tc2dfcWJ5dGVzID0gMDsJLyogTWFyayBpdCBhcyBmcmVlICovCisKKyNpZmRlZiBN QUMKKwltYWNfc3lzdm1zZ19jbGVhbnVwKG1zcWtwdHIpOworI2VuZGlmCisKKwl3YWtldXAobXNx a3B0cik7Cit9CisKK3N0YXRpYyB2b2lkCitzeXN2bXNnX2NsZWFudXBfZm9yX3ByaXNvbl9teWhv b2soc3RydWN0IHByaXNvbiAqcHIpCit7CisJaW50IGk7CisJc3RydWN0IG1zcWlkX2tlcm5lbCAq bXNxa3B0cjsKKworCW10eF9sb2NrKCZtc3FfbXR4KTsKKwlmb3IgKGkgPSAwOyBpIDwgbXNnaW5m by5tc2dtbmk7IGkrKykgeworCQltc3FrcHRyID0gJm1zcWlkc1tpXTsKKwkJaWYgKG1zcWtwdHIt PnUubXNnX3FieXRlcyAhPSAwICYmCisJCSAgICBtc3FrcHRyLT5jcmVkICYmIG1zcWtwdHItPmNy ZWQtPmNyX3ByaXNvbiA9PSBwcikKKwkJCW1zcV9yZW1vdmUobXNxa3B0cik7CisJfQorCW10eF91 bmxvY2soJm1zcV9tdHgpOworfQorCiAjaWZuZGVmIF9TWVNfU1lTUFJPVE9fSF8KIHN0cnVjdCBt c2djdGxfYXJncyB7CiAJaW50CW1zcWlkOwpAQCAtNDMzLDYgKzUwMiw5IEBAIGtlcm5fbXNnY3Rs KHRkLCBtc3FpZCwgY21kLCBtc3FidWYpCiAJCWVycm9yID0gRUlOVkFMOwogCQlnb3RvIGRvbmUy OwogCX0KKwllcnJvciA9IGNyX2NhbnNlZV9tc3EodGQtPnRkX3VjcmVkLCBtc3FrcHRyKTsKKwlp ZiAoZXJyb3IgIT0gMCkKKwkJZ290byBkb25lMjsKICNpZmRlZiBNQUMKIAllcnJvciA9IG1hY19z eXN2bXNxX2NoZWNrX21zcWN0bCh0ZC0+dGRfdWNyZWQsIG1zcWtwdHIsIGNtZCk7CiAJaWYgKGVy cm9yICE9IDApCkBAIC00NDYsNyArNTE4LDkgQEAga2Vybl9tc2djdGwodGQsIG1zcWlkLCBjbWQs IG1zcWJ1ZikKIAogCWNhc2UgSVBDX1JNSUQ6CiAJeworI2lmZGVmIE1BQwogCQlzdHJ1Y3QgbXNn ICptc2doZHI7CisjZW5kaWYKIAkJaWYgKChlcnJvciA9IGlwY3Blcm0odGQsICZtc3FrcHRyLT51 Lm1zZ19wZXJtLCBJUENfTSkpKQogCQkJZ290byBkb25lMjsKIApAQCAtNDY4LDM3ICs1NDIsNyBA QCBrZXJuX21zZ2N0bCh0ZCwgbXNxaWQsIGNtZCwgbXNxYnVmKQogCQl9CiAjZW5kaWYKIAotCQly YWNjdF9zdWJfY3JlZChtc3FrcHRyLT5jcmVkLCBSQUNDVF9OTVNHUSwgMSk7Ci0JCXJhY2N0X3N1 Yl9jcmVkKG1zcWtwdHItPmNyZWQsIFJBQ0NUX01TR1FRVUVVRUQsIG1zcWtwdHItPnUubXNnX3Fu dW0pOwotCQlyYWNjdF9zdWJfY3JlZChtc3FrcHRyLT5jcmVkLCBSQUNDVF9NU0dRU0laRSwgbXNx a3B0ci0+dS5tc2dfY2J5dGVzKTsKLQkJY3JmcmVlKG1zcWtwdHItPmNyZWQpOwotCQltc3FrcHRy LT5jcmVkID0gTlVMTDsKLQotCQkvKiBGcmVlIHRoZSBtZXNzYWdlIGhlYWRlcnMgKi8KLQkJbXNn aGRyID0gbXNxa3B0ci0+dS5tc2dfZmlyc3Q7Ci0JCXdoaWxlIChtc2doZHIgIT0gTlVMTCkgewot CQkJc3RydWN0IG1zZyAqbXNnaGRyX3RtcDsKLQotCQkJLyogRnJlZSB0aGUgc2VnbWVudHMgb2Yg ZWFjaCBtZXNzYWdlICovCi0JCQltc3FrcHRyLT51Lm1zZ19jYnl0ZXMgLT0gbXNnaGRyLT5tc2df dHM7Ci0JCQltc3FrcHRyLT51Lm1zZ19xbnVtLS07Ci0JCQltc2doZHJfdG1wID0gbXNnaGRyOwot CQkJbXNnaGRyID0gbXNnaGRyLT5tc2dfbmV4dDsKLQkJCW1zZ19mcmVlaGRyKG1zZ2hkcl90bXAp OwotCQl9Ci0KLQkJaWYgKG1zcWtwdHItPnUubXNnX2NieXRlcyAhPSAwKQotCQkJcGFuaWMoIm1z Z19jYnl0ZXMgaXMgc2NyZXdlZCB1cCIpOwotCQlpZiAobXNxa3B0ci0+dS5tc2dfcW51bSAhPSAw KQotCQkJcGFuaWMoIm1zZ19xbnVtIGlzIHNjcmV3ZWQgdXAiKTsKLQotCQltc3FrcHRyLT51Lm1z Z19xYnl0ZXMgPSAwOwkvKiBNYXJrIGl0IGFzIGZyZWUgKi8KLQotI2lmZGVmIE1BQwotCQltYWNf c3lzdm1zcV9jbGVhbnVwKG1zcWtwdHIpOwotI2VuZGlmCi0KLQkJd2FrZXVwKG1zcWtwdHIpOwor CQltc3FfcmVtb3ZlKG1zcWtwdHIpOwogCX0KIAogCQlicmVhazsKQEAgLTU3OCw2ICs2MjIsNyBA QCBzeXNfbXNnZ2V0KHRkLCB1YXApCiAJCWZvciAobXNxaWQgPSAwOyBtc3FpZCA8IG1zZ2luZm8u bXNnbW5pOyBtc3FpZCsrKSB7CiAJCQltc3FrcHRyID0gJm1zcWlkc1ttc3FpZF07CiAJCQlpZiAo bXNxa3B0ci0+dS5tc2dfcWJ5dGVzICE9IDAgJiYKKwkJCSAgICBtc3FrcHRyLT5jcmVkICYmIG1z cWtwdHItPmNyZWQtPmNyX3ByaXNvbiA9PSBjcmVkLT5jcl9wcmlzb24gJiYKIAkJCSAgICBtc3Fr cHRyLT51Lm1zZ19wZXJtLmtleSA9PSBrZXkpCiAJCQkJYnJlYWs7CiAJCX0KQEAgLTcxOCw2ICs3 NjMsOCBAQCBrZXJuX21zZ3NuZCh0ZCwgbXNxaWQsIG1zZ3AsIG1zZ3N6LCBtc2dmbGcsIG10eXBl KQogCQlnb3RvIGRvbmUyOwogCX0KIAorCWlmICgoZXJyb3IgPSBjcl9jYW5zZWVfbXNxKHRkLT50 ZF91Y3JlZCwgbXNxa3B0cikpKQorCQlnb3RvIGRvbmUyOwogCWlmICgoZXJyb3IgPSBpcGNwZXJt KHRkLCAmbXNxa3B0ci0+dS5tc2dfcGVybSwgSVBDX1cpKSkgewogCQlEUFJJTlRGKCgicmVxdWVz dGVyIGRvZXNuJ3QgaGF2ZSB3cml0ZSBhY2Nlc3NcbiIpKTsKIAkJZ290byBkb25lMjsKQEAgLTEw ODEsNiArMTEyOCw4IEBAIGtlcm5fbXNncmN2KHRkLCBtc3FpZCwgbXNncCwgbXNnc3osIG1zZ3R5 cCwgbXNnZmxnLCBtdHlwZSkKIAkJZ290byBkb25lMjsKIAl9CiAKKwlpZiAoKGVycm9yID0gY3Jf Y2Fuc2VlX21zcSh0ZC0+dGRfdWNyZWQsIG1zcWtwdHIpKSkKKwkJZ290byBkb25lMjsKIAlpZiAo KGVycm9yID0gaXBjcGVybSh0ZCwgJm1zcWtwdHItPnUubXNnX3Blcm0sIElQQ19SKSkpIHsKIAkJ RFBSSU5URigoInJlcXVlc3RlciBkb2Vzbid0IGhhdmUgcmVhZCBhY2Nlc3NcbiIpKTsKIAkJZ290 byBkb25lMjsKQEAgLTEzMjAsOSArMTM2OSwzNyBAQCBzeXNfbXNncmN2KHRkLCB1YXApCiBzdGF0 aWMgaW50CiBzeXNjdGxfbXNxaWRzKFNZU0NUTF9IQU5ETEVSX0FSR1MpCiB7CisJaW50IGVycm9y OworCXN0cnVjdCBzYnVmIHNiOworCXN0cnVjdCBtc3FpZF9rZXJuZWwgdG1wLCBlbXB0eTsKKwlp bnQgaTsKKworCWVycm9yID0gc3lzY3RsX3dpcmVfb2xkX2J1ZmZlcihyZXEsIDApOworCWlmIChl cnJvciAhPSAwKQorCQlnb3RvIGRvbmU7CisJc2J1Zl9uZXdfZm9yX3N5c2N0bCgmc2IsIE5VTEws IHNpemVvZihzdHJ1Y3QgbXNxaWRfa2VybmVsKSAqIG1zZ2luZm8ubXNnbW5pLCByZXEpOworCisJ Ynplcm8oJmVtcHR5LCBzaXplb2YoZW1wdHkpKTsKKwlmb3IgKGkgPSAwOyBpIDwgbXNnaW5mby5t c2dtbmk7IGkrKykgeworCQlzdHJ1Y3QgbXNxaWRfa2VybmVsICptc3FrcHRyOworCisJCW1zcWtw dHIgPSAmbXNxaWRzW2ldOworCQlpZiAobXNxa3B0ci0+dS5tc2dfcWJ5dGVzID09IDAgfHwKKwkJ ICAgIGNyX2NhbnNlZV9tc3EocmVxLT50ZC0+dGRfdWNyZWQsIG1zcWtwdHIpKSB7CisJCQltc3Fr cHRyID0gJmVtcHR5OworCQl9IGVsc2UgaWYgKHJlcS0+dGQtPnRkX3VjcmVkLT5jcl9wcmlzb24g IT0gbXNxa3B0ci0+Y3JlZC0+Y3JfcHJpc29uKSB7CisJCQliY29weShtc3FrcHRyLCAmdG1wLCBz aXplb2YodG1wKSk7CisJCQltc3FrcHRyID0gJnRtcDsKKwkJCW1zcWtwdHItPnUubXNnX3Blcm0u a2V5ID0gSVBDX1BSSVZBVEU7CisJCX0KIAotCXJldHVybiAoU1lTQ1RMX09VVChyZXEsIG1zcWlk cywKLQkgICAgc2l6ZW9mKHN0cnVjdCBtc3FpZF9rZXJuZWwpICogbXNnaW5mby5tc2dtbmkpKTsK KwkJc2J1Zl9iY2F0KCZzYiwgbXNxa3B0ciwgc2l6ZW9mKCptc3FrcHRyKSk7CisJfQorCWVycm9y ID0gc2J1Zl9maW5pc2goJnNiKTsKKwlzYnVmX2RlbGV0ZSgmc2IpOworCitkb25lOgorCXJldHVy biAoZXJyb3IpOwogfQogCiBTWVNDVExfSU5UKF9rZXJuX2lwYywgT0lEX0FVVE8sIG1zZ21heCwg Q1RMRkxBR19SRCwgJm1zZ2luZm8ubXNnbWF4LCAwLApkaWZmIC0tZ2l0IGEvc3lzL2tlcm4vc3lz dl9zZW0uYyBiL3N5cy9rZXJuL3N5c3Zfc2VtLmMKaW5kZXggZjlmZjIxNy4uNWI5ZTFjYSAxMDA2 NDQKLS0tIGEvc3lzL2tlcm4vc3lzdl9zZW0uYworKysgYi9zeXMva2Vybi9zeXN2X3NlbS5jCkBA IC01Nyw2ICs1Nyw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxzeXMvc3lz Y2FsbHN1YnIuaD4KICNpbmNsdWRlIDxzeXMvc3lzZW50Lmg+CiAjaW5jbHVkZSA8c3lzL3N5c2N0 bC5oPgorI2luY2x1ZGUgPHN5cy9zYnVmLmg+CiAjaW5jbHVkZSA8c3lzL3Vpby5oPgogI2luY2x1 ZGUgPHN5cy9tYWxsb2MuaD4KICNpbmNsdWRlIDxzeXMvamFpbC5oPgpAQCAtNzksNiArODAsOSBA QCBzdGF0aWMgaW50IHNlbXVubG9hZCh2b2lkKTsKIHN0YXRpYyB2b2lkIHNlbWV4aXRfbXlob29r KHZvaWQgKmFyZywgc3RydWN0IHByb2MgKnApOwogc3RhdGljIGludCBzeXNjdGxfc2VtYShTWVND VExfSEFORExFUl9BUkdTKTsKIHN0YXRpYyBpbnQgc2VtdmFsaWQoaW50IHNlbWlkLCBzdHJ1Y3Qg c2VtaWRfa2VybmVsICpzZW1ha3B0cik7CitzdGF0aWMgaW50IGNyX2NhbnNlZV9zZW0oc3RydWN0 IHVjcmVkICpjcmVkLCBzdHJ1Y3Qgc2VtaWRfa2VybmVsICpzZW1ha3B0cik7CitzdGF0aWMgdm9p ZCBzZW1fcmVtb3ZlKGludCBzZW1pZHgsIHN0cnVjdCB1Y3JlZCAqY3JlZCk7CitzdGF0aWMgdm9p ZCBzeXN2c2VtX2NsZWFudXBfZm9yX3ByaXNvbl9teWhvb2soc3RydWN0IHByaXNvbiAqcHIpOwog CiAjaWZuZGVmIF9TWVNfU1lTUFJPVE9fSF8KIHN0cnVjdCBfX3NlbWN0bF9hcmdzOwpAQCAtMjg3 LDYgKzI5MSw3IEBAIHNlbWluaXQodm9pZCkKIAltdHhfaW5pdCgmc2VtX3VuZG9fbXR4LCAic2Vt dSIsIE5VTEwsIE1UWF9ERUYpOwogCXNlbWV4aXRfdGFnID0gRVZFTlRIQU5ETEVSX1JFR0lTVEVS KHByb2Nlc3NfZXhpdCwgc2VtZXhpdF9teWhvb2ssIE5VTEwsCiAJICAgIEVWRU5USEFORExFUl9Q UklfQU5ZKTsKKwlzeXN2c2VtX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rID0gJnN5c3ZzZW1fY2xl YW51cF9mb3JfcHJpc29uX215aG9vazsKIAogCWVycm9yID0gc3lzY2FsbF9oZWxwZXJfcmVnaXN0 ZXIoc2VtX3N5c2NhbGxzKTsKIAlpZiAoZXJyb3IgIT0gMCkKQEAgLTMxMyw2ICszMTgsNyBAQCBz ZW11bmxvYWQodm9pZCkKICNlbmRpZgogCXN5c2NhbGxfaGVscGVyX3VucmVnaXN0ZXIoc2VtX3N5 c2NhbGxzKTsKIAlFVkVOVEhBTkRMRVJfREVSRUdJU1RFUihwcm9jZXNzX2V4aXQsIHNlbWV4aXRf dGFnKTsKKwlzeXN2c2VtX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rID0gTlVMTDsKICNpZmRlZiBN QUMKIAlmb3IgKGkgPSAwOyBpIDwgc2VtaW5mby5zZW1tbmk7IGkrKykKIAkJbWFjX3N5c3ZzZW1f ZGVzdHJveSgmc2VtYVtpXSk7CkBAIC01MDYsNiArNTEyLDcwIEBAIHNlbXZhbGlkKGludCBzZW1p ZCwgc3RydWN0IHNlbWlkX2tlcm5lbCAqc2VtYWtwdHIpCiAJICAgIHNlbWFrcHRyLT51LnNlbV9w ZXJtLnNlcSAhPSBJUENJRF9UT19TRVEoc2VtaWQpID8gRUlOVkFMIDogMCk7CiB9CiAKK3N0YXRp YyBpbnQKK2NyX2NhbnNlZV9zZW0oc3RydWN0IHVjcmVkICpjcmVkLCBzdHJ1Y3Qgc2VtaWRfa2Vy bmVsICpzZW1ha3B0cikKK3sKKworCWlmIChzZW1ha3B0ci0+Y3JlZCA9PSBOVUxMIHx8IHByaXNv bl9jaGVjayhjcmVkLCBzZW1ha3B0ci0+Y3JlZCkpCisJCXJldHVybiAoRUlOVkFMKTsKKwlyZXR1 cm4gKDApOworfQorCitzdGF0aWMgdm9pZAorc2VtX3JlbW92ZShpbnQgc2VtaWR4LCBzdHJ1Y3Qg dWNyZWQgKmNyZWQpCit7CisJaW50IGk7CisJc3RydWN0IHNlbWlkX2tlcm5lbCAqc2VtYWtwdHI7 CisKKwlLQVNTRVJUKHNlbWlkeCA+PSAwICYmIHNlbWlkeCA8IHNlbWluZm8uc2VtbW5pLCAoInNl bWlkeCBvdXQgb2YgYm91bmRzIikpOworCXNlbWFrcHRyID0gJnNlbWFbc2VtaWR4XTsKKwlzZW1h a3B0ci0+dS5zZW1fcGVybS5jdWlkID0gY3JlZCA/IGNyZWQtPmNyX3VpZCA6IDA7CisJc2VtYWtw dHItPnUuc2VtX3Blcm0udWlkID0gY3JlZCA/IGNyZWQtPmNyX3VpZCA6IDA7CisJc2VtYWtwdHIt PnUuc2VtX3Blcm0ubW9kZSA9IDA7CisJcmFjY3Rfc3ViX2NyZWQoc2VtYWtwdHItPmNyZWQsIFJB Q0NUX05TRU0sIHNlbWFrcHRyLT51LnNlbV9uc2Vtcyk7CisJY3JmcmVlKHNlbWFrcHRyLT5jcmVk KTsKKwlzZW1ha3B0ci0+Y3JlZCA9IE5VTEw7CisJU0VNVU5ET19MT0NLKCk7CisJc2VtdW5kb19j bGVhcihzZW1pZHgsIC0xKTsKKwlTRU1VTkRPX1VOTE9DSygpOworI2lmZGVmIE1BQworCW1hY19z eXN2c2VtX2NsZWFudXAoc2VtYWtwdHIpOworI2VuZGlmCisJd2FrZXVwKHNlbWFrcHRyKTsKKwlm b3IgKGkgPSAwOyBpIDwgc2VtaW5mby5zZW1tbmk7IGkrKykgeworCQlpZiAoKHNlbWFbaV0udS5z ZW1fcGVybS5tb2RlICYgU0VNX0FMTE9DKSAmJgorCQkgICAgc2VtYVtpXS51LnNlbV9iYXNlID4g c2VtYWtwdHItPnUuc2VtX2Jhc2UpCisJCQltdHhfbG9ja19mbGFncygmc2VtYV9tdHhbaV0sIExP UF9EVVBPSyk7CisJfQorCWZvciAoaSA9IHNlbWFrcHRyLT51LnNlbV9iYXNlIC0gc2VtOyBpIDwg c2VtdG90OyBpKyspCisJCXNlbVtpXSA9IHNlbVtpICsgc2VtYWtwdHItPnUuc2VtX25zZW1zXTsK Kwlmb3IgKGkgPSAwOyBpIDwgc2VtaW5mby5zZW1tbmk7IGkrKykgeworCQlpZiAoKHNlbWFbaV0u dS5zZW1fcGVybS5tb2RlICYgU0VNX0FMTE9DKSAmJgorCQkgICAgc2VtYVtpXS51LnNlbV9iYXNl ID4gc2VtYWtwdHItPnUuc2VtX2Jhc2UpIHsKKwkJCXNlbWFbaV0udS5zZW1fYmFzZSAtPSBzZW1h a3B0ci0+dS5zZW1fbnNlbXM7CisJCQltdHhfdW5sb2NrKCZzZW1hX210eFtpXSk7CisJCX0KKwl9 CisJc2VtdG90IC09IHNlbWFrcHRyLT51LnNlbV9uc2VtczsKK30KKworc3RhdGljIHZvaWQKK3N5 c3ZzZW1fY2xlYW51cF9mb3JfcHJpc29uX215aG9vayhzdHJ1Y3QgcHJpc29uICpwcikKK3sKKwlp bnQgaTsKKworCW10eF9sb2NrKCZzZW1fbXR4KTsKKwlmb3IgKGkgPSAwOyBpIDwgc2VtaW5mby5z ZW1tbmk7IGkrKykgeworCQlpZiAoKHNlbWFbaV0udS5zZW1fcGVybS5tb2RlICYgU0VNX0FMTE9D KSAmJgorCQkgICAgc2VtYVtpXS5jcmVkICYmIHNlbWFbaV0uY3JlZC0+Y3JfcHJpc29uID09IHBy KSB7CisJCQltdHhfbG9jaygmc2VtYV9tdHhbaV0pOworCQkJc2VtX3JlbW92ZShpLCBOVUxMKTsK KwkJCW10eF91bmxvY2soJnNlbWFfbXR4W2ldKTsKKwkJfQorCX0KKwltdHhfdW5sb2NrKCZzZW1f bXR4KTsKK30KKwogLyoKICAqIE5vdGUgdGhhdCB0aGUgdXNlci1tb2RlIGhhbGYgb2YgdGhpcyBw YXNzZXMgYSB1bmlvbiwgbm90IGEgcG9pbnRlci4KICAqLwpAQCAtNjEwLDYgKzY4MCw4IEBAIGtl cm5fc2VtY3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgc2VtaWQsIGludCBzZW1udW0sIGludCBj bWQsCiAJCQllcnJvciA9IEVJTlZBTDsKIAkJCWdvdG8gZG9uZTI7CiAJCX0KKwkJaWYgKChlcnJv ciA9IGNyX2NhbnNlZV9zZW0odGQtPnRkX3VjcmVkLCBzZW1ha3B0cikpICE9IDApCisJCQlnb3Rv IGRvbmUyOwogCQlpZiAoKGVycm9yID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRyLT51LnNlbV9wZXJt LCBJUENfUikpKQogCQkJZ290byBkb25lMjsKICNpZmRlZiBNQUMKQEAgLTYzMiw2ICs3MDQsNyBA QCBrZXJuX3NlbWN0bChzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHNlbWlkLCBpbnQgc2VtbnVtLCBp bnQgY21kLAogCWlmIChjbWQgPT0gSVBDX1JNSUQpCiAJCW10eF9sb2NrKCZzZW1fbXR4KTsKIAlt dHhfbG9jayhzZW1hX210eHApOworCiAjaWZkZWYgTUFDCiAJZXJyb3IgPSBtYWNfc3lzdnNlbV9j aGVja19zZW1jdGwoY3JlZCwgc2VtYWtwdHIsIGNtZCk7CiAJaWYgKGVycm9yICE9IDApCkBAIC02 NDUsNDEgKzcxOCwxOCBAQCBrZXJuX3NlbWN0bChzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHNlbWlk LCBpbnQgc2VtbnVtLCBpbnQgY21kLAogCWNhc2UgSVBDX1JNSUQ6CiAJCWlmICgoZXJyb3IgPSBz ZW12YWxpZChzZW1pZCwgc2VtYWtwdHIpKSAhPSAwKQogCQkJZ290byBkb25lMjsKKwkJaWYgKChl cnJvciA9IGNyX2NhbnNlZV9zZW0odGQtPnRkX3VjcmVkLCBzZW1ha3B0cikpICE9IDApCisJCQln b3RvIGRvbmUyOwogCQlpZiAoKGVycm9yID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRyLT51LnNlbV9w ZXJtLCBJUENfTSkpKQogCQkJZ290byBkb25lMjsKLQkJc2VtYWtwdHItPnUuc2VtX3Blcm0uY3Vp ZCA9IGNyZWQtPmNyX3VpZDsKLQkJc2VtYWtwdHItPnUuc2VtX3Blcm0udWlkID0gY3JlZC0+Y3Jf dWlkOwotCQlzZW1ha3B0ci0+dS5zZW1fcGVybS5tb2RlID0gMDsKLQkJcmFjY3Rfc3ViX2NyZWQo c2VtYWtwdHItPmNyZWQsIFJBQ0NUX05TRU0sIHNlbWFrcHRyLT51LnNlbV9uc2Vtcyk7Ci0JCWNy ZnJlZShzZW1ha3B0ci0+Y3JlZCk7Ci0JCXNlbWFrcHRyLT5jcmVkID0gTlVMTDsKLQkJU0VNVU5E T19MT0NLKCk7Ci0JCXNlbXVuZG9fY2xlYXIoc2VtaWR4LCAtMSk7Ci0JCVNFTVVORE9fVU5MT0NL KCk7Ci0jaWZkZWYgTUFDCi0JCW1hY19zeXN2c2VtX2NsZWFudXAoc2VtYWtwdHIpOwotI2VuZGlm Ci0JCXdha2V1cChzZW1ha3B0cik7Ci0JCWZvciAoaSA9IDA7IGkgPCBzZW1pbmZvLnNlbW1uaTsg aSsrKSB7Ci0JCQlpZiAoKHNlbWFbaV0udS5zZW1fcGVybS5tb2RlICYgU0VNX0FMTE9DKSAmJgot CQkJICAgIHNlbWFbaV0udS5zZW1fYmFzZSA+IHNlbWFrcHRyLT51LnNlbV9iYXNlKQotCQkJCW10 eF9sb2NrX2ZsYWdzKCZzZW1hX210eFtpXSwgTE9QX0RVUE9LKTsKLQkJfQotCQlmb3IgKGkgPSBz ZW1ha3B0ci0+dS5zZW1fYmFzZSAtIHNlbTsgaSA8IHNlbXRvdDsgaSsrKQotCQkJc2VtW2ldID0g c2VtW2kgKyBzZW1ha3B0ci0+dS5zZW1fbnNlbXNdOwotCQlmb3IgKGkgPSAwOyBpIDwgc2VtaW5m by5zZW1tbmk7IGkrKykgewotCQkJaWYgKChzZW1hW2ldLnUuc2VtX3Blcm0ubW9kZSAmIFNFTV9B TExPQykgJiYKLQkJCSAgICBzZW1hW2ldLnUuc2VtX2Jhc2UgPiBzZW1ha3B0ci0+dS5zZW1fYmFz ZSkgewotCQkJCXNlbWFbaV0udS5zZW1fYmFzZSAtPSBzZW1ha3B0ci0+dS5zZW1fbnNlbXM7Ci0J CQkJbXR4X3VubG9jaygmc2VtYV9tdHhbaV0pOwotCQkJfQotCQl9Ci0JCXNlbXRvdCAtPSBzZW1h a3B0ci0+dS5zZW1fbnNlbXM7CisJCXNlbV9yZW1vdmUoc2VtaWR4LCBjcmVkKTsKIAkJYnJlYWs7 CiAKIAljYXNlIElQQ19TRVQ6CiAJCWlmICgoZXJyb3IgPSBzZW12YWxpZChzZW1pZCwgc2VtYWtw dHIpKSAhPSAwKQogCQkJZ290byBkb25lMjsKKwkJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9zZW0o dGQtPnRkX3VjcmVkLCBzZW1ha3B0cikpICE9IDApCisJCQlnb3RvIGRvbmUyOwogCQlpZiAoKGVy cm9yID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRyLT51LnNlbV9wZXJtLCBJUENfTSkpKQogCQkJZ290 byBkb25lMjsKIAkJc2J1ZiA9IGFyZy0+YnVmOwpAQCAtNjkzLDYgKzc0Myw4IEBAIGtlcm5fc2Vt Y3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgc2VtaWQsIGludCBzZW1udW0sIGludCBjbWQsCiAJ Y2FzZSBJUENfU1RBVDoKIAkJaWYgKChlcnJvciA9IHNlbXZhbGlkKHNlbWlkLCBzZW1ha3B0cikp ICE9IDApCiAJCQlnb3RvIGRvbmUyOworCQlpZiAoKGVycm9yID0gY3JfY2Fuc2VlX3NlbSh0ZC0+ dGRfdWNyZWQsIHNlbWFrcHRyKSkgIT0gMCkKKwkJCWdvdG8gZG9uZTI7CiAJCWlmICgoZXJyb3Ig PSBpcGNwZXJtKHRkLCAmc2VtYWtwdHItPnUuc2VtX3Blcm0sIElQQ19SKSkpCiAJCQlnb3RvIGRv bmUyOwogCQliY29weSgmc2VtYWtwdHItPnUsIGFyZy0+YnVmLCBzaXplb2Yoc3RydWN0IHNlbWlk X2RzKSk7CkBAIC03MDEsNiArNzUzLDggQEAga2Vybl9zZW1jdGwoc3RydWN0IHRocmVhZCAqdGQs IGludCBzZW1pZCwgaW50IHNlbW51bSwgaW50IGNtZCwKIAljYXNlIEdFVE5DTlQ6CiAJCWlmICgo ZXJyb3IgPSBzZW12YWxpZChzZW1pZCwgc2VtYWtwdHIpKSAhPSAwKQogCQkJZ290byBkb25lMjsK KwkJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9zZW0odGQtPnRkX3VjcmVkLCBzZW1ha3B0cikpICE9 IDApCisJCQlnb3RvIGRvbmUyOwogCQlpZiAoKGVycm9yID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRy LT51LnNlbV9wZXJtLCBJUENfUikpKQogCQkJZ290byBkb25lMjsKIAkJaWYgKHNlbW51bSA8IDAg fHwgc2VtbnVtID49IHNlbWFrcHRyLT51LnNlbV9uc2VtcykgewpAQCAtNzEzLDYgKzc2Nyw4IEBA IGtlcm5fc2VtY3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgc2VtaWQsIGludCBzZW1udW0sIGlu dCBjbWQsCiAJY2FzZSBHRVRQSUQ6CiAJCWlmICgoZXJyb3IgPSBzZW12YWxpZChzZW1pZCwgc2Vt YWtwdHIpKSAhPSAwKQogCQkJZ290byBkb25lMjsKKwkJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9z ZW0odGQtPnRkX3VjcmVkLCBzZW1ha3B0cikpICE9IDApCisJCQlnb3RvIGRvbmUyOwogCQlpZiAo KGVycm9yID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRyLT51LnNlbV9wZXJtLCBJUENfUikpKQogCQkJ Z290byBkb25lMjsKIAkJaWYgKHNlbW51bSA8IDAgfHwgc2VtbnVtID49IHNlbWFrcHRyLT51LnNl bV9uc2VtcykgewpAQCAtNzI1LDYgKzc4MSw4IEBAIGtlcm5fc2VtY3RsKHN0cnVjdCB0aHJlYWQg KnRkLCBpbnQgc2VtaWQsIGludCBzZW1udW0sIGludCBjbWQsCiAJY2FzZSBHRVRWQUw6CiAJCWlm ICgoZXJyb3IgPSBzZW12YWxpZChzZW1pZCwgc2VtYWtwdHIpKSAhPSAwKQogCQkJZ290byBkb25l MjsKKwkJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9zZW0odGQtPnRkX3VjcmVkLCBzZW1ha3B0cikp ICE9IDApCisJCQlnb3RvIGRvbmUyOwogCQlpZiAoKGVycm9yID0gaXBjcGVybSh0ZCwgJnNlbWFr cHRyLT51LnNlbV9wZXJtLCBJUENfUikpKQogCQkJZ290byBkb25lMjsKIAkJaWYgKHNlbW51bSA8 IDAgfHwgc2VtbnVtID49IHNlbWFrcHRyLT51LnNlbV9uc2VtcykgewpAQCAtNzYyLDYgKzgyMCw4 IEBAIGtlcm5fc2VtY3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgc2VtaWQsIGludCBzZW1udW0s IGludCBjbWQsCiAJCWlmICgoZXJyb3IgPSBzZW12YWxpZChzZW1pZCwgc2VtYWtwdHIpKSAhPSAw KQogCQkJZ290byBkb25lMjsKIAkJS0FTU0VSVChjb3VudCA9PSBzZW1ha3B0ci0+dS5zZW1fbnNl bXMsICgibnNlbXMgY2hhbmdlZCIpKTsKKwkJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9zZW0odGQt PnRkX3VjcmVkLCBzZW1ha3B0cikpICE9IDApCisJCQlnb3RvIGRvbmUyOwogCQlpZiAoKGVycm9y ID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRyLT51LnNlbV9wZXJtLCBJUENfUikpKQogCQkJZ290byBk b25lMjsKIAkJZm9yIChpID0gMDsgaSA8IHNlbWFrcHRyLT51LnNlbV9uc2VtczsgaSsrKQpAQCAt Nzc0LDYgKzgzNCw4IEBAIGtlcm5fc2VtY3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgc2VtaWQs IGludCBzZW1udW0sIGludCBjbWQsCiAJY2FzZSBHRVRaQ05UOgogCQlpZiAoKGVycm9yID0gc2Vt dmFsaWQoc2VtaWQsIHNlbWFrcHRyKSkgIT0gMCkKIAkJCWdvdG8gZG9uZTI7CisJCWlmICgoZXJy b3IgPSBjcl9jYW5zZWVfc2VtKHRkLT50ZF91Y3JlZCwgc2VtYWtwdHIpKSAhPSAwKQorCQkJZ290 byBkb25lMjsKIAkJaWYgKChlcnJvciA9IGlwY3Blcm0odGQsICZzZW1ha3B0ci0+dS5zZW1fcGVy bSwgSVBDX1IpKSkKIAkJCWdvdG8gZG9uZTI7CiAJCWlmIChzZW1udW0gPCAwIHx8IHNlbW51bSA+ PSBzZW1ha3B0ci0+dS5zZW1fbnNlbXMpIHsKQEAgLTc4Niw2ICs4NDgsOCBAQCBrZXJuX3NlbWN0 bChzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHNlbWlkLCBpbnQgc2VtbnVtLCBpbnQgY21kLAogCWNh c2UgU0VUVkFMOgogCQlpZiAoKGVycm9yID0gc2VtdmFsaWQoc2VtaWQsIHNlbWFrcHRyKSkgIT0g MCkKIAkJCWdvdG8gZG9uZTI7CisJCWlmICgoZXJyb3IgPSBjcl9jYW5zZWVfc2VtKHRkLT50ZF91 Y3JlZCwgc2VtYWtwdHIpKSAhPSAwKQorCQkJZ290byBkb25lMjsKIAkJaWYgKChlcnJvciA9IGlw Y3Blcm0odGQsICZzZW1ha3B0ci0+dS5zZW1fcGVybSwgSVBDX1cpKSkKIAkJCWdvdG8gZG9uZTI7 CiAJCWlmIChzZW1udW0gPCAwIHx8IHNlbW51bSA+PSBzZW1ha3B0ci0+dS5zZW1fbnNlbXMpIHsK QEAgLTgxOCw2ICs4ODIsOCBAQCBrZXJuX3NlbWN0bChzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHNl bWlkLCBpbnQgc2VtbnVtLCBpbnQgY21kLAogCQlpZiAoKGVycm9yID0gc2VtdmFsaWQoc2VtaWQs IHNlbWFrcHRyKSkgIT0gMCkKIAkJCWdvdG8gZG9uZTI7CiAJCUtBU1NFUlQoY291bnQgPT0gc2Vt YWtwdHItPnUuc2VtX25zZW1zLCAoIm5zZW1zIGNoYW5nZWQiKSk7CisJCWlmICgoZXJyb3IgPSBj cl9jYW5zZWVfc2VtKHRkLT50ZF91Y3JlZCwgc2VtYWtwdHIpKSAhPSAwKQorCQkJZ290byBkb25l MjsKIAkJaWYgKChlcnJvciA9IGlwY3Blcm0odGQsICZzZW1ha3B0ci0+dS5zZW1fcGVybSwgSVBD X1cpKSkKIAkJCWdvdG8gZG9uZTI7CiAJCWZvciAoaSA9IDA7IGkgPCBzZW1ha3B0ci0+dS5zZW1f bnNlbXM7IGkrKykgewpAQCAtODcyLDYgKzkzOCw3IEBAIHN5c19zZW1nZXQoc3RydWN0IHRocmVh ZCAqdGQsIHN0cnVjdCBzZW1nZXRfYXJncyAqdWFwKQogCWlmIChrZXkgIT0gSVBDX1BSSVZBVEUp IHsKIAkJZm9yIChzZW1pZCA9IDA7IHNlbWlkIDwgc2VtaW5mby5zZW1tbmk7IHNlbWlkKyspIHsK IAkJCWlmICgoc2VtYVtzZW1pZF0udS5zZW1fcGVybS5tb2RlICYgU0VNX0FMTE9DKSAmJgorCQkJ ICAgIHNlbWFbc2VtaWRdLmNyZWQgJiYgc2VtYVtzZW1pZF0uY3JlZC0+Y3JfcHJpc29uID09IGNy ZWQtPmNyX3ByaXNvbiAmJgogCQkJICAgIHNlbWFbc2VtaWRdLnUuc2VtX3Blcm0ua2V5ID09IGtl eSkKIAkJCQlicmVhazsKIAkJfQpAQCAtMTA0OSw2ICsxMTE2LDggQEAgc3lzX3NlbW9wKHN0cnVj dCB0aHJlYWQgKnRkLCBzdHJ1Y3Qgc2Vtb3BfYXJncyAqdWFwKQogCQllcnJvciA9IEVJTlZBTDsK IAkJZ290byBkb25lMjsKIAl9CisJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9zZW0odGQtPnRkX3Vj cmVkLCBzZW1ha3B0cikpICE9IDApCisJCWdvdG8gZG9uZTI7CiAJLyoKIAkgKiBJbml0aWFsIHBh c3MgdGhydSBzb3BzIHRvIHNlZSB3aGF0IHBlcm1pc3Npb25zIGFyZSBuZWVkZWQuCiAJICogQWxz byBwZXJmb3JtIGFueSBjaGVja3MgdGhhdCBkb24ndCBuZWVkIHJlcGVhdGluZyBvbiBlYWNoCkBA IC0xMzcyLDkgKzE0NDEsMzcgQEAgc2VtZXhpdF9teWhvb2sodm9pZCAqYXJnLCBzdHJ1Y3QgcHJv YyAqcCkKIHN0YXRpYyBpbnQKIHN5c2N0bF9zZW1hKFNZU0NUTF9IQU5ETEVSX0FSR1MpCiB7CisJ aW50IGVycm9yOworCXN0cnVjdCBzYnVmIHNiOworCXN0cnVjdCBzZW1pZF9rZXJuZWwgdG1wLCBl bXB0eTsKKwlpbnQgaTsKKworCWVycm9yID0gc3lzY3RsX3dpcmVfb2xkX2J1ZmZlcihyZXEsIDAp OworCWlmIChlcnJvciAhPSAwKQorCQlnb3RvIGRvbmU7CisJc2J1Zl9uZXdfZm9yX3N5c2N0bCgm c2IsIE5VTEwsIHNpemVvZihzdHJ1Y3Qgc2VtaWRfa2VybmVsKSAqIHNlbWluZm8uc2VtbW5pLCBy ZXEpOwogCi0JcmV0dXJuIChTWVNDVExfT1VUKHJlcSwgc2VtYSwKLQkgICAgc2l6ZW9mKHN0cnVj dCBzZW1pZF9rZXJuZWwpICogc2VtaW5mby5zZW1tbmkpKTsKKwliemVybygmZW1wdHksIHNpemVv ZihlbXB0eSkpOworCWZvciAoaSA9IDA7IGkgPCBzZW1pbmZvLnNlbW1uaTsgaSsrKSB7CisJCXN0 cnVjdCBzZW1pZF9rZXJuZWwgKnNlbWFrcHRyOworCisJCXNlbWFrcHRyID0gJnNlbWFbaV07CisJ CWlmICgoc2VtYWtwdHItPnUuc2VtX3Blcm0ubW9kZSAmIFNFTV9BTExPQykgPT0gMCB8fAorCQkg ICAgY3JfY2Fuc2VlX3NlbShyZXEtPnRkLT50ZF91Y3JlZCwgc2VtYWtwdHIpKSB7CisJCQlzZW1h a3B0ciA9ICZlbXB0eTsKKwkJfSBlbHNlIGlmIChyZXEtPnRkLT50ZF91Y3JlZC0+Y3JfcHJpc29u ICE9IHNlbWFrcHRyLT5jcmVkLT5jcl9wcmlzb24pIHsKKwkJCWJjb3B5KHNlbWFrcHRyLCAmdG1w LCBzaXplb2YodG1wKSk7CisJCQlzZW1ha3B0ciA9ICZ0bXA7CisJCQlzZW1ha3B0ci0+dS5zZW1f cGVybS5rZXkgPSBJUENfUFJJVkFURTsKKwkJfQorCisJCXNidWZfYmNhdCgmc2IsIHNlbWFrcHRy LCBzaXplb2YoKnNlbWFrcHRyKSk7CisJfQorCWVycm9yID0gc2J1Zl9maW5pc2goJnNiKTsKKwlz YnVmX2RlbGV0ZSgmc2IpOworCitkb25lOgorCXJldHVybiAoZXJyb3IpOwogfQogCiAjaWYgZGVm aW5lZChDT01QQVRfRlJFRUJTRDQpIHx8IGRlZmluZWQoQ09NUEFUX0ZSRUVCU0Q1KSB8fCBcCmRp ZmYgLS1naXQgYS9zeXMva2Vybi9zeXN2X3NobS5jIGIvc3lzL2tlcm4vc3lzdl9zaG0uYwppbmRl eCA2NmEyYTQzLi41Mjc2MGNmIDEwMDY0NAotLS0gYS9zeXMva2Vybi9zeXN2X3NobS5jCisrKyBi L3N5cy9rZXJuL3N5c3Zfc2htLmMKQEAgLTg2LDYgKzg2LDcgQEAgX19GQlNESUQoIiRGcmVlQlNE JCIpOwogI2luY2x1ZGUgPHN5cy9zeXNlbnQuaD4KICNpbmNsdWRlIDxzeXMvc3lzcHJvdG8uaD4K ICNpbmNsdWRlIDxzeXMvamFpbC5oPgorI2luY2x1ZGUgPHN5cy9zYnVmLmg+CiAKICNpbmNsdWRl IDxzZWN1cml0eS9tYWMvbWFjX2ZyYW1ld29yay5oPgogCkBAIC0xMjAsNyArMTIxLDcgQEAgc3Ry dWN0IHNobW1hcF9zdGF0ZSB7CiB9OwogCiBzdGF0aWMgdm9pZCBzaG1fZGVhbGxvY2F0ZV9zZWdt ZW50KHN0cnVjdCBzaG1pZF9rZXJuZWwgKik7Ci1zdGF0aWMgaW50IHNobV9maW5kX3NlZ21lbnRf Ynlfa2V5KGtleV90KTsKK3N0YXRpYyBpbnQgc2htX2ZpbmRfc2VnbWVudF9ieV9rZXkoc3RydWN0 IHByaXNvbiAqLCBrZXlfdCk7CiBzdGF0aWMgc3RydWN0IHNobWlkX2tlcm5lbCAqc2htX2ZpbmRf c2VnbWVudChpbnQsIGJvb2wpOwogc3RhdGljIGludCBzaG1fZGVsZXRlX21hcHBpbmcoc3RydWN0 IHZtc3BhY2UgKnZtLCBzdHJ1Y3Qgc2htbWFwX3N0YXRlICopOwogc3RhdGljIHZvaWQgc2htcmVh bGxvYyh2b2lkKTsKQEAgLTEzMCw2ICsxMzEsOSBAQCBzdGF0aWMgaW50IHNobXVubG9hZCh2b2lk KTsKIHN0YXRpYyB2b2lkIHNobWV4aXRfbXlob29rKHN0cnVjdCB2bXNwYWNlICp2bSk7CiBzdGF0 aWMgdm9pZCBzaG1mb3JrX215aG9vayhzdHJ1Y3QgcHJvYyAqcDEsIHN0cnVjdCBwcm9jICpwMik7 CiBzdGF0aWMgaW50IHN5c2N0bF9zaG1zZWdzKFNZU0NUTF9IQU5ETEVSX0FSR1MpOworc3RhdGlj IGludCBjcl9jYW5zZWVfc2htKHN0cnVjdCB1Y3JlZCAqLCBzdHJ1Y3Qgc2htaWRfa2VybmVsICop Oworc3RhdGljIHZvaWQgc2htX3JlbW92ZShzdHJ1Y3Qgc2htaWRfa2VybmVsICosIGludCk7Citz dGF0aWMgdm9pZCBzeXN2c2htX2NsZWFudXBfZm9yX3ByaXNvbl9teWhvb2soc3RydWN0IHByaXNv biAqKTsKIAogLyoKICAqIFR1bmVhYmxlIHZhbHVlcy4KQEAgLTE4OSwxMiArMTkzLDEzIEBAIHN0 YXRpYyBzdHJ1Y3Qgc3ggc3lzdnNobXN4OwogI2RlZmluZQlTWVNWU0hNX0FTU0VSVF9MT0NLRUQo KQlzeF9hc3NlcnQoJnN5c3ZzaG1zeCwgU0FfWExPQ0tFRCkKIAogc3RhdGljIGludAotc2htX2Zp bmRfc2VnbWVudF9ieV9rZXkoa2V5X3Qga2V5KQorc2htX2ZpbmRfc2VnbWVudF9ieV9rZXkoc3Ry dWN0IHByaXNvbiAqcHIsIGtleV90IGtleSkKIHsKIAlpbnQgaTsKIAogCWZvciAoaSA9IDA7IGkg PCBzaG1hbGxvY2VkOyBpKyspCiAJCWlmICgoc2htc2Vnc1tpXS51LnNobV9wZXJtLm1vZGUgJiBT SE1TRUdfQUxMT0NBVEVEKSAmJgorCQkgICAgc2htc2Vnc1tpXS5jcmVkICYmIHNobXNlZ3NbaV0u Y3JlZC0+Y3JfcHJpc29uID09IHByICYmCiAJCSAgICBzaG1zZWdzW2ldLnUuc2htX3Blcm0ua2V5 ID09IGtleSkKIAkJCXJldHVybiAoaSk7CiAJcmV0dXJuICgtMSk7CkBAIC0yNzIsNiArMjc3LDQ1 IEBAIHNobV9kZWxldGVfbWFwcGluZyhzdHJ1Y3Qgdm1zcGFjZSAqdm0sIHN0cnVjdCBzaG1tYXBf c3RhdGUgKnNobW1hcF9zKQogfQogCiBzdGF0aWMgaW50Citjcl9jYW5zZWVfc2htKHN0cnVjdCB1 Y3JlZCAqY3JlZCwgc3RydWN0IHNobWlkX2tlcm5lbCAqc2htc2VnKQoreworCisJaWYgKHNobXNl Zy0+Y3JlZCA9PSBOVUxMIHx8IHByaXNvbl9jaGVjayhjcmVkLCBzaG1zZWctPmNyZWQpKQorCQly ZXR1cm4gKEVJTlZBTCk7CisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIHZvaWQKK3NobV9yZW1v dmUoc3RydWN0IHNobWlkX2tlcm5lbCAqc2htc2VnLCBpbnQgc2VnbnVtKQoreworCisJc2htc2Vn LT51LnNobV9wZXJtLmtleSA9IElQQ19QUklWQVRFOworCXNobXNlZy0+dS5zaG1fcGVybS5tb2Rl IHw9IFNITVNFR19SRU1PVkVEOworCWlmIChzaG1zZWctPnUuc2htX25hdHRjaCA8PSAwKSB7CisJ CXNobV9kZWFsbG9jYXRlX3NlZ21lbnQoc2htc2VnKTsKKwkJc2htX2xhc3RfZnJlZSA9IHNlZ251 bTsKKwl9Cit9CisKK3N0YXRpYyB2b2lkCitzeXN2c2htX2NsZWFudXBfZm9yX3ByaXNvbl9teWhv b2soc3RydWN0IHByaXNvbiAqcHIpCit7CisJaW50IGk7CisKKwlTWVNWU0hNX0xPQ0soKTsKKwlm b3IgKGkgPSAwOyBpIDwgc2htYWxsb2NlZDsgaSsrKSB7CisJCXN0cnVjdCBzaG1pZF9rZXJuZWwg KnNobXNlZzsKKworCQlzaG1zZWcgPSAmc2htc2Vnc1tpXTsKKwkJaWYgKChzaG1zZWctPnUuc2ht X3Blcm0ubW9kZSAmIFNITVNFR19BTExPQ0FURUQpICYmCisJCSAgICBzaG1zZWctPmNyZWQtPmNy X3ByaXNvbiA9PSBwcikgeworCQkJc2htX3JlbW92ZShzaG1zZWcsIGkpOworCQl9CisJfQorCVNZ U1ZTSE1fVU5MT0NLKCk7Cit9CisKK3N0YXRpYyBpbnQKIGtlcm5fc2htZHRfbG9ja2VkKHN0cnVj dCB0aHJlYWQgKnRkLCBjb25zdCB2b2lkICpzaG1hZGRyKQogewogCXN0cnVjdCBwcm9jICpwID0g dGQtPnRkX3Byb2M7CkBAIC0zNDgsNiArMzkyLDkgQEAga2Vybl9zaG1hdF9sb2NrZWQoc3RydWN0 IHRocmVhZCAqdGQsIGludCBzaG1pZCwgY29uc3Qgdm9pZCAqc2htYWRkciwKIAlzaG1zZWcgPSBz aG1fZmluZF9zZWdtZW50KHNobWlkLCB0cnVlKTsKIAlpZiAoc2htc2VnID09IE5VTEwpCiAJCXJl dHVybiAoRUlOVkFMKTsKKwllcnJvciA9IGNyX2NhbnNlZV9zaG0odGQtPnRkX3VjcmVkLCBzaG1z ZWcpOworCWlmIChlcnJvciAhPSAwKQorCQlyZXR1cm4gKGVycm9yKTsKIAllcnJvciA9IGlwY3Bl cm0odGQsICZzaG1zZWctPnUuc2htX3Blcm0sCiAJICAgIChzaG1mbGcgJiBTSE1fUkRPTkxZKSA/ IElQQ19SIDogSVBDX1J8SVBDX1cpOwogCWlmIChlcnJvciAhPSAwKQpAQCAtNDc3LDYgKzUyNCw5 IEBAIGtlcm5fc2htY3RsX2xvY2tlZChzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHNobWlkLCBpbnQg Y21kLCB2b2lkICpidWYsCiAJc2htc2VnID0gc2htX2ZpbmRfc2VnbWVudChzaG1pZCwgY21kICE9 IFNITV9TVEFUKTsKIAlpZiAoc2htc2VnID09IE5VTEwpCiAJCXJldHVybiAoRUlOVkFMKTsKKwll cnJvciA9IGNyX2NhbnNlZV9zaG0odGQtPnRkX3VjcmVkLCBzaG1zZWcpOworCWlmIChlcnJvciAh PSAwKQorCQlyZXR1cm4gKGVycm9yKTsKICNpZmRlZiBNQUMKIAllcnJvciA9IG1hY19zeXN2c2ht X2NoZWNrX3NobWN0bCh0ZC0+dGRfdWNyZWQsIHNobXNlZywgY21kKTsKIAlpZiAoZXJyb3IgIT0g MCkKQEAgLTUxMiwxMiArNTYyLDggQEAga2Vybl9zaG1jdGxfbG9ja2VkKHN0cnVjdCB0aHJlYWQg KnRkLCBpbnQgc2htaWQsIGludCBjbWQsIHZvaWQgKmJ1ZiwKIAkJZXJyb3IgPSBpcGNwZXJtKHRk LCAmc2htc2VnLT51LnNobV9wZXJtLCBJUENfTSk7CiAJCWlmIChlcnJvciAhPSAwKQogCQkJcmV0 dXJuIChlcnJvcik7Ci0JCXNobXNlZy0+dS5zaG1fcGVybS5rZXkgPSBJUENfUFJJVkFURTsKLQkJ c2htc2VnLT51LnNobV9wZXJtLm1vZGUgfD0gU0hNU0VHX1JFTU9WRUQ7Ci0JCWlmIChzaG1zZWct PnUuc2htX25hdHRjaCA8PSAwKSB7Ci0JCQlzaG1fZGVhbGxvY2F0ZV9zZWdtZW50KHNobXNlZyk7 Ci0JCQlzaG1fbGFzdF9mcmVlID0gSVBDSURfVE9fSVgoc2htaWQpOwotCQl9CisKKwkJc2htX3Jl bW92ZShzaG1zZWcsIElQQ0lEX1RPX0lYKHNobWlkKSk7CiAJCWJyZWFrOwogI2lmIDAKIAljYXNl IFNITV9MT0NLOgpAQCAtNzI3LDcgKzc3Myw3IEBAIHN5c19zaG1nZXQoc3RydWN0IHRocmVhZCAq dGQsIHN0cnVjdCBzaG1nZXRfYXJncyAqdWFwKQogCWlmICh1YXAtPmtleSA9PSBJUENfUFJJVkFU RSkgewogCQllcnJvciA9IHNobWdldF9hbGxvY2F0ZV9zZWdtZW50KHRkLCB1YXAsIG1vZGUpOwog CX0gZWxzZSB7Ci0JCXNlZ251bSA9IHNobV9maW5kX3NlZ21lbnRfYnlfa2V5KHVhcC0+a2V5KTsK KwkJc2VnbnVtID0gc2htX2ZpbmRfc2VnbWVudF9ieV9rZXkodGQtPnRkX3VjcmVkLT5jcl9wcmlz b24sIHVhcC0+a2V5KTsKIAkJaWYgKHNlZ251bSA+PSAwKQogCQkJZXJyb3IgPSBzaG1nZXRfZXhp c3RpbmcodGQsIHVhcCwgbW9kZSwgc2VnbnVtKTsKIAkJZWxzZSBpZiAoKHVhcC0+c2htZmxnICYg SVBDX0NSRUFUKSA9PSAwKQpAQCAtODgzLDYgKzkyOSw3IEBAIHNobWluaXQodm9pZCkKIAlzeF9p bml0KCZzeXN2c2htc3gsICJzeXN2c2htc3giKTsKIAlzaG1leGl0X2hvb2sgPSAmc2htZXhpdF9t eWhvb2s7CiAJc2htZm9ya19ob29rID0gJnNobWZvcmtfbXlob29rOworCXN5c3ZzaG1fY2xlYW51 cF9mb3JfcHJpc29uX2hvb2sgPSAmc3lzdnNobV9jbGVhbnVwX2Zvcl9wcmlzb25fbXlob29rOwog CiAJZXJyb3IgPSBzeXNjYWxsX2hlbHBlcl9yZWdpc3RlcihzaG1fc3lzY2FsbHMpOwogCWlmIChl cnJvciAhPSAwKQpAQCAtOTIzLDYgKzk3MCw3IEBAIHNobXVubG9hZCh2b2lkKQogCWZyZWUoc2ht c2VncywgTV9TSE0pOwogCXNobWV4aXRfaG9vayA9IE5VTEw7CiAJc2htZm9ya19ob29rID0gTlVM TDsKKwlzeXN2c2htX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rID0gTlVMTDsKIAlzeF9kZXN0cm95 KCZzeXN2c2htc3gpOwogCXJldHVybiAoMCk7CiB9CkBAIC05MzEsOSArOTc5LDM4IEBAIHN0YXRp YyBpbnQKIHN5c2N0bF9zaG1zZWdzKFNZU0NUTF9IQU5ETEVSX0FSR1MpCiB7CiAJaW50IGVycm9y OworCXN0cnVjdCBzYnVmIHNiOworCXN0cnVjdCBzaG1pZF9rZXJuZWwgdG1wLCBlbXB0eTsKKwlp bnQgaTsKIAogCVNZU1ZTSE1fTE9DSygpOwotCWVycm9yID0gU1lTQ1RMX09VVChyZXEsIHNobXNl Z3MsIHNobWFsbG9jZWQgKiBzaXplb2Yoc2htc2Vnc1swXSkpOworCisJZXJyb3IgPSBzeXNjdGxf d2lyZV9vbGRfYnVmZmVyKHJlcSwgMCk7CisJaWYgKGVycm9yICE9IDApCisJCWdvdG8gZG9uZTsK KwlzYnVmX25ld19mb3Jfc3lzY3RsKCZzYiwgTlVMTCwgc2htYWxsb2NlZCAqIHNpemVvZihzaG1z ZWdzWzBdKSwgcmVxKTsKKworCWJ6ZXJvKCZlbXB0eSwgc2l6ZW9mKGVtcHR5KSk7CisJZW1wdHku dS5zaG1fcGVybS5tb2RlID0gU0hNU0VHX0ZSRUU7CisJZm9yIChpID0gMDsgaSA8IHNobWFsbG9j ZWQ7IGkrKykgeworCQlzdHJ1Y3Qgc2htaWRfa2VybmVsICpzaG1zZWc7CisKKwkJc2htc2VnID0g JnNobXNlZ3NbaV07CisJCWlmICgoc2htc2VnLT51LnNobV9wZXJtLm1vZGUgJiBTSE1TRUdfQUxM T0NBVEVEKSA9PSAwIHx8CisJCSAgICBjcl9jYW5zZWVfc2htKHJlcS0+dGQtPnRkX3VjcmVkLCAm c2htc2Vnc1tpXSkpIHsKKwkJCXNobXNlZyA9ICZlbXB0eTsKKwkJfSBlbHNlIGlmIChyZXEtPnRk LT50ZF91Y3JlZC0+Y3JfcHJpc29uICE9IHNobXNlZy0+Y3JlZC0+Y3JfcHJpc29uKSB7CisJCQli Y29weShzaG1zZWcsICZ0bXAsIHNpemVvZih0bXApKTsKKwkJCXNobXNlZyA9ICZ0bXA7CisJCQlz aG1zZWctPnUuc2htX3Blcm0ua2V5ID0gSVBDX1BSSVZBVEU7CisJCX0KKworCQlzYnVmX2JjYXQo JnNiLCBzaG1zZWcsIHNpemVvZigqc2htc2VnKSk7CisJfQorCWVycm9yID0gc2J1Zl9maW5pc2go JnNiKTsKKwlzYnVmX2RlbGV0ZSgmc2IpOworCitkb25lOgogCVNZU1ZTSE1fVU5MT0NLKCk7CiAJ cmV0dXJuIChlcnJvcik7CiB9CkBAIC05NzcsNiArMTA1NCwxMSBAQCBvc2htY3RsKHN0cnVjdCB0 aHJlYWQgKnRkLCBzdHJ1Y3Qgb3NobWN0bF9hcmdzICp1YXApCiAJCVNZU1ZTSE1fVU5MT0NLKCk7 CiAJCXJldHVybiAoRUlOVkFMKTsKIAl9CisJZXJyb3IgPSBjcl9jYW5zZWVfc2htKHRkLT50ZF91 Y3JlZCwgc2htc2VnKTsKKwlpZiAoZXJyb3IgIT0gMCkgeworCQlTWVNWU0hNX1VOTE9DSygpOwor CQlyZXR1cm4gKGVycm9yKTsKKwl9CiAJZXJyb3IgPSBpcGNwZXJtKHRkLCAmc2htc2VnLT51LnNo bV9wZXJtLCBJUENfUik7CiAJaWYgKGVycm9yICE9IDApIHsKIAkJU1lTVlNITV9VTkxPQ0soKTsK ZGlmZiAtLWdpdCBhL3N5cy9zeXMvaXBjLmggYi9zeXMvc3lzL2lwYy5oCmluZGV4IGU2NDNkNDgu Ljg4YjVmMTQgMTAwNjQ0Ci0tLSBhL3N5cy9zeXMvaXBjLmgKKysrIGIvc3lzL3N5cy9pcGMuaApA QCAtMTI2LDYgKzEyNiw3IEBAIHN0cnVjdCBpcGNfcGVybSB7CiBzdHJ1Y3QgdGhyZWFkOwogc3Ry dWN0IHByb2M7CiBzdHJ1Y3Qgdm1zcGFjZTsKK3N0cnVjdCBwcmlzb247CiAKICNpZiBkZWZpbmVk KENPTVBBVF9GUkVFQlNENCkgfHwgZGVmaW5lZChDT01QQVRfRlJFRUJTRDUpIHx8IFwKICAgICBk ZWZpbmVkKENPTVBBVF9GUkVFQlNENikgfHwgZGVmaW5lZChDT01QQVRfRlJFRUJTRDcpCkBAIC0x MzMsOSArMTM0LDEzIEBAIHZvaWQJaXBjcGVybV9vbGQybmV3KHN0cnVjdCBpcGNfcGVybV9vbGQg Kiwgc3RydWN0IGlwY19wZXJtICopOwogdm9pZAlpcGNwZXJtX25ldzJvbGQoc3RydWN0IGlwY19w ZXJtICosIHN0cnVjdCBpcGNfcGVybV9vbGQgKik7CiAjZW5kaWYKIAordm9pZCBpcGNfY2xlYW51 cF9mb3JfcHJpc29uKHN0cnVjdCBwcmlzb24gKik7CiBpbnQJaXBjcGVybShzdHJ1Y3QgdGhyZWFk ICosIHN0cnVjdCBpcGNfcGVybSAqLCBpbnQpOwogZXh0ZXJuIHZvaWQgKCpzaG1mb3JrX2hvb2sp KHN0cnVjdCBwcm9jICosIHN0cnVjdCBwcm9jICopOwogZXh0ZXJuIHZvaWQgKCpzaG1leGl0X2hv b2spKHN0cnVjdCB2bXNwYWNlICopOworZXh0ZXJuIHZvaWQgKCpzeXN2c2htX2NsZWFudXBfZm9y X3ByaXNvbl9ob29rKShzdHJ1Y3QgcHJpc29uICopOworZXh0ZXJuIHZvaWQgKCpzeXN2bXNnX2Ns ZWFudXBfZm9yX3ByaXNvbl9ob29rKShzdHJ1Y3QgcHJpc29uICopOworZXh0ZXJuIHZvaWQgKCpz eXN2c2VtX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rKShzdHJ1Y3QgcHJpc29uICopOwogCiAjZWxz ZSAvKiAhIF9LRVJORUwgKi8KIAo= --=_63617d2f0e214e52d0427b5986ad3c29-- From owner-freebsd-jail@FreeBSD.ORG Fri Jun 12 01:23:19 2015 Return-Path: Delivered-To: freebsd-jail@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86F4A4F5; Fri, 12 Jun 2015 01:23:19 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 732491A13; Fri, 12 Jun 2015 01:23:19 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 64FE4341F84E; Thu, 11 Jun 2015 18:23:13 -0700 (PDT) Message-ID: <557A34DB.9070103@freebsd.org> Date: Thu, 11 Jun 2015 18:24:43 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: kikuchan@uranus.dti.ne.jp, freebsd-jail@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 01:23:19 -0000 Can a bugzilla or github request please be made for this so that it doesn't get lost? thank you, -Alfred On 6/11/15 6:17 PM, kikuchan@uranus.dti.ne.jp wrote: > Hello, > > I'm (still) trying to figure out how jail-aware SysV IPC mechanism should be. > > I want to run PostgreSQL in each jail without changing UID for each jail. > If you don't change UID on each jail, it doesn't work due to IPC objects conflict between jails. > See also; > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 > http://www.freebsddiary.org/jail-multiple.php > https://wiki.freebsd.org/Jails > https://forums.freebsd.org/threads/postgresql-in-jail.51528/ > > There is a patch for 4.7-STABLE on bugzilla (see above) to solve the problem by completely separating namespace for each jail in kernel, > but I couldn't find any (other) implementation that works on recent FreeBSD. > I've also tried to re-write the patch for recent FreeBSD, but I couldn't make it properly due to my limited kernel knowledge ;( > > Anyway, I created (and update) a patch to trying to solve the problem by simply separating IPC key_t space for each jail. > The attached patch can be applied to 10-STABLE (or CURRENT?). > > After the patch is applied; > - IPC objects created on parent jail, are invisible to children. > - IPC objects created on neighbor jail, are also invisible each other. > - IPC objects craeted on child jail, are VISIBLE from parent. > - IPC key_t spaces are separated between jails. If you see the key_t named object from parent, it's shown as IPC_PRIVATE. > > I choose this design of feature, however, I'm not sure this is the right design for jail-aware IPC. > If you prefer the completely separated namespace approach, it's ok. I want to focus on how the IPC mechanism dealing with hierarchical jail system. > > So I need more feedbacks. Could you help me please? > You can dig and play with ipcs(1)/ipcrm(1) to see what happend on each jail. > > Thanks. > > -- > Kikuchan > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-jail@FreeBSD.ORG Fri Jun 12 02:11:34 2015 Return-Path: Delivered-To: freebsd-jail@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A753636F; Fri, 12 Jun 2015 02:11:34 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from vsmtp07.dti.ne.jp (vsmtp07.dti.ne.jp [202.216.231.142]) by mx1.freebsd.org (Postfix) with ESMTP id DB0481642; Fri, 12 Jun 2015 02:11:33 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from mail.dream.jp (webmail01.ga.dti.ne.jp [202.216.229.152]) by vsmtp07.dti.ne.jp (3.11v) with ESMTP AUTH id t5C24PBc029633; Fri, 12 Jun 2015 11:04:25 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Date: Fri, 12 Jun 2015 11:04:25 +0900 From: To: Alfred Perlstein Cc: , Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) In-Reply-To: <557A34DB.9070103@freebsd.org> References: <557A34DB.9070103@freebsd.org> Message-ID: X-Sender: kikuchan@uranus.dti.ne.jp User-Agent: DTI MyMail/0.3-trunk X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 02:11:34 -0000 Thank you for your reply! Just appended, is this OK? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 On Thu, 11 Jun 2015 18:24:43 -0700, Alfred Perlstein wrote: > Can a bugzilla or github request please be made for this so that it > doesn't get lost? > > thank you, > -Alfred > > On 6/11/15 6:17 PM, kikuchan@uranus.dti.ne.jp wrote: >> Hello, >> >> I'm (still) trying to figure out how jail-aware SysV IPC mechanism should be. >> >> I want to run PostgreSQL in each jail without changing UID for each jail. >> If you don't change UID on each jail, it doesn't work due to IPC objects conflict between jails. >> See also; >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 >> http://www.freebsddiary.org/jail-multiple.php >> https://wiki.freebsd.org/Jails >> https://forums.freebsd.org/threads/postgresql-in-jail.51528/ >> >> There is a patch for 4.7-STABLE on bugzilla (see above) to solve the problem by completely separating namespace for each jail in kernel, >> but I couldn't find any (other) implementation that works on recent FreeBSD. >> I've also tried to re-write the patch for recent FreeBSD, but I couldn't make it properly due to my limited kernel knowledge ;( >> >> Anyway, I created (and update) a patch to trying to solve the problem by simply separating IPC key_t space for each jail. >> The attached patch can be applied to 10-STABLE (or CURRENT?). >> >> After the patch is applied; >> - IPC objects created on parent jail, are invisible to children. >> - IPC objects created on neighbor jail, are also invisible each other. >> - IPC objects craeted on child jail, are VISIBLE from parent. >> - IPC key_t spaces are separated between jails. If you see the key_t named object from parent, it's shown as IPC_PRIVATE. >> >> I choose this design of feature, however, I'm not sure this is the right design for jail-aware IPC. >> If you prefer the completely separated namespace approach, it's ok. I want to focus on how the IPC mechanism dealing with hierarchical jail system. >> >> So I need more feedbacks. Could you help me please? >> You can dig and play with ipcs(1)/ipcrm(1) to see what happend on each jail. >> >> Thanks. >> >> -- >> Kikuchan >> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-jail@FreeBSD.ORG Fri Jun 12 02:13:40 2015 Return-Path: Delivered-To: freebsd-jail@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2800E560; Fri, 12 Jun 2015 02:13:40 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 162B8169B; Fri, 12 Jun 2015 02:13:39 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id F29FD341F84E; Thu, 11 Jun 2015 19:13:38 -0700 (PDT) Message-ID: <557A40AE.3010804@freebsd.org> Date: Thu, 11 Jun 2015 19:15:10 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: kikuchan@uranus.dti.ne.jp CC: freebsd-jail@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) References: <557A34DB.9070103@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 02:13:40 -0000 Thank you! On 6/11/15 7:04 PM, kikuchan@uranus.dti.ne.jp wrote: > Thank you for your reply! > > Just appended, is this OK? > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 > > > On Thu, 11 Jun 2015 18:24:43 -0700, Alfred Perlstein wrote: >> Can a bugzilla or github request please be made for this so that it >> doesn't get lost? >> >> thank you, >> -Alfred >> >> On 6/11/15 6:17 PM, kikuchan@uranus.dti.ne.jp wrote: >>> Hello, >>> >>> I'm (still) trying to figure out how jail-aware SysV IPC mechanism should be. >>> >>> I want to run PostgreSQL in each jail without changing UID for each jail. >>> If you don't change UID on each jail, it doesn't work due to IPC objects conflict between jails. >>> See also; >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 >>> http://www.freebsddiary.org/jail-multiple.php >>> https://wiki.freebsd.org/Jails >>> https://forums.freebsd.org/threads/postgresql-in-jail.51528/ >>> >>> There is a patch for 4.7-STABLE on bugzilla (see above) to solve the problem by completely separating namespace for each jail in kernel, >>> but I couldn't find any (other) implementation that works on recent FreeBSD. >>> I've also tried to re-write the patch for recent FreeBSD, but I couldn't make it properly due to my limited kernel knowledge ;( >>> >>> Anyway, I created (and update) a patch to trying to solve the problem by simply separating IPC key_t space for each jail. >>> The attached patch can be applied to 10-STABLE (or CURRENT?). >>> >>> After the patch is applied; >>> - IPC objects created on parent jail, are invisible to children. >>> - IPC objects created on neighbor jail, are also invisible each other. >>> - IPC objects craeted on child jail, are VISIBLE from parent. >>> - IPC key_t spaces are separated between jails. If you see the key_t named object from parent, it's shown as IPC_PRIVATE. >>> >>> I choose this design of feature, however, I'm not sure this is the right design for jail-aware IPC. >>> If you prefer the completely separated namespace approach, it's ok. I want to focus on how the IPC mechanism dealing with hierarchical jail system. >>> >>> So I need more feedbacks. Could you help me please? >>> You can dig and play with ipcs(1)/ipcrm(1) to see what happend on each jail. >>> >>> Thanks. >>> >>> -- >>> Kikuchan >>> >>> >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-jail@FreeBSD.ORG Sat Jun 13 04:04:43 2015 Return-Path: Delivered-To: freebsd-jail@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC9A8991 for ; Sat, 13 Jun 2015 04:04:43 +0000 (UTC) (envelope-from marcus@odin.blazingdot.com) Received: from odin.blazingdot.com (odin.blazingdot.com [204.109.60.170]) by mx1.freebsd.org (Postfix) with ESMTP id 7EEFC272 for ; Sat, 13 Jun 2015 04:04:40 +0000 (UTC) (envelope-from marcus@odin.blazingdot.com) Received: by odin.blazingdot.com (Postfix, from userid 1001) id 623AE1320ED; Fri, 12 Jun 2015 23:59:21 -0400 (EDT) Date: Fri, 12 Jun 2015 23:59:21 -0400 From: Marcus Reid To: freebsd-jail@freebsd.org, freebsd-zfs@freebsd.org Subject: zfs in a jail Message-ID: <20150613035921.GA22078@blazingdot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Coffee-Level: nearly-fatal User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 04:04:43 -0000 Hi, I'm doing zfs from within a jail, and there is one thing that's giving me some trouble. First, the bits that get zfs working from inside a jail: /etc/jail.conf: allow.mount; allow.mount.zfs; enforce_statfs = 1; /etc/sysctl.conf: security.jail.mount_allowed=1 security.jail.mount_zfs_allowed=1 security.jail.enforce_statfs=1 zfs set jailed=on zroot/jails/git/git Finally, to get the dataset visible inside the jail, this is required when the jail is running: zfs jail git zroot/jails/git/git So, in jail.conf, I do a: exec.poststart = "zfs jail git zroot/jails/git/git" Problem: zfs is not visible in jail after a reboot. This problem is understood but I don't know the solution. exec.poststart is run after exec.start (the thing that runs /etc/rc in the jail), so the zfs datasets are not yet visible when /etc/rc.d/zfs runs in the jail. So, I have to log into the jail and do a 'zfs mount -a' after everything comes up. Not ideal. If there were a exec.postcreate directive in jail.conf that ran a command on the host after jail creation but before /etc/rc starts, then I could run 'zfs jail' before the jails init scripts are run. Am I going about that in the wrong way? jail.conf seems like the right place for it, because you want your storage working after a 'jail -rc git', right? Thanks, Marcus From owner-freebsd-jail@FreeBSD.ORG Sat Jun 13 07:29:52 2015 Return-Path: Delivered-To: freebsd-jail@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 998EC2A6 for ; Sat, 13 Jun 2015 07:29:52 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from vsmtp07.dti.ne.jp (vsmtp07.dti.ne.jp [202.216.231.142]) by mx1.freebsd.org (Postfix) with ESMTP id 36E8C6AE for ; Sat, 13 Jun 2015 07:29:51 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from mail.dream.jp (webmail01.ga.dti.ne.jp [202.216.229.152]) by vsmtp07.dti.ne.jp (3.11v) with ESMTP AUTH id t5D7TfaR028347; Sat, 13 Jun 2015 16:29:42 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Date: Sat, 13 Jun 2015 16:29:41 +0900 From: To: Marcus Reid Cc: , Subject: Re: zfs in a jail In-Reply-To: <20150613035921.GA22078@blazingdot.com> References: <20150613035921.GA22078@blazingdot.com> Message-ID: X-Sender: kikuchan@uranus.dti.ne.jp User-Agent: DTI MyMail/0.3-trunk X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 07:29:52 -0000 Hi, I'm doing the exec.postcreate like thing with the following way, just FYI. in /etc/jail.conf ---- exec.start="" exec.poststart="/jail/poststart.sh ${name}" ---- in /jail/poststart.sh ---- jid=`/usr/sbin/jls -j $1 jid` name="$1" # Do whatever you want to initialize the jail from host, here # Run the command in the jail /usr/sbin/jexec "${name}" /bin/sh /etc/rc ---- I hope this may help you. Regards, Kikuchan On Fri, 12 Jun 2015 23:59:21 -0400, Marcus Reid wrote: > Hi, > > I'm doing zfs from within a jail, and there is one thing that's giving > me some trouble. > > First, the bits that get zfs working from inside a jail: > > /etc/jail.conf: > allow.mount; > allow.mount.zfs; > enforce_statfs = 1; > > /etc/sysctl.conf: > security.jail.mount_allowed=1 > security.jail.mount_zfs_allowed=1 > security.jail.enforce_statfs=1 > > zfs set jailed=on zroot/jails/git/git > > Finally, to get the dataset visible inside the jail, this is required > when the jail is running: > > zfs jail git zroot/jails/git/git > > So, in jail.conf, I do a: > > exec.poststart = "zfs jail git zroot/jails/git/git" > > Problem: zfs is not visible in jail after a reboot. This problem is > understood but I don't know the solution. > > exec.poststart is run after exec.start (the thing that runs /etc/rc in > the jail), so the zfs datasets are not yet visible when /etc/rc.d/zfs > runs in the jail. So, I have to log into the jail and do a 'zfs mount > -a' after everything comes up. Not ideal. If there were a > exec.postcreate directive in jail.conf that ran a command on the host > after jail creation but before /etc/rc starts, then I could run 'zfs > jail' before the jails init scripts are run. > > Am I going about that in the wrong way? jail.conf seems like the right > place for it, because you want your storage working after a 'jail -rc > git', right? > > Thanks, > > Marcus > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org"