From owner-soc-status@FreeBSD.ORG Sat Jul 26 21:20:17 2014 Return-Path: Delivered-To: soc-status@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0219BEE6; Sat, 26 Jul 2014 21:20:17 +0000 (UTC) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B87AC2319; Sat, 26 Jul 2014 21:20:16 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id h136so4557518oig.7 for ; Sat, 26 Jul 2014 14:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Egl54Pj+NkdLg/MJlqrYWr9rulG9PXkGswgX0ESJyT0=; b=MgV/zqBZbm6gwBXM/HXYMwQ0QxKiC08BzW5JNqmp0AyKwAdUD1HN2nelPqsP2C6rsW MnnoJDTp7kesYUm1gU0/PU3ruXjp6bP/x8JT/5F4Fp/2LSKUp9xT1H+W9EUiFwmg7dR7 QqEwzloxJgixi2A6tdbHBbSZh4zrNfmG/aWHsFTYRKOTSv3DCyzsdFvEHxF07X+SAkq5 xzK9Vtnt8e3vhfrOrU91FN9ggNOhGb0mC3QYFE4y5KocBNz6FlOR0rHkBEmvZDOxeU22 gZ/7EhLpeRlQX+jYQaicXKFd9og+91PyreVVhgZB7l7v69ugP+XaTLIv7W4ELhB3rznU khFA== MIME-Version: 1.0 X-Received: by 10.60.123.103 with SMTP id lz7mr35845868oeb.18.1406409615892; Sat, 26 Jul 2014 14:20:15 -0700 (PDT) Received: by 10.182.216.197 with HTTP; Sat, 26 Jul 2014 14:20:15 -0700 (PDT) Date: Sat, 26 Jul 2014 23:20:15 +0200 Message-ID: Subject: [intel smap, kpatch] weekly report #9 From: Oliver Pinter To: soc-status@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: gavin@freebsd.org X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 21:20:17 -0000 At the last week, I was done with most of the core functionality. The SMAP capable kernel can boot on w/ and w/o SMAP support. The XSAVEOPT related manual patching was elliminated and used the common kernel patchin framework. So what's done at this week: * working kernel patching * working module patching * working preload patching * adopted SMAP instructions to kernel patching * adopted XSAVEOPT instructions to kernel patching * tested in Qemu * tested on real hardware What's will I on next week: * optimize * fix bugs * implement other patches than same sized On 7/19/14, Oliver Pinter wrote: > Hi! > > This week I mostly implemented the kernel patching framework. It's > required to optimize a little, but mostly done. The current status can > you find both in svn or git repo. > > The current code boot tested with kernel image patching, it's works. > Next should I test kld preload patching and kldload patching, and then > adopting SMAP related instructions and xsave related codes. > > Detailed info are in wiki. > > On 7/11/14, Oliver Pinter wrote: >> Hi All! >> >> At previous week I started to design a kernel patching framework and I >> have a little holiday. >> >> At this week I mostly finished the design, and started to implement >> the selfpatching framework. >> >> Next week I plan to finish the implementation of the framework, and >> after that migrate the SMAP stuff to use them. >> >> The current status can you found on my wiki site. >> >> On 6/28/14, Oliver Pinter wrote: >>> This week I started the second phase of GSoC. In this design a >>> run-time kernel and module patching framework. This means that the >>> kernel able to dynamically change their code run-time. >>> >>> In second phase's first week I investigated where must I implement the >>> functionality and which kernel APIs should I use. >>> >>> You can found the current status in my wiki page. >>> >>> On 6/21/14, Oliver Pinter wrote: >>>> Hi! >>>> >>>> At this week i am hunting a triple fault during the boot. This caused >>>> by a compiler error, when CPUTYPE in /etc/make.conf was set to >>>> core-avx2, after removing this the first phase was done. All of my >>>> test running fine and the system are stable. Originally only amd64 >>>> implementation required, but I added to i386 too - but the later not >>>> yet tested. >>>> >>>> In next phase I design a proper way how to patch kernel and modules at >>>> boot and run-time. >>>> >>>> What's done: >>>> * SMAP for amd64 >>>> * test SMAP for amd64 >>>> * build framework >>>> * VM creation >>>> * SMAP for i386 (not tested) >>>> * some other tool, that make my life easier >>>> >>>> The current status can you find on my wiki page. >>>> >>>> On 6/15/14, Oliver Pinter wrote: >>>>> Hi all! >>>>> >>>>> In the last week I was mostly done with implementation, as you can see >>>>> on my wiki page. The most of i386 commits are not tested because a >>>>> cross-build problem on amd64 system. >>>>> Other resolvable problem are on amd64 system, where the machine triple >>>>> faulted, because wrong assembler statements generated with the >>>>> compiler. I'm deep in debugging both of two case. This issue are too >>>>> in my wiki page under this section: >>>>> https://wiki.freebsd.org/SummerOfCode2014/IntelSMAPandKernelPatching#notes >>>>> >>>>> I have at this week my last exam at Thursday. After that I'm focusing >>>>> fully on GSoC. >>>>> >>>>> On 6/6/14, Oliver Pinter wrote: >>>>>> Hi all! >>>>>> >>>>>> Previous week I started to work on SMAP for amd64 and i386. For amd64 >>>>>> many parts are in good state. The codes currently are only compile >>>>>> tested, at next week I create a VM, and create run-time tests. For >>>>>> i386 started the work on yesterday. >>>>>> All of my status can be found on my wiki page. >>>>>> >>>>>> What's done, but not tested in this week: >>>>>> * {amd64,i386} trap handler >>>>>> * amd64 initialization >>>>>> * {amd64,i386} identification >>>>>> * {amd64,i386} exceptions >>>>>> * amd64 pmap changes >>>>>> * amd64 support.S changes >>>>>> * amd64 ia32 compat exceptions >>>>>> * i386 ddb extension >>>>>> >>>>>> At next week I plan to finish all of amd64 things, and most of i386 >>>>>> things, and begin to test; start to design a proper way to create >>>>>> kpatch and/or ifunc like things. >>>>>> >>>>>> >>>>>> svn: http://svnweb.freebsd.org/socsvn/soc2014/op/ >>>>>> git: https://github.com/opntr/opBSD (branches: >>>>>> op/gsoc2014/{master,smap,kpatch} ) >>>>>> wiki: >>>>>> https://wiki.freebsd.org/SummerOfCode2014/IntelSMAPandKernelPatching >>>>>> >>>>>> >>>>>> On 5/29/14, Oliver Pinter wrote: >>>>>>> Hi all! >>>>>>> >>>>>>> I'm working on Intel SMAP technology in first half of GSoC. >>>>>>> At first week I investigated in SMAP technology and relevant FreeBSD >>>>>>> codes, whats changed since my Bsc thesis. >>>>>>> >>>>>>> I implemented a vulnerable kernel module and PoC to test allowed and >>>>>>> not allowed memory access scenario. Created my wiki page, svn repo, >>>>>>> and git repo. >>>>>>> >>>>>>> svn: http://svnweb.freebsd.org/socsvn/soc2014/op/ >>>>>>> git: https://github.com/opntr/opBSD (branches: >>>>>>> op/gsoc2014/{master,smap,kpatch} ) >>>>>>> wiki: >>>>>>> https://wiki.freebsd.org/SummerOfCode2014/IntelSMAPandKernelPatching >>>>>>> test-cases: >>>>>>> http://svnweb.freebsd.org/socsvn/soc2014/op/tests/smap-tester/ >>>>>>> >>>>>>> Good days, >>>>>>> Oliver >>>>>>> >>>>>> >>>>> >>>> >>> >> >