From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 22:20:41 2015 Return-Path: Delivered-To: freebsd-hackers@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 5648833F for ; Fri, 27 Mar 2015 22:20:41 +0000 (UTC) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (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 1A0CAFA7 for ; Fri, 27 Mar 2015 22:20:41 +0000 (UTC) Received: by obcjt1 with SMTP id jt1so82086015obc.2 for ; Fri, 27 Mar 2015 15:20:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+M104RUp5/nVxx+g5xzimIJVKe3D/vRmIDEOS6J+M4o=; b=YJvUA5aRWhKKT0ho36n43fzcEic49dqa8V5fnzjEhW9D9MwDdjQQZ09dG7EEb1VU/a +UCX2nDrYs4TkXZJvja6Zcr49f4DZeixuNyocsFAHH+IrsyOMVsaFp07+He7bcnVVucQ tma/Yq7Dw5pUUHXFOeHzPNlPRhzanhpG0okXcqzkgA30Be4OvTY7izakBZ2Kbnow7RT1 cw5krhvPvBCiCx3f27++PZ/RQfd6sD6WAIUSOFcDkh/GGPo8WuYvnGaz3AIXgeotV+H2 Q5COmZstuRgjiSQJOjlKoemOBpEnjLuVOSpqo+ZMPs8ayDM7c8wYrz1W6dBP6OyUezJV A2RA== X-Gm-Message-State: ALoCoQno3kUnG4ZcIWBTwqR3FDOAqKmuhdS17K8XQFmrdOJWrAm0aXuzgRgcZxJe9K2F/4fRXGxm MIME-Version: 1.0 X-Received: by 10.202.219.87 with SMTP id s84mr12817774oig.114.1427494839973; Fri, 27 Mar 2015 15:20:39 -0700 (PDT) Received: by 10.202.57.195 with HTTP; Fri, 27 Mar 2015 15:20:39 -0700 (PDT) In-Reply-To: References: <20150321220246.GE14650@dft-labs.eu> <20150321232622.GF14650@dft-labs.eu> <20150327194920.GB18158@dft-labs.eu> Date: Fri, 27 Mar 2015 23:20:39 +0100 Message-ID: Subject: Re: How to traverse kernel threads? From: Oliver Pinter To: Yue Chen Content-Type: text/plain; charset=UTF-8 Cc: PaX Team , Benjamin Kaduk , Mateusz Guzik , HardenedBSD Core , "freebsd-hackers@freebsd.org" 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 22:20:41 -0000 On Fri, Mar 27, 2015 at 9:55 PM, Yue Chen wrote: >> 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 (Added HardenedBSD core and PaXTeam to CC.) Until you can not fixed all of the infoleaks from kernel (try sysctl -a | grep 0x or similar command) the KASLR and other kernel address space randomization techniques are easily bypass-able... > > > > 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 > >