From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 20:55:33 2015 Return-Path: Delivered-To: freebsd-hackers@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 CF350931; Fri, 27 Mar 2015 20:55:33 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 92EEB620; Fri, 27 Mar 2015 20:55:33 +0000 (UTC) Received: by pacwz10 with SMTP id wz10so54982341pac.2; Fri, 27 Mar 2015 13:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=FWgXUXSqTWjHehonf2bhxu/hxkvIzBnssSnWWWywk1s=; b=oi2KX+Q9qA1kt/Z7mWmsJhK4RuvhW6b1pKOFIaVZsfx2/wP9MpC4ej/GdAxADw1DJ+ aALEZ68Hj655Qx2TKWbhK0g+cEyFF6zfdnywXvIP5GeMXhjvf7ds/iXplgWXZWJBZiH0 U+zb4+s4YaYmb2sKDNJJWZh5WNW22KnNcC85sJh/VwEUWrJuXQkll1w5KrVhRcdXy1rk Is2ITCzvhnoAWFGKejHGQZI7zakm78j8BcoIUIXTgcpMYPv8aZWbGEI3JHYDQXEe/Fg2 tz57UfUbYIRbBIFeq3FEzz5sZu1xXtb72kjtd7gmfqUTtHFD3FMDl9Ig0DU6fwvPVJhq Fwjw== X-Received: by 10.66.118.198 with SMTP id ko6mr39056417pab.16.1427489733103; Fri, 27 Mar 2015 13:55:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.179.203 with HTTP; Fri, 27 Mar 2015 13:55:02 -0700 (PDT) In-Reply-To: <20150327194920.GB18158@dft-labs.eu> References: <20150321220246.GE14650@dft-labs.eu> <20150321232622.GF14650@dft-labs.eu> <20150327194920.GB18158@dft-labs.eu> From: Yue Chen Date: Fri, 27 Mar 2015 16:55:02 -0400 Message-ID: Subject: Re: How to traverse kernel threads? To: Mateusz Guzik , Oliver Pinter , Benjamin Kaduk , Yue Chen , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 20:55:33 -0000 > Except it seems there routines are supposed to be only used when > execution is 'frozen' (e.g. when escaped to the debugger). It means probably we can run the code in ``smp_rendezvous()'' function, right? > Still nobody knows what you are trying to do. We are trying to enhance FreeBSD's security by randomizing kernel code basic blocks periodically at runtime, to mitigate the attacks like return-oriented programming (ROP). It is basically a stronger form of ASLR. After each randomization procedure, the function return addresses saved in the stack are the ``old'' addresses before randomization, so we need to update them to the new addresses. That's why we need to get all the stack ranges to find those addresses. Also, in kernel, we believe that not only the return addresses in stacks need to be updated, there may exist other ``old'' saved instruction (PC) addresses in memory. Like in exception handling (maybe, do not know), debugging-purpose code and restartable atomic sequences (RAS) implementation. That's why I asked how to traverse all the kernel pages and get their virtual addresses here: https://lists.freebsd.org/pipermail/freebsd-hackers/2015-March/047336.html Now we found that it seems needed to traverse the ``pv_entry'' structure for x86_64 MMU. Another problem is that we do not know if FreeBSD has any form of special encodings or offset form for 64-bit instruction addresses (e.g., saved %RIP) on X86_64, instead of hard-coded addresses. For example, using a 32-bit offset instead of the 64-bit full address; and doing what glibc does for the setjmp/longjmp jmp_buf (special encodings (PTR_MANGLE) for the saved register values). Any suggestion or correction are highly appreciated. Best, Yue On Fri, Mar 27, 2015 at 3:49 PM, Mateusz Guzik wrote: > On Fri, Mar 27, 2015 at 02:35:55PM -0400, Yue Chen wrote: > > When using the following code on kernel module loading: > > > ------------------------------------------------------------------------------------------ > > struct thread *td = kdb_thr_first(); > > td = kdb_thr_next(td); > > > ------------------------------------------------------------------------------------------ > > The kernel panics. > > > > Panics how? > > Also you can easily see these functions don't lock anything, so it would > be assumed you took appropriate locks. > > Except it seems there routines are supposed to be only used when > execution is 'frozen' (e.g. when escaped to the debugger). > > > > > And when printing all threads in proc0 (all kernel threads?): > > > ------------------------------------------------------------------------------------------ > > struct proc *p = pfind(0); > > FOREACH_THREAD_IN_PROC(p, td) { > > uprintf("td: %x\n", td); > > } > > > > proc0 is an exported symbol, no need to pfind. > > > td = curthread; > > uprintf("cur td: %x\n", td); > > > ------------------------------------------------------------------------------------------ > > The ``curthread'' (from this kernel module running the above code) is not > > in the 0 process group. > > > > There is no 'curthread from kernel module'. > > My guess is you do this work from module initializator, and in that case > curthread is the thread which loads the module, and such a thread is > definitely not linked into proc0. > > Still nobody knows what you are trying to do. > > -- > Mateusz Guzik >