hi!
we now have a 'struct timer_list' API, its use is similar to that of the linux kernel (and openbsc).
The caller (e.g. your driver/app) allocates a 'struct timer_list', sets the 'cb' function pointer to a callback function, and then schedules the timer with 'schedule_timer(&my_struct_tm, 600) for expiration in e.g. 600ms from now.
Once the timer expires, it will call the callback. There's also an 'unsigned long' argument that you can pass along.
Calling the timer expiration routines happens by calling update_timers() from the while (1) loop in the main program. This will of course change once we have a scheduler and tasks.
Cheers, Harald
Hi folks.
I have now getting interrupts and i am sending the first little APDUs to the card. I think i will have something that basicly works soon. But up to now i think it will be impossible to save processing time during the transmission - wait phases without having semaphores (or something semilar that can be used to wait for an event without wasting processing time in a while loop.) However - this only makes sense with a multitasking os which we actually do not have ;-)
The driver will get a function like sim_card_transceive(*message, *response) or so on because a transaction with the card will never be receive or send only. You always send something to the card and you always get something back.
The response and answer apdu structures will be the same as in XCOS and i think i can reuse a lot of the good old XCOS header files that contain basic constants, returncodes ect...
Thanks a lot to roh who showed me how i can register an interrupt.
regards. Philipp
Hi,
congrats.
Does the chip manages T=0 or T=1 by itself or do you have to implement it in software?
Indeed APDU are always exchanged. If the card doesn't answer, it's an error condition. it should be reported by an error status return value. But the complete exchange can be long, a card may send "time extension requests".
The reset procedure requires a dedicated API.
What about PPS, ie line speed negociation? This feature is described in ISO7816-3, and also in TS 11.11 chapter 5.8.2.
Your driver need 4 functions: -init driver -stop driver -reset card and return ATR -exchange APDU and, maybe -suspend and resume, which can stop the clock.
I think official sim cards can be put in sleep state, that the clock can be stopped, and this sort of energy saving stuff. I don't know a lot about this, and we don't need this in a first version.
----- Update status for the on-card project: -----
Reminder : I'm using javacard 2.x.y
I'm still working on the file system implementation, I want it sufficiently versatile for others projects too, so it's a bit long, but already working. I have routines to create files and directories, support binary files, record files and directories. I still need to create write() and read() routines, but they are quite trivial. I'm spending time on the file selection, even if the SIM spec supports only a few modes.
The first goal is to have a basic applet that's the most ISO7816-4 compatible, then a sim specific version. The functionalities are equivalent , but the apdu formats are a bit different.
The final goal is to have the ability to create any file structure (GSM or not) holding any possible data, without neglecting security (of files, not gsm algs ;) ).
Speaking of this, the COMP128 alg is already ported to javacard thanks to C code available on the web. If someone has test vectors (IE encryption results verified by someone else), I'll be happy to try them.
I still have a small doubt for high-update rate files. What is an high update rate? Can this really wear a card's eeprom? I may have to create a specific file type to implement wear levelling, using a log/cyclic structure. I don't know the urgency level of this feature.
Regards Sebastien
On Tue, Mar 9, 2010 at 3:12 PM, dexter zero-kelvin@gmx.de wrote:
Hi folks.
I have now getting interrupts and i am sending the first little APDUs to the card. I think i will have something that basicly works soon. But up to now i think it will be impossible to save processing time during the transmission - wait phases without having semaphores (or something semilar that can be used to wait for an event without wasting processing time in a while loop.) However - this only makes sense with a multitasking os which we actually do not have ;-)
The driver will get a function like sim_card_transceive(*message, *response) or so on because a transaction with the card will never be receive or send only. You always send something to the card and you always get something back.
The response and answer apdu structures will be the same as in XCOS and i think i can reuse a lot of the good old XCOS header files that contain basic constants, returncodes ect...
Thanks a lot to roh who showed me how i can register an interrupt.
regards. Philipp
Something more of a note for later:
I don't know which GSM stack layer needs to exchange APDUs. I guess it's not level 1, so apdus will be exchanged through the serial link with the phone. It may be nice to have a pcsclite driver to drive the sim card in the phone. Then we'll be able to use a SIM cards connected to the real phone, or a ccid smart card reader connected to the PC running the layer2/layer3, using the same API.
Sebastien
On Tue, Mar 9, 2010 at 4:21 PM, Sébastien Lorquet squalyl@gmail.com wrote:
Hi,
congrats.
Does the chip manages T=0 or T=1 by itself or do you have to implement it in software?
Indeed APDU are always exchanged. If the card doesn't answer, it's an error condition. it should be reported by an error status return value. But the complete exchange can be long, a card may send "time extension requests".
The reset procedure requires a dedicated API.
What about PPS, ie line speed negociation? This feature is described in ISO7816-3, and also in TS 11.11 chapter 5.8.2.
Your driver need 4 functions: -init driver -stop driver -reset card and return ATR -exchange APDU and, maybe -suspend and resume, which can stop the clock.
I think official sim cards can be put in sleep state, that the clock can be stopped, and this sort of energy saving stuff. I don't know a lot about this, and we don't need this in a first version.
----- Update status for the on-card project: -----
Reminder : I'm using javacard 2.x.y
I'm still working on the file system implementation, I want it sufficiently versatile for others projects too, so it's a bit long, but already working. I have routines to create files and directories, support binary files, record files and directories. I still need to create write() and read() routines, but they are quite trivial. I'm spending time on the file selection, even if the SIM spec supports only a few modes.
The first goal is to have a basic applet that's the most ISO7816-4 compatible, then a sim specific version. The functionalities are equivalent , but the apdu formats are a bit different.
The final goal is to have the ability to create any file structure (GSM or not) holding any possible data, without neglecting security (of files, not gsm algs ;) ).
Speaking of this, the COMP128 alg is already ported to javacard thanks to C code available on the web. If someone has test vectors (IE encryption results verified by someone else), I'll be happy to try them.
I still have a small doubt for high-update rate files. What is an high update rate? Can this really wear a card's eeprom? I may have to create a specific file type to implement wear levelling, using a log/cyclic structure. I don't know the urgency level of this feature.
Regards Sebastien
On Tue, Mar 9, 2010 at 3:12 PM, dexter zero-kelvin@gmx.de wrote:
Hi folks.
I have now getting interrupts and i am sending the first little APDUs to the card. I think i will have something that basicly works soon. But up to now i think it will be impossible to save processing time during the transmission - wait phases without having semaphores (or something semilar that can be used to wait for an event without wasting processing time in a while loop.) However - this only makes sense with a multitasking os which we actually do not have ;-)
The driver will get a function like sim_card_transceive(*message, *response) or so on because a transaction with the card will never be receive or send only. You always send something to the card and you always get something back.
The response and answer apdu structures will be the same as in XCOS and i think i can reuse a lot of the good old XCOS header files that contain basic constants, returncodes ect...
Thanks a lot to roh who showed me how i can register an interrupt.
regards. Philipp
On Tue, Mar 09, 2010 at 04:25:11PM +0100, Sébastien Lorquet wrote:
I don't know which GSM stack layer needs to exchange APDUs. I guess it's not level 1,
In normal GSM stacks, yes, the Layer1 provides an abstraction layer for SIM card access.
Hwoever, the actual SIM card read/write commands come from Layer 3 or the application above that.
so apdus will be exchanged through the serial link with the phone. It may be nice to have a pcsclite driver to drive the sim card in the phone. Then we'll be able to use a SIM cards connected to the real phone, or a ccid smart card reader connected to the PC running the layer2/layer3, using the same API.
Yes, I like that idea, and we can easily use yet another of our HLDC data link connections for this.
However, it seems almost like a bit of over-engineering to me to go a far as to support PC/SC. Sure, it's a cool hack, and if somebody has an interest in it and some time to spare.
But then, as long as the Layer3 is on the PC, it would be fine if it can support real PC/SC readers. Only when we start to support running layer3 inside the phone, we would require the use of the SIM card reader inside the phone.
Hmm we can take this the reverse way: Instead of implementing PCSC for the phone SIM, we can implement the phone API for PCSC. This will me MUCH more simpler. A thread with a queue to collect the commands and call the callback when the response is received, then we're done (yes, pcsc is synchronous)
On Tue, Mar 9, 2010 at 4:54 PM, Harald Welte laforge@gnumonks.org wrote:
On Tue, Mar 09, 2010 at 04:25:11PM +0100, Sébastien Lorquet wrote:
I don't know which GSM stack layer needs to exchange APDUs. I guess it's
not
level 1,
In normal GSM stacks, yes, the Layer1 provides an abstraction layer for SIM card access.
Hwoever, the actual SIM card read/write commands come from Layer 3 or the application above that.
so apdus will be exchanged through the serial link with the phone. It may be nice to have a pcsclite driver to drive the sim card in the
phone.
Then we'll be able to use a SIM cards connected to the real phone, or a
ccid
smart card reader connected to the PC running the layer2/layer3, using
the
same API.
Yes, I like that idea, and we can easily use yet another of our HLDC data link connections for this.
However, it seems almost like a bit of over-engineering to me to go a far as to support PC/SC. Sure, it's a cool hack, and if somebody has an interest in it and some time to spare.
But then, as long as the Layer3 is on the PC, it would be fine if it can support real PC/SC readers. Only when we start to support running layer3 inside the phone, we would require the use of the SIM card reader inside the phone.
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
so apdus will be exchanged through the serial link with the phone. It may be nice to have a pcsclite driver to drive the sim card in the phone. Then we'll be able to use a SIM cards connected to the real phone, or a ccid smart card reader connected to the PC running the layer2/layer3, using the same API.
Yes, I like that idea, and we can easily use yet another of our HLDC data link connections for this.
However, it seems almost like a bit of over-engineering to me to go a far as to support PC/SC. Sure, it's a cool hack, and if somebody has an interest in it and some time to spare.
I would do it the other way around. Make sure that all call from layer 3 are in the form of " apdu_xfer(in,out); "
Then implementing this apdu_xfer either using : . A HLDC data link to the real phone . A PCSC reader (the api allows for raw apdu exchange very easily) . A bare serial link to one of those cheap card reader . The SIM api directly when running inside the phone.
Sylvain
Hi sylvain, Yes, we're on the same wavelength here.
Sebastien
On Tue, Mar 9, 2010 at 5:03 PM, Sylvain Munaut 246tnt@gmail.com wrote:
so apdus will be exchanged through the serial link with the phone. It may be nice to have a pcsclite driver to drive the sim card in the
phone.
Then we'll be able to use a SIM cards connected to the real phone, or a
ccid
smart card reader connected to the PC running the layer2/layer3, using
the
same API.
Yes, I like that idea, and we can easily use yet another of our HLDC data link connections for this.
However, it seems almost like a bit of over-engineering to me to go a far as to support PC/SC. Sure, it's a cool hack, and if somebody has an interest in it and some time to spare.
I would do it the other way around. Make sure that all call from layer 3 are in the form of " apdu_xfer(in,out); "
Then implementing this apdu_xfer either using : . A HLDC data link to the real phone . A PCSC reader (the api allows for raw apdu exchange very easily) . A bare serial link to one of those cheap card reader . The SIM api directly when running inside the phone.
Sylvain
On Tue, 9 Mar 2010 16:21:43 +0100 Sébastien Lorquet squalyl@gmail.com wrote:
I think official sim cards can be put in sleep state, that the clock can be stopped, and this sort of energy saving stuff. I don't know a lot about this, and we don't need this in a first version.
All reasonably recent SIM cards (the 3,3V generation and past) support it and phones have been using this to save power for at least the past 12 Years. But I guess this is not a thing to worry about in this stage but rather something to keep in mind.
cheers, nibbler
Hi dexter,
thanks for your update!
On Tue, Mar 09, 2010 at 03:12:47PM +0100, dexter wrote:
I have now getting interrupts and i am sending the first little APDUs to the card. I think i will have something that basicly works soon.
But up to now i think it will be impossible to save processing time during the transmission - wait phases without having semaphores (or something semilar that can be used to wait for an event without wasting processing time in a while loop.) However - this only makes sense with a multitasking os which we actually do not have ;-)
yes, if you think about a synchronous / "blocking I/O" scenario.
However, you could always have something asynchronous: The caller calls something like sim_card_transceive(*message, *cb), and the driver calls back the 'cb' function when it has received the data.
I think the latter is the best we can do at the moment.
Another possible concept is to introduce some kind of message queue: The entity that wants to issue a command to the SIM sends a message into the queue, indicating to which other message queue any responses shall be queued to.
I agree the synchronous approach seems to be the more natural one (for most human beings at least). However, it comes at the cost of scheduling overhead/latency, new possibilities for deadlocks and potentially difficult debugging than in a single-threaded program.
Right now I don't really know yet how many threads/tasks we will end up having. I only know we should be careful and not to have too many of them. Layer2 is certainly going to be one task, Layer3 will have at least one. Layer3 is he entity that normally talks to the SIM, at least excluding things coming directly from the app like phonebook access and storing SMS.
The driver will get a function like sim_card_transceive(*message, *response) or so on because a transaction with the card will never be receive or send only. You always send something to the card and you always get something back.
If the caller does not care, he could simply specify a NULL pointer as *response.
We cross posted, you gave me more info, thanks. The async approach seems very nice here.
Sebastien
On Tue, Mar 9, 2010 at 4:24 PM, Harald Welte laforge@gnumonks.org wrote:
Hi dexter,
thanks for your update!
On Tue, Mar 09, 2010 at 03:12:47PM +0100, dexter wrote:
I have now getting interrupts and i am sending the first little APDUs to the card. I think i will have something that basicly works soon.
But up to now i think it will be impossible to save processing time during the transmission - wait phases without having semaphores (or something semilar that can be used to wait for an event without wasting processing time in a while loop.) However - this only makes sense with a multitasking os which we actually do not have ;-)
yes, if you think about a synchronous / "blocking I/O" scenario.
However, you could always have something asynchronous: The caller calls something like sim_card_transceive(*message, *cb), and the driver calls back the 'cb' function when it has received the data.
I think the latter is the best we can do at the moment.
Another possible concept is to introduce some kind of message queue: The entity that wants to issue a command to the SIM sends a message into the queue, indicating to which other message queue any responses shall be queued to.
I agree the synchronous approach seems to be the more natural one (for most human beings at least). However, it comes at the cost of scheduling overhead/latency, new possibilities for deadlocks and potentially difficult debugging than in a single-threaded program.
Right now I don't really know yet how many threads/tasks we will end up having. I only know we should be careful and not to have too many of them. Layer2 is certainly going to be one task, Layer3 will have at least one. Layer3 is he entity that normally talks to the SIM, at least excluding things coming directly from the app like phonebook access and storing SMS.
The driver will get a function like sim_card_transceive(*message, *response) or so on because a transaction with the card will never be receive or send only. You always send something to the card and you always get something back.
If the caller does not care, he could simply specify a NULL pointer as *response.
--
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
baseband-devel@lists.osmocom.org
-
dexter -
Harald Welte -
nibbler -
Sylvain Munaut -
Sébastien Lorquet