Hi,
On Sun, Sep 16, 2012 at 1:00 PM, Rajat Sharma <fs.rajat@xxxxxxxxx> wrote:
> Some useful debugging options:
>
> CONFIG_DEBUG_STACK_USAGE
> CONFIG_DEBUG_STACKOVERFLOW
>
>
>> if you take enough large array so as to hit the heap
>> area at that present moment (they both grow towards each other)
>
> I doubt if it is true for kernel mode stack. Kernel stack allocation is
> plain pages allocation using zone buddy allocator (alloc_pages_node), so
> what is beyond that page, allocated to something else or not is really not
> predictable. However one thing which is predictable (and other people have
> pointed out as well) is overrunning thread_info struct of the current task.
> Also this overrun may not show up with this simple module, because there is
> no need to access thread_info here. My suggestions:
I agree with the above. It sounds much more logical to me as well. I
made a mistake of thinking the Kernel 1GB as being mapped like an ELF
- which obviously may not be a correct assumption. Thanks for
correcting.
>
> Try putting a schedule call after overrunning thread_info structure,
> thread_info might be accessed while scheduling back current process.
> Try to access current macro after overrun, it will try do access corrupt
> thread_info structure to get task_struct pointer.
>
> But make sure to corrupt the thread_info structure in predictive manner as
> pointed out in previous mails :).
>
> -Rajat
>
>
> On Sun, Sep 16, 2012 at 10:35 AM, Shreyansh Jain <shrey.linux@xxxxxxxxx>
> wrote:
>> Hi 卜弋天 and list,
>>
>> Please find my comments inline
>>
>> On Thu, Sep 13, 2012 at 7:38 PM, 卜弋天 <buyit@xxxxxxx> wrote:
>>> i don't know why you want to corrupt kernel stack by using this method,
>>> stack usually grow from high address to low address,
>>> if you allocate a buff in a function then use memset(), it is writing
>>> data
>>> from low address to high address.
>>> in your implementation, you allocate an array with 8000*4=32000 bytes (
>>> int
>>> arr[8000]; ), then you try to corrupt stack by using memset(), which
>>> operate
>>> memory by bytes, rather than by int. so this memset() only corrupt the
>>> first
>>> 8192 bytes of the buffer, which is far away from your current task stack.
>>>
>>> thread_info locates at the bottom of current task's stack, please
>>> reference the source code of current_thread_info() function of your
>>> platform. i think it is true for X86 or ARM.
>>>
>>> if you really want to corrupt current kernel task's stack, please
>>> try
>>> below code, i did't test it but i think it should work, at least you can
>>> find something from the log:
>>>
>>> char *sp_addr;
>>> struct thread_info *thread = current_thread_info();
>>> sp_addr = (char*)thread;
>>>
>>> printk("sp_addr==thread:%p, task:%p\n", thread, thread->task);
>>>
>>> memset (sp_addr, 0x0, 1024);
>>>
>>> printk("after corrupt, task:%p, it is dying...\n", thread->task);
>>
>> Actually, after reading through the first authors email, it seems he
>> is trying to find the answer to "How much is maximum allocatable space
>> on the Kernel Stack" (Shubham, please correct me if I am wrong).
>>
>> In that essence what you have mentioned above is more of a direct
>> method of corrupting the thread_info structure - a definitive stack
>> corruption.
>>
>>>
>>>
>>>> Date: Thu, 13 Sep 2012 15:32:05 +0530
>>>> Subject: Re: kernel stack memory
>>>> From: mujeeb.adil@xxxxxxxxx
>>>> To: getarunks@xxxxxxxxx
>>>> CC: shubham20006@xxxxxxxxx; kernelnewbies@xxxxxxxxxxxxxxxxx
>>>
>>>>
>>>> Hi,
>>>>
>>>> On Thu, Sep 13, 2012 at 1:59 PM, Arun KS <getarunks@xxxxxxxxx> wrote:
>>>> > Hello Shubham,
>>>> >
>>>> > On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma
>>>> > <shubham20006@xxxxxxxxx>
>>>> > wrote:
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> As far as i know, the size of stack allocated in the kernel space is
>>>> >> 8Kb for each process. But in case i use more than 8Kb of memory from
>>>> >> the stack then what will happen? I think that in that case the system
>>>> >> would crash because i am accessing an illegal memory area. I wrote
>>>> >> kernel module in which i defined an integer array whose size was
>>>> >> 8000.
>>>> >> But still it did not crash my system. Why?
>>>> >>
>>>> >> The module i wrote was as follows:
>>>> >>
>>>> >> #include <linux/kernel.h>
>>>> >> #include <linux/module.h>
>>>> >>
>>>> >> int __init init_my_module(void)
>>>> >> {
>>>> >> int arr[8000];
>>>> >> printk("%s:%d\tmodule initilized\n", __func__, __LINE__);
>>>> >> arr[1] = 1;
>>>> >> arr[4000] = 1;
>>>> >> arr[7999] = 1;
>>>> >
>>>> > Instead do a memset.
>>>> > memset(arr, 0, 8192);
>>>> >
>>>> > If you do this the current calling process thread_info will be set to
>>>> > zero.
>>>> > This should cause a crash.
>>>>
>>>> I tried and this is also not causing any crash.
>>>>
>>>> Thanks,
>>>> Adil
>>>> >
>>>> > Thanks,
>>>> > Arun
>>>> >
>>>> >
>>>> >>
>>>> >> printk("%s:%d\tarr[1]:%d, arr[4000]:%d, arr[7999]:%d\n", __func__,
>>>> >> __LINE__, arr[1], arr[4000], arr[7999]);
>>>> >> return 0;
>>>> >> }
>>>> >>
>>>> >> void __exit cleanup_my_module(void)
>>>> >> {
>>>> >> printk("exiting\n");
>>>> >> return;
>>>> >> }
>>>> >>
>>>> >> module_init(init_my_module);
>>>> >> module_exit(cleanup_my_module);
>>>> >>
>>>> >> MODULE_LICENSE("GPL");
>>>> >>
>>
>> Though I don't have an exact answer, but what I understand is that
>> there is no limit imposed by the kernel while writing in the kernel
>> layer (as Kshemendra's first post pointed out). Thus, you keep writing
>> what you wish till either you corrupt the next instruction set or some
>> data structure which would be read somewhere in future (at that time
>> what can happen is undefined). Assuming this understanding is some
>> what correct, if you take enough large array so as to hit the heap
>> area at that present moment (they both grow towards each other), you
>> can have a undefined behavior (which may not be instantly visible).
>>
>> This is all I can add. PCMIIW
>>
>> Thanks.
>> Shreyansh
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies@xxxxxxxxxxxxxxxxx
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-
Shreyansh
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
