July 2014 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

IRQ mismatch ifconfig and /proc/interrupts
by Oscar Salvador July 31, 2014

July 31, 2014

Hi People! How are you doing? I'm writting to you because I have a doubt about interrupts. If I look the interrupts assigned to my eth* with ifconfig, I get: eth0 Link encap:Ethernet HWaddr bb:aa:bb:bb:aa:aa Interrupt:20 Memory:f7e00000-f7e20000 eth1 Link encap:Ethernet HWaddr bb:aa:bb:bb:aa:aa Interrupt:18 Memory:f7d00000-f7d20000 As you can see, my system assigned IRQ-20 and IRQ-18 to eth0 and eth1. But If i look into /proc/interrupts, I don't have these interrupts: root@oscar:/home/oscar# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 15 0 0 0 0 0 0 0 IR-IO-APIC-edge timer 8: 0 1 0 0 0 0 0 0 IR-IO-APIC-edge rtc0 9: 0 0 0 0 0 2 1 0 IR-IO-APIC-fasteoi acpi 16: 191342 27819 25143 21231 19007 18159 17183 15717 IR-IO-APIC-fasteoi ehci_hcd:usb3 19: 15 7 0 0 2 9 1 4 IR-IO-APIC-fasteoi firewire_ohci 23: 1441 76 61 42 101 55 29 23 IR-IO-APIC-fasteoi ehci_hcd:usb4 40: 0 0 0 0 0 0 0 0 DMAR_MSI-edge dmar0 41: 0 0 0 0 0 0 0 0 DMAR_MSI-edge dmar1 42: 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge xhci_hcd 43: 27318 1788 1314 1414 4046 2273 2232 2059 IR-PCI-MSI-edge eth0 44: 115244 14686 10096 8738 41559 16021 10972 10090 IR-PCI-MSI-edge ahci 45: 197010 19487 45260 14687 43697 29520 24546 21590 IR-PCI-MSI-edge eth1-rx-0 46: 27239 20276 18861 14845 54218 17950 12907 9765 IR-PCI-MSI-edge eth1-tx-0 47: 0 0 1 0 0 0 0 1 IR-PCI-MSI-edge eth1 48: 262 150 78 60 261 249 168 47 IR-PCI-MSI-edge snd_hda_intel 49: 857324 80338 67789 59555 682632 90385 78616 65048 IR-PCI-MSI-edge i915 As you can see, seems to be that eth1 has IRQ-45 IRQ-46 and IRQ-47, and eth0 has IRQ-43. I don't understand why ifconfig shows another IRQ. Is this a normal behaviour? Someone would be so kind to explain me this? Or maybe throw me some paper that explains this. thank you very much Best Regards Oscar

2 1

Re: rootkits blocking using virtualization??
by Peter Teoh July 31, 2014

July 31, 2014

Are u referring to this: http://kernelnewbies.org/KernelProjects/VirtRootkitBlocker Just trying to answer your question: --Is the method of making kernel read only to block rootkits used in linux kernel mainline? I suspect not. How are u going to distinguish between "legitimate program" and "rootkit" program? Program includes both userland program and kernel modules. This distinction is needed, because legitimate kernel modules can call "kmalloc" and that is read/writeable kernel memory. Supposed there is a vulnerability in the kernel modules (and thus userspace program can escalate privilege and execute into) then the "kmalloc" is executed on behalf of the malware, but outwardly it looks as if the kernel module is making a memory allocation. Unless u record down all the potential legitimate kernel execution path (sequence of EIP addresses), and compare it dynamically with the redirected path (as triggered by the malware), it seemed like impossible to distinguish. And the database of path is also going to be very huge. Let me know if u have alternative ideas about setting kernel memory readonly. But on the other hand, this idea is also not new, explored before, for virtualization protection, NOT for rootkit detection. When u virtualized OS, the host has to set the all the memory given to the guest as readonly. For details: For KVM: http://www.linux-kvm.org/wiki/images/3/33/KvmForum2008$kdf2008_15.pdf For Xen: http://wiki.xen.org/wiki/X86_Paravirtualised_Memory_Management http://lists.xen.org/archives/html/xen-devel/2009-10/msg01201.html And this page has good info: http://www.linux-kvm.org/page/Memory (read esp the "shadow page memory" mechanism, which is very expensive, and somewhat like the ideas proposed in the kernelnewbies mentor page). On Wed, Jul 30, 2014 at 7:44 PM, Aniket Shinde <universalvirus.ani(a)gmail.com > wrote: > Hello guys, > I was going through kernelnewbies.org and came across a project > "Block Rootkits using Virtualization" by riel. > Basically we have to make kernel read only after boot process > completes so rootkits get blocked. > I have few doubts... > > --Is the method of making kernel read only to block rootkits used in linux > kernel mainline? > > --have anybody implenented this project already? > > --what is the good way to start with above project? > > --any guidelines to implemnet above project?? > > --can I get any menor?? > > --any material related to above project?? > > (note: i have requested to mailing list but have not been approved yet. So > please reply me personely.) > > _______________________________________________ > Kernel-mentors mailing list > Kernel-mentors(a)selenic.com > http://selenic.com/mailman/listinfo/kernel-mentors > > -- Regards, Peter Teoh

1 1

blocking rootkits using virtualization
by Aniket Shinde July 30, 2014

July 30, 2014

Hello guys, I was going through kernelnewbies.org and came across a project "Block Rootkits using Virtualization" by riel. Basically we have to make kernel read only after boot process completes so rootkits get blocked. I have few doubts... --Is the method of making kernel read only to block rootkits used in linux kernel mainline? --have anybody implenented this project already? --what is the good way to start with above project? --any guidelines to implemnet above project?? --can I get any menor?? --any material related to above project??

2 1

global descriptor table in X86 Linux
by Xin Tong July 29, 2014

July 29, 2014

Hi Ive heard that Linux uses the flat mode segmentation, i.e. the segmentation base is forced to be 0 and the limit to be 2^64. I am having trouble finding the kernel code that sets up the GDT, can someone please point me to the right direction. Thanks a lot. Xin

2 1

Doubt Regarding Floating Point Arithmetic
by me storage July 29, 2014

July 29, 2014

Hi I am reading LDD .In that i didn't understand one point .In Chapter 2(Building and Running Modules) they mentioned that " Kernel code cannot do floating point arithmetic" .My doubt is which code is used for floating point arithmetic that means at low level? Thank you

4 4

Re: How to implement a driver's read and write operations with synchronization properly
by Anh Le July 29, 2014

July 29, 2014

On Tue, Jul 29, 2014 at 7:47 PM, Jonathan Neuschäfer <j.neuschaefer(a)gmx.net> wrote: > I've tried this out myself, and it seems to be an issue with bash: > As you can see, I observed the same pattern of 1008 and 993 bytes. I think you're right. The split is done by the user program, separated from kernel land. So I guess it's reasonable to use the 1st approach, which is to always release the lock at the end of the operation. But still, user programs like bash could have a race problem by spliting the input, I hope that they can somehow take care of this problem themselves. Thanks guys. -- Le Quoc Anh

3 2

Re: How to implement a driver's read and write operations with synchronization properly
by Anh Le July 29, 2014

July 29, 2014

Thanks, Jonathan, for the quick reply. On Tue, Jul 29, 2014 at 3:36 PM, Jonathan Neuschäfer <j.neuschaefer(a)gmx.net> wrote: > Which "write operation" is called twice in your scenario? It's the "write" method of the "struct file_operations" structure. I define it like this (no synchronizatin yet): static ssize_t sample_write(struct file *f, const char __user *buf, size_t len, loff_t *ppos) { printk(KERN_DEBUG "[sample] buf len: %u, *ppos: %u\n", len, *ppos); return simple_write_to_buffer(kbuf, 2048, ppos, buf, len); } > If a userspace program writes 1000 bytes at first, how can you know that > it wants to perform another write later on? I use printk to debug the module. More details in the answer below. > If a userspace program wants to write a chunk of data atomically, it > should use just one call to write(2). (On Linux, one can save some > copying by using writev(2), which writes data from multiple buffers in > one atomic step.) I tried the following command: echo $(perl -e "print 'a'x2000") > /dev/sample and get the following messages from dmesg: [30884.066433] [sample] buf len: 1008, *ppos: 0 [30884.066451] [sample] buf len: 993, *ppos: 1008 So as I understand my 2001 bytes has been split into 2 chunks, the first one with 1008 bytes and the second one with 993 bytes, and therefore the write operation is called 2 times to consume the whole input. -- Le Quoc Anh

3 2

How to implement a driver's read and write operations with synchronization properly
by Anh Le July 29, 2014

July 29, 2014

Hi everyone, I'm trying to write a misc char driver with read and write operations, and I choose reader writer lock for synchronization between them. Suppose that when writing 2000 bytes, the write operation is called twice, each time writing only 1000 bytes. There are 2 ways to implement synchronization as below: 1. Acquire and release lock everytime the write operation is called. Same with read operation. 2. Acquire the lock when the write operation is called for the first time, and release when the whole write procedure is completed. In this case, the lock is acquired before transfering the 1st byte, and released after transfering the 2000th byte. Same with read operation. As how I see it, both of these approaches have problems. The first one release the lock in between the write operations, so a reader can get in while the writer has only finished a portion of its work. With the second approach, I have no way to tell that the write procedure ends with the 2000th byte. What if there are more? Could anyone tell me the proper way to deal with this situation? Thanks in advance. -- Le Quoc Anh

3 2

opening a file second time using vi on LCD console hangs the system
by Chan Kim July 29, 2014

July 29, 2014

Hi, I'm using fbconsole on the LCD using USB keyboard. I open a new file using vi then edit, write it, and exit. Then second time I open the file using vi, it hangs. with [1]+ Stopped (tty input) message. Anybody any hint? Thanks! Chan

2 1

Re: Kernelnewbies Digest, Vol 44, Issue 51
by Vishwas Srivastava July 28, 2014

July 28, 2014

thank Jeff for your time to read and reply my mail. One more ques, are you aware of anything in linux which can be used to check safely, if a particular piece of code is not running in process context, and therefore can not be preempted or context switched? For sure, I am going to be much careful to use in_interrupt/in_irq macros in future. thanks in advance. Vishwas S On Tue, Jul 29, 2014 at 12:30 AM, Jeff Haran <Jeff.Haran(a)citrix.com> wrote: > > > > > *From:* Vishwas Srivastava [mailto:vishu.kernel@gmail.com] > *Sent:* Monday, July 28, 2014 10:29 AM > *To:* Jeff Haran; kernelnewbies(a)kernelnewbies.org > > *Subject:* Re: Kernelnewbies Digest, Vol 44, Issue 51 > > > > Hi Jeff, > > yes, your guess is correct. The place i checked in_interrupt() > was a region before which a call to spin_lock_bh() was made. > > So what is the rule? > > > > Vishwas, > > > > My take from this was that the in_interrupt() macro is perhaps > inappropriately named. It doesn’t tell you you are in an interrupt > handler. It’s interpreting the bits of the thread_info preempt_count > field and those bits can be set for a variety of reasons. I’ve found it’s > not productive to try to impose rules on it after the fact. Not that > different than for instance the spin_lock() function. If you just read > that function name, “spin_lock()”, you might come to the conclusion that > it implies there is always some sort of spin loop going on. And that’s true > in many cases, but on a UP system with kernel pre-emption disable, > spin_lock() does nothing (at least it didn’t do anything the last time I > look at it closely, that might have changed since). The code does what it > does and one must struggle through reading it in order to figure out how to > use it (and hope that you’ve come to the right conclusions and haven’t > missed some subtlety and that it doesn’t change too much in the future). > Not the most efficient state of affairs IMHO, but that’s them apples. > > > > if in_interrupt() return me true then that is the region of the code which > can not be context switched or if i am out of interrupt (in kernel thread) > and have called spin_lock_bh(), then this macro is not reliable to safely > find out if the region below this can not be context switched? > > If that is the case, then perhaps only the "false" return of the macro > in_interrupt is reliable. > > > > “Reliable” in the sense that what it does sort of matches its mnemonics in > the case where it returns false. But when it returns true, it means > something else. > > > > Jeff Haran > > > > thanks, > > Vishwas S > > > > On Mon, Jul 28, 2014 at 9:54 PM, Jeff Haran <Jeff.Haran(a)citrix.com> wrote: > > > > *From:* kernelnewbies-bounces(a)kernelnewbies.org [mailto: > kernelnewbies-bounces(a)kernelnewbies.org] *On Behalf Of *Vishwas Srivastava > *Sent:* Saturday, July 26, 2014 10:07 AM > *To:* kernelnewbies(a)kernelnewbies.org > *Subject:* Re: Kernelnewbies Digest, Vol 44, Issue 51 > > > > Hi All, > > I have a doubt regarding the threaded interrupt handing > mechanism. > > what is the kernel context of execution while executing interrupt thread. > > if i check for macro > > in_irq() or in_interrupt() withing handler thread , my understanding is > that they both are going to return me 0 (since we are in kernel thread), > > as threads runs in process context. > > > > Also, since they are "kernel threads", they must be schedulable enteties. > > what conceptually deviated me from my understanding is one of the driver > which had a threaded interrupt mechanism and when i checked > > > > in_interrupt() macro, it returned me a non zero value so i am a bit > confused. > > > > By any chance had you disabled interrupts or bottom halves when you made > this call to in_interrupt()? > > The reason I ask is the last time I looked into this the conclusion I came > to was that in_interrupt() would return non-zero under a couple of > different conditions; 1) the code was really executing in either a bottom > half or IRQ context, or; 2) the code was executing in process context but > had previously disabled interrupts or bottom halves, e.g. a call to > spin_lock_bh() or anything else that disables bottom halves. At the time I > was trying to figure out how to tell for sure whether or not a given > function was being called from a bottom half (as opposed to executing in > process context with bottom halves disabled) and from what I could see at > the time, there was no way to distinguish the two conditions. Disclaimer: > I’m no expert on this stuff, just reporting what I concluded at the time > from eyeballing the code. Perhaps I missed something. > > > > Jeff Haran > > > > thanks in advance. > > > > Vishwas S > > > > > > > > > > > > >

1 0