Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Aug 2014 17:11:42 +0200
From:      Oliver Pinter <oliver.pntr@gmail.com>
To:        soc-status@freebsd.org
Cc:        gavin@freebsd.org
Subject:   Re: [intel smap, kpatch] weekly report #10 and #11
Message-ID:  <CAPjTQNFCWFdaYLW9azi6Pm8K-UhZN0pr9wuqSG2Aum0NUYxqTQ@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
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?CAPjTQNFCWFdaYLW9azi6Pm8K-UhZN0pr9wuqSG2Aum0NUYxqTQ>