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?
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!
@@LowLevelLearning can you please make device driver for some IPS displays by reading their manual ?
Finally, a decent, relatively modern, resource with examples on driver development.
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)
thanks I hope it is the second video of a long series, then also examining the whole issue of interrupts ....... sincere congratulations!
This is so good. I wish these series were available last year :( Could you also recommend some reading material? Thank you
wow! we need more videos like this!!! Thanks for your work!
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.
Keep it up friend, you are making an impact on learners like me :)
Thanks your tutorial, that's really cool! keep up!bro.
beautiful tutorial
very clear explanation
very clear and readable code
Glad you liked it!
Sir your channel should get more support. your vids are so usefull. Keep making these contents. THANK YOUU🙏🙏
So nice of you! :D
Great!!! Learning a lot !!!!
Glad to hear that!
return simple_read_from_buffer(user, size, off, "Hello!
" , 7); to avoid lot of Hello!'s
that was wonderful
Amazing tutorials, thank you
Million like , we need more videos
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?
Nice.. Keep uploading raspberry pi pico videos :)
Will do, once I figure out how to get this damn OLED screen to work D:
What if something went wrong and crashed? How would you debug the kernel-level code?
Thanks
:D
Nice tutorial mate 👍
Thank you! Cheers!
Many thanks bro
How did you get the broadcom datasheets?I Didn't found them even in the Broadcom's site :(
nice! please do more kernel driver tutorials
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
Loving it
please keep on uploading, how to write keyboard, mouse drivers and much more and what interview question can interviewer ask?
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!
@mark coming in with the crazy support. Thank you so much my dude!
Very nice
I understand it barely but great series
amazing
Did anyone catch the bug/reason why the file has many "hello"s when catted?
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?
Can you show us how to make a build target for a platform? For C/Rust
Because these are file system constructs, does this mean the driver speed is bottlenecked by the sdd/hdd speed?
(@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
2/3 👍
now.. how do we do this in rust.. :P
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?