Hi,
I would like to open/read/write/close a regular file from my device
driver.
I think it would be possible, but I am confused, the "The Linux Kernel
Module Programming Guide" states that I can not use standard libraries
from within a module, I know the standard library ends up calling
system calls, but which calls should I use to deal with regular
files ?
I am developing a Ethernet driver and the Mac address configuration
Jos? Lu?s Marchetti
P.S. Posted the message again, previous one had no subject.
Veja quais s?o os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
On Sat, 2009-01-10 at 19:44 -0800, Jose Luis Marchetti wrote:
> I would like to open/read/write/close a regular file from my device
> driver.
No, you probably wouldn't :) Generally, this is recommended against
because there are many better ways to do it:
* Create an interface and have userspace set the parameter (ethtool,
ifconfig - the latter can already set MAC addresses)
* Create entries in sysfs and have uevents cause various activities,
including having the response being some file gets loaded (firmware).
Since it looks like you just want to set the MAC address, I suggest
looking at how this is already done, then rely upon users using ifconfig
correctly to set the desired address. There should be no reason to have
a kernel-side network driver reading from a file.
[NOTE: If you're doing embedded development and you don't have an EEPROM
on your board, and you're asking this because someone told you to find
the cheapest and nastiest solution in software, then look at passing in
the desired MAC via the firmware, as many embedded boards already do. ]
Jon.
Jon Masters wrote:
>
> [NOTE: If you're doing embedded development and you don't have an EEPROM
> on your board, and you're asking this because someone told you to find
> the cheapest and nastiest solution in software, then look at passing in
> the desired MAC via the firmware, as many embedded boards already do. ]
>
Or just have the startup scripts set it via ifconfig.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Sat, 10 Jan 2009 19:44:55 -0800 (PST)
Jose Luis Marchetti <[email protected]> wrote:
> Hi,
>
> I would like to open/read/write/close a regular file from my device
> driver.
You don't generally get to do this. What are you actually trying to
achieve ?
>
> You don't generally get to do this. What are you
> actually trying to achieve ?
Thanks for asking, there are two scenarios, the first one it would be to save an ethernet mac address, I got already emails with some work arounds for this. The other scenario is a little bit more complicated:
The system I am working now ( Kernel drivers + User applications ) performs cryptographic operations and it has a regulatory constraint: the user application have to undergo (expensive) certification everytime it is changed, but that is only true if the user application have access to the cryptographic keys, imagine a i++ is missing in the code, then we have to undergo the expensive certification for that.
To avoid that I am trying to isolate the keys ( about 30 X 128bit keys, some of the keys chance everytime they are used ) and cryptographic algorithm from the application and putting them into the kernel so the application can not access that. Well you would say, saving the keys into a file is not a good security measure as it is accessible, the trick is that before saving the key into the file the kernel would encrypt the keys with another key ( KEK- Key Encryption Key ) and this KEK is stored into non volatile register inside the processor, so although the file is accessible it is encrypted.
In this scenario the user application would request encryption/decryption services from the kernel, but it would never pass the Key to be used during the operation, it would pass a Key Id, like this: encrypt this data using key number 7 and Key number 7 is stored in a file ( encrypted ) the kernel could read.
OK, some would say, the user application could read the key file and passed the encrypted key into the kernel function, the kernel would decrypt the encrypted key and do the operation, which is fine, but some of those keys change at every operation, so they have to be re-stored into the file at every operation, it would be nice to have it done by the kernel.
Thanks!
Veja quais s?o os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
Jose Luis Marchetti wrote:
>> You don't generally get to do this. What are you
>> actually trying to achieve ?
>
> Thanks for asking, there are two scenarios, the first one it would be to save an ethernet mac address, I got already emails with some work arounds for this. The other scenario is a little bit more complicated:
>
> The system I am working now ( Kernel drivers + User applications ) performs cryptographic operations and it has a regulatory constraint: the user application have to undergo (expensive) certification everytime it is changed, but that is only true if the user application have access to the cryptographic keys, imagine a i++ is missing in the code, then we have to undergo the expensive certification for that.
> To avoid that I am trying to isolate the keys ( about 30 X 128bit keys, some of the keys chance everytime they are used ) and cryptographic algorithm from the application and putting them into the kernel so the application can not access that. Well you would say, saving the keys into a file is not a good security measure as it is accessible, the trick is that before saving the key into the file the kernel would encrypt the keys with another key ( KEK- Key Encryption Key ) and this KEK is stored into non volatile register inside the processor, so although the file is accessible it is encrypted.
> In this scenario the user application would request encryption/decryption services from the kernel, but it would never pass the Key to be used during the operation, it would pass a Key Id, like this: encrypt this data using key number 7 and Key number 7 is stored in a file ( encrypted ) the kernel could read.
> OK, some would say, the user application could read the key file and passed the encrypted key into the kernel function, the kernel would decrypt the encrypted key and do the operation, which is fine, but some of those keys change at every operation, so they have to be re-stored into the file at every operation, it would be nice to have it done by the kernel.
One big problem with file access in the kernel is that all the file
operations require a process context - they need a process to stick the
file descriptor into, to determine access permissions, etc. If you just
start calling file operations from inside the kernel you're essentially
stealing whatever process you're being called from's context for these
operations, which is unlikely to be a good idea.
Not to mention, that accessing files from inside the kernel usually
means the kernel enforces a policy on file naming/locations, and putting
that sort of policy in the kernel is usually frowned upon.
In the case you're describing I'm not sure why you couldn't just store
the keys in encrypted form inside the user app and have it write them
back out when they change, instead of making the kernel do it..
> One big problem with file access in the kernel is that all
> the file operations require a process context - they need a
> process to stick the file descriptor into, to determine
> access permissions, etc. If you just start calling file
> operations from inside the kernel you're essentially
> stealing whatever process you're being called from's
> context for these operations, which is unlikely to be a good
> idea.
>
> Not to mention, that accessing files from inside the kernel
> usually means the kernel enforces a policy on file
> naming/locations, and putting that sort of policy in the
> kernel is usually frowned upon.
OK, that is clear now.
>From all I read, it is possible to access files from within inside the kernel, but it would not be a good practice, thanks for the insights.
>
> In the case you're describing I'm not sure why you
> couldn't just store the keys in encrypted form inside
> the user app and have it write them back out when they
> change, instead of making the kernel do it..
Yes, that was one of the possible solutions I pointed out, and it might be the one I am going to use, thanks!
Veja quais s?o os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
On Mon, 2009-01-12 at 07:51 -0800, Jose Luis Marchetti wrote:
> OK, that is clear now.
> From all I read, it is possible to access files from within inside the kernel, but it would not be a good practice, thanks for the insights.
> >
I don't know why no-one's brought this up already but no, it usually
isn't even possible. As previously mentioned, you will hijack the
current user context to do your file operations. That context may be in
a different filesystem namespace (eg due to chroot'ing) and as such
*won't even be able to see the file you're trying to hit*.
Even if you create a new kernel thread which is parented to init you'll
get a consistent view of files but it's still very hard to know it's the
*right* view of files.
http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad
--Ben.