[intel smap, kpatch] weekly report #9

[Oliver Pinter]

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>