I don't think your write function is safe. If they provide 1024 bytes, or greater, you're going to copy 1024 bytes into a buffer of 1024 bytes. However, when you use '%s' in the printk function, it's going to continue printing until it hits a NULL character. Ultimately if you're expecting a string value, or something that is NULL terminated, then you should always add 1 to buffer size. Great video though
You're going with somewhat classic but somewhat obsolete way of teaching/learning kernel development where you make a module creating a procfs file. This isn't best choice in my opinion as nowadays, it is quite unlikely that a typical driver would ever create a procfs file. Sysfs file, on the other hand - sure. Debugfs file - also. But not a procfs.. not anymore :) Now with sysfs you have this added bonus that it handles more things for you and you wouldn't do this bug on read callback. In your code, you always return 7 so the cat doesn't know if it did read the whole file or not - the read syscall never returns the EOF condition. This is why real procfs code in the kernel uses seq_operations abstraction to hanlde that nicely. The easiest thing you could do, however, is to check the offset argument, if it's non zero, you know its the 2nd read call and you can return 0 instead of 7. This still isn't fully correct but at least you won't get many "hello" messages anymore.
Your `printk` call in `lll_write` would result in a kernel infoleak vulnerability. If the user passes input longer than the buffer, there won't be any null bytes left at the end from the initial zero-fill and the `%s` may continue reading off the end of the buffer. To avoid this in ordinary C code, one would use the 'variable precision' form to allow you to specify the maximum length as an additional argument: printk("You said '%.*s'! ", size, data_buffer) Even better, though, would be to use the "escaped raw buffer" format -- provided as an extension for `printk` not present in ordinary `printf` -- to avoid writing newlines, control characters, or other garbage from the user into the kernel message log: printk("You said '%*pE'! ", size, data_buffer)
Very interesting series, please continue. I need to find something useful that would require a kernel module just to try it out. For those wondering, /proc is not a magic keyword, it's simply a special filesystem mounted by the kernel. You can see that by typing `mount`, among other such special FS (/sys, ...). @LLL do you plan on making a video that explains how to create a kernel module that can be mounted like this?
The bug in lll_read is that you never check if the read offset is greater than your buffer size, so when cat tries to read after it was given 7 bytes, your kernel mod just keeps giving it the same 7 bytes and the process repeats until cat is given a 0 to know that it has reached the end of the file.
Hello, I have an question here How the procfs will fetch the exact data from the hardware For example: /proc/meminfo will reflect the memory details. Will procfs resides in primary memory rather than secondary memory? If not can you please explain with example 🙂
(@5:00) - don’t you have to put \o (lowercase oh) to do an octal literal? Otherwise, you’ll just get 666 (base 10), which isn’t the same. You could also do \b000110110110 for binary, or \x1B6 for hexadecimal.
make[1]: *** /lib/modules/5.10.17-v7l+/build: No such file or directory. Stop. I m getting above error when give make all command, can anyone help to remove this error?
Please keep on uploading. I love these tutorials.
Glad you like them!
@@LowLevel-TV can you please make device driver for some IPS displays by reading their manual ?
I don't think your write function is safe. If they provide 1024 bytes, or greater, you're going to copy 1024 bytes into a buffer of 1024 bytes. However, when you use '%s' in the printk function, it's going to continue printing until it hits a NULL character. Ultimately if you're expecting a string value, or something that is NULL terminated, then you should always add 1 to buffer size. Great video though
You're going with somewhat classic but somewhat obsolete way of teaching/learning kernel development where you make a module creating a procfs file. This isn't best choice in my opinion as nowadays, it is quite unlikely that a typical driver would ever create a procfs file. Sysfs file, on the other hand - sure. Debugfs file - also. But not a procfs.. not anymore :)
Now with sysfs you have this added bonus that it handles more things for you and you wouldn't do this bug on read callback. In your code, you always return 7 so the cat doesn't know if it did read the whole file or not - the read syscall never returns the EOF condition. This is why real procfs code in the kernel uses seq_operations abstraction to hanlde that nicely.
The easiest thing you could do, however, is to check the offset argument, if it's non zero, you know its the 2nd read call and you can return 0 instead of 7. This still isn't fully correct but at least you won't get many "hello" messages anymore.
Your `printk` call in `lll_write` would result in a kernel infoleak vulnerability. If the user passes input longer than the buffer, there won't be any null bytes left at the end from the initial zero-fill and the `%s` may continue reading off the end of the buffer. To avoid this in ordinary C code, one would use the 'variable precision' form to allow you to specify the maximum length as an additional argument:
printk("You said '%.*s'!
", size, data_buffer)
Even better, though, would be to use the "escaped raw buffer" format -- provided as an extension for `printk` not present in ordinary `printf` -- to avoid writing newlines, control characters, or other garbage from the user into the kernel message log:
printk("You said '%*pE'!
", size, data_buffer)
I really love your explanation style. Hope you could make more advanced videos, you seem to have so much knowledge
Oh man. Thank you so much. Kernel modules were a black box for me.
return simple_read_from_buffer(user, size, off, "Hello!
" , 7); to avoid lot of Hello!'s
This is so good. I wish these series were available last year :( Could you also recommend some reading material? Thank you
Finally, a decent, relatively modern, resource with examples on driver development.
Very interesting series, please continue. I need to find something useful that would require a kernel module just to try it out.
For those wondering, /proc is not a magic keyword, it's simply a special filesystem mounted by the kernel. You can see that by typing `mount`, among other such special FS (/sys, ...).
@LLL do you plan on making a video that explains how to create a kernel module that can be mounted like this?
Thanks man! For the tutorials they are awesome. I just want to what do you do for living. Are you kernel developer ?
I am not a kernel developer, just embedded developer and a reader of stackoverflow LOL
nice! please do more kernel driver tutorials
What if something went wrong and crashed? How would you debug the kernel-level code?
How did you get the broadcom datasheets?I Didn't found them even in the Broadcom's site :(
that was wonderful
wow! we need more videos like this!!! Thanks for your work!
thanks I hope it is the second video of a long series, then also examining the whole issue of interrupts ....... sincere congratulations!
now.. how do we do this in rust.. :P
The bug in lll_read is that you never check if the read offset is greater than your buffer size, so when cat tries to read after it was given 7 bytes, your kernel mod just keeps giving it the same 7 bytes and the process repeats until cat is given a 0 to know that it has reached the end of the file.
Did anyone catch the bug/reason why the file has many "hello"s when catted?
Hello,
I have an question here
How the procfs will fetch the exact data from the hardware
For example: /proc/meminfo will reflect the memory details.
Will procfs resides in primary memory rather than secondary memory?
If not can you please explain with example 🙂
Here's how it does this:
elixir.bootlin.com/linux/latest/source/fs/proc/meminfo.c#L32
Thanks your tutorial, that's really cool! keep up!bro.
Keep it up friend, you are making an impact on learners like me :)
Thanks
:D
Sir your channel should get more support. your vids are so usefull. Keep making these contents. THANK YOUU🙏🙏
So nice of you! :D
Can you show us how to make a build target for a platform? For C/Rust
Nice.. Keep uploading raspberry pi pico videos :)
Will do, once I figure out how to get this damn OLED screen to work D:
Great!!! Learning a lot !!!!
Glad to hear that!
beautiful tutorial
very clear explanation
very clear and readable code
Glad you liked it!
I know this is off topic but I was wondering if you know how to pass internet over usb gadget for a raspberry pi zero?
Because these are file system constructs, does this mean the driver speed is bottlenecked by the sdd/hdd speed?
Nice tutorial mate 👍
Thank you! Cheers!
(@5:00) - don’t you have to put \o (lowercase oh) to do an octal literal? Otherwise, you’ll just get 666 (base 10), which isn’t the same. You could also do \b000110110110 for binary, or \x1B6 for hexadecimal.
Putting a '0' before a number formats it to octal, like '0b' for binary and '0x' for hex values
Million like , we need more videos
I understand it barely but great series
Amazing tutorials, thank you
Loving it
Very nice
Many thanks bro
amazing
2/3 👍
please keep on uploading, how to write keyboard, mouse drivers and much more and what interview question can interviewer ask?
Thanks!
@mark coming in with the crazy support. Thank you so much my dude!
make[1]: *** /lib/modules/5.10.17-v7l+/build: No such file or directory. Stop.
I m getting above error when give make all command, can anyone help to remove this error?