Date: Thu, 14 Aug 2014 22:48:25 +0200 From: Oliver Pinter <oliver.pntr@gmail.com> To: soc-status@freebsd.org Cc: gavin@freebsd.org Subject: [intel smap, kpatch] weekly report #12 - FINAL Message-ID: <CAPjTQNGvHuVsrhrphoZ3SdqT7VqP04n4YpyfEFTy0XnjU_zJKQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Last week I finalized the implementation and tested on real hardware and in emulator. All things works fine. You can find all details on wiki page, codes on github and in socsvn, and vm image on my crysys.hu home, and the final patchset in socsvn. Links: https://wiki.freebsd.org/SummerOfCode2014/IntelSMAPandKernelPatching https://github.com/opntr/opBSD/commits/op/gsoc2014/master http://www.crysys.hu/~op/freebsd/vm-image/ http://svnweb.freebsd.org/socsvn/soc2014/op/ On 8/9/14, Oliver Pinter <oliver.pntr@gmail.com> wrote: > Last two week I optimized a little the code and separated machine > dependent and independent code. I identified one wrong API usage which > i should fix at next week. > > The KSP framework was mostly done, and tested on real hardware w/ and > w/o XSAVEOPT and on qemu w/ and w/o SMAP. > The SMAP functionality was tested in qemu with the test framework > (what you can find in svn repo or github). > > The current status is in my wiki. > > I running again to svn error, when I try to merge current head to my > project branch: > > [...] > U sys/dev/usb/usbdevs > U sys/dev/hptnr/os_bsd.h > U sys/dev/drm2/ttm/ttm_bo_vm.c > U sys/dev/acpica/acpi_cpu.c > U sys/dev/fdt/simplebus.c > U sys/dev/hptrr/hptrr_os_bsd.c > U sys/dev/fb/fbd.c > svn: E130003: The PROPFIND response contains invalid XML (207 Multi-Status) > op@pandora-d ~> svnlite --version > svn, version 1.8.8 (r1568071) compiled on > bikeshed-malachite-topaz-amber-freebsd > > What's next: > * fix the mentioned bug > * more testing > * optionally implement variable size patches (not yet required to SMAP > functionality) > > On 7/26/14, Oliver Pinter <oliver.pntr@gmail.com> wrote: >> 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 <oliver.pntr@gmail.com> 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 <oliver.pntr@gmail.com> 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 <oliver.pntr@gmail.com> 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 <oliver.pntr@gmail.com> 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 <oliver.pntr@gmail.com> 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 <oliver.pntr@gmail.com> 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 <oliver.pntr@gmail.com> 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPjTQNGvHuVsrhrphoZ3SdqT7VqP04n4YpyfEFTy0XnjU_zJKQ>