Anàlisi de rendiment i optimització en targetes SIM

id192693   ANÀLISI DE RENDIMENT I OPTIMITZACIÓ EN TARGETES SIM MARC ROCA CAMPOS Director/a ALEXPAJUELOGONZALEZ(Giesecke+Devrient) Titulació GrauenEnginyeriaInformàtica(Tecnologiesdelainformació) Memòria del treball de fi de grau Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 15/05/2025  Anàlisi de rendiment i optimització en targetes SIM Resum Les SIM (Subscriber Identity Module) són dispositius embedded amb dissenyats per a connectar-se a xarxes mòbils de manera segura i eficient. En aquest projecte és combat el problema de treballar en l’estudi i millora de temps d’execució d’aquests dispositius. Treballant amb el format de targeta. Es desenvolupen dues eines clau per estudiar el comportament de les SIM. La primera, és un perfilador per extreure traces de codi per a visualitzar amb Speedscope. La segona, Debug Timer, usa temporitzadors interns per mesurar temps en targeta. El projecte serà desenvolupat en SCRUM enterament per l’autor. Resumen Las SIM (Subscriber Identity Module) son dispositivos embedded diseñados para conectarse a redes móviles de manera segura y eficiente. En este proyecto se aborda el problema de estudiar y mejorar los tiempos de ejecución de estos dispositivos. Trabajando con el formato de tarjeta. Se desarrollan dos herramientas clave, utilizadas para estudiar el comportamiento de las SIM. La primera, es un perfilador para extraer trazas de código para visualizar con Speedscope. La segunda, Debug Timer, utiliza temporizadores internos para medir tiempos en tarjeta. El proyecto será desarrollado en SCRUM enteramente por el autor. Abstract SIM (Subscriber Identity Module) are embedded devices designed to securely and efficiently connect to mobile networks. This project addresses the problem of studying and improving execution times of these devices. Working with the card format. Two key tools are developed to study the behavior of SIM. The first tool is a profiler that extracts code traces for visualization in Speedscope. The second, Debug Timer, uses internal timers to measure time on cards. This project will be developed using SCRUM entirely by the author. 0 Anàlisi de rendiment i optimització en targetes SIM Taula de continguts 1. Introducció......................................................................................................................................... 5 1.1. Funcionament d’un targeta SIM.............................................................................................5 1.1.1. Comandes APDU.............................................................................................................................5 1.2. Image Trusted Loader (ITL)........................................................................................................7 1.3. Identificació del Problema........................................................................................................8 2. Abast.................................................................................................................................................... 9 2.1. Objectius..............................................................................................................................................9 2.1.1. Objectiu principal.......................................................................................................................... 9 2.1.2. Objectius secundaris..................................................................................................................9 2.2. Requeriments..................................................................................................................................9 2.2.1. Requeriments funcionals........................................................................................................9 2.2.1. Requeriments no funcionals...............................................................................................10 2.3. Stakeholders...................................................................................................................................10 2.4 Obstacles i riscs............................................................................................................................. 10 3. Justificació........................................................................................................................................ 11 3.1. Solucions actuals............................................................................................................................11 3.2. Justificació.........................................................................................................................................11 3.2.1. Creació d’eines de perfilació................................................................................................. 11 3.2.2. Millora de rendiment............................................................................................................... 12 4. Metodologia.................................................................................................................................... 13 4.1. Treball..................................................................................................................................................13 4.2. Seguiment....................................................................................................................................... 13 5. Planificació...................................................................................................................................... 14 5.1. Descripció de les tasques.........................................................................................................14 5.1.1. Gestió del projecte...................................................................................................................... 14 5.1.2. Mesura de rendiment.............................................................................................................. 14 5.1.3. Anàlisi de resultats......................................................................................................................15 5.1.4. Desenvolupament......................................................................................................................15 5.1.5. Resum.................................................................................................................................................16 5.2. Diagrama de Gantt......................................................................................................................17 5.3. Recursos............................................................................................................................................18 5.4. Gestió de riscs................................................................................................................................18 5.5. Desviació en planificació..........................................................................................................18 5.6. Estat final de les tasques......................................................................................................... 19 6. Gestió econòmica......................................................................................................................... 21 6.1. Pressupost.........................................................................................................................................21 6.1.1. Cost de personal............................................................................................................................21 6.1.2. Cost del Hardware..................................................................................................................... 22 6.1.3. Cost de l’espai............................................................................................................................... 23 6.1.4. Cost del Software.......................................................................................................................24 1 Anàlisi de rendiment i optimització en targetes SIM 6.1.5. Riscs.....................................................................................................................................................25 6.1.5. Total......................................................................................................................................................25 6.2. Control de gestió......................................................................................................................... 25 7. Sostenibilitat...................................................................................................................................27 7.1. Dimensió econòmica................................................................................................................. 27 7.2. Dimensió social.............................................................................................................................27 7.3. Dimensió mediambiental.......................................................................................................27 8. Arquitectura d’una targeta SIM.............................................................................................28 8.1. Processadors (SecureCore SC300/Cortex-M35P)....................................................... 28 8.1.1. Components en comú.............................................................................................................29 8.1.2. Diferències......................................................................................................................................30 8.2. Memòria Flash..............................................................................................................................30 8.3. Interfícies de comunicació..................................................................................................... 31 8.4. Components addicionals....................................................................................................... 33 9. Perfilació en targetes SIM........................................................................................................34 9.1. Perifèrics per la perfilació en processadors Cortex-M.............................................34 9.1.1. Data Watchpoint and Trace (DWT).................................................................................34 9.1.2. Embedded Trace Macrocell (ETM)..................................................................................35 9.1.3. Instrument Trace Macrocell (ITM)................................................................................... 35 9.1.4. Diagrama de les components de depuració amb ARM..................................35 9.2. Perfilació amb Keil µVision....................................................................................................36 9.2.1. Performance Analyzer.............................................................................................................37 9.2.2. Trace Recording.........................................................................................................................38 9.2.3. Funcions de depuració en Keil µVision......................................................................39 9.2.4. Simulació amb µVision - Instruction Set Simulators (ISS)...........................40 9.2.5. Avantatges i desavantatges del ISS de Keil............................................................40 9.2.3. Emulació amb µVision........................................................................................................... 41 9.2.4. Avantatges i desavantatges d’emulació amb Keil..............................................41 9.3. Simulació Software funcional de sistemes embedded.........................................42 9.3.1. Avantatges i desavantatges de simulació funcional......................................... 42 9.4. Tests usant lectors de targetes...........................................................................................42 9.4.1. Avantatges i desavantatges de tests usant lectors............................................43 9.5. Instrumentalització del codi en targetes SIM........................................................... 43 9.5.1. Instrumentalització per la mesura de temps......................................................... 43 9.5.2. Avantatges i desavantatges de la instrumentalització per la mesura de temps............................................................................................................................................................ 44 9.5.3. Instrumentalització per l’obtenció de traces.........................................................44 9.5.4. Avantatges i desavantatges de la instrumentalitzció per l’obtenció de traces..............................................................................................................................................................45 10. Descripció de la solució.......................................................................................................... 46 10.1. Conclusions................................................................................................................................... 46 10.2. Traces de codi per cada comanda.................................................................................. 46 2 Anàlisi de rendiment i optimització en targetes SIM 10.3. Mesura de temps.......................................................................................................................47 11. Speedscope................................................................................................................................... 48 11.1. Obtenció dels registres............................................................................................................48 11.1.1. Opcions de compilació...........................................................................................................49 11.1.2. Funcions hooks...........................................................................................................................49 11.1.3. Format d’emmagatzematge.............................................................................................49 11.1.4. Format de traces....................................................................................................................... 50 11.2. Funcionament de l’eina..........................................................................................................50 11.5. Anàlisi de traces...........................................................................................................................53 12. Debug Timer.................................................................................................................................54 12.1. Temporitzador Hardware en targetes SIM...................................................................54 12.2. Representació del temps...................................................................................................... 55 12.3. Funcionament.............................................................................................................................56 12.4. API pel programador...............................................................................................................56 12.5. Emmagatzematge i retorn dels valors..........................................................................57 12.6. Disseny............................................................................................................................................ 58 12.6.2. Diagrama UML..........................................................................................................................58 12.6.2. Principis Software en el disseny....................................................................................59 12.7. Exemple d’ús................................................................................................................................60 13. Mesures, anàlisi i millores....................................................................................................... 62 13.1. Mesura....................................................................................................................................62 13.2. Anàlisi dinàmic............................................................................................................................62 13.2.1. Codi segur......................................................................................................................................63 13.3. Compilació.....................................................................................................................................63 13.4. Anàlisi estàtic.............................................................................................................................. 64 14. Conclusions...................................................................................................................................65 14.1. Resum...............................................................................................................................................65 14.2. Compliment d’objectius........................................................................................................65 14.2.1. Objectiu Principal....................................................................................................................65 14.2.2. Objectius Secundaris........................................................................................................... 65 14.3. Assoliment de competències............................................................................................ 66 14.4. Adequació al coneixement del grau..............................................................................66 14.5. Treball futur..................................................................................................................................67 14.6. Opinió personal..........................................................................................................................67 15. Glossari............................................................................................................................................68 16. Bibliografia....................................................................................................................................70 3 Anàlisi de rendiment i optimització en targetes SIM Taula de taules Taula 1: Resum de tasques. Elaboració pròpia.............................................................................16 Taula 2: Estat actual del projecte. Elaboració pròpia..............................................................20 Taula 3: Sou mitjans dels rols. Elaboració pròpia.......................................................................21 Taula 4: Cost de les tasques. Elaboració pròpia.........................................................................22 Taula 5: Cost del Hardware. Elaboració pròpia........................................................................... 23 Taula 6: Cost de l’espai. Elaboració pròpia....................................................................................24 Taula 7: Cost del Software. Elaboració pròpia............................................................................. 25 Taula 8: Costs totals. Elaboració pròpia.......................................................................................... 25 Taula 9: Especificació targetes SIM del treball. Elaboració pròpia..................................28 Taula 10: Taula amb temps de memòria flash de STM32F1. Elaboració pròpia.........31 Taula 11: Format d’emmagatzematge de marques temps. Elaboració pròpia........ 58 Taula de figures Figura 1: Exemple d’APDU SELECT acord a especificació 3GPP......................................... 6 Figura 2: Diagrama del procés d’actualització amb ITL..........................................................8 Figura 3: Diagrama Gantt del projecte. Elaboració pròpia...................................................17 Figura 4: Components de processadors SC300 i M35P........................................................ 29 Figura 5: Interfície especificada per ISO/IEC 7816 per targetes SIM...............................32 Figura 6: Formats de targetes SIM, juntament amb eSIM...................................................33 Figura 7: Diagrama d’ETM i ITM en Cortex-M3........................................................................... 36 Figura 8: Finestra de Keil µVision en depuració de codi.......................................................37 Figura 9: Finestra de Performance Analyzer de Keil µVision.............................................38 Figura 10: Finestra de Instruction Trace de Keil µVision.......................................................39 Figura 11: ULINKpro, dispositiu per connectar ordinador a emulador...........................41 Figura 12: Interfície de l’eina Speedscope en inici................................................................... 48 Figura 13: Log en Speedscope mostrat de manera temporal.............................................51 Figura 14: Visualització del Log en format Left Heavy........................................................... 52 Figura 15: Visualització del Log en format Sandwich............................................................. 52 Figura 16: Diagrama UML del disseny de Debug Timer. Elaboració pròpia...............59 4 Anàlisi de rendiment i optimització en targetes SIM 1. Introducció Les SIM (Subscriber Identity Module) són el principal actor en telecomunicacions mòbil. Son secure elements (SE), definits com a xips que ofereixen protecció de dades i serveis usats per identificaciò, emmagatzematge segur de dades. En aquest cas el servei és d'autenticació a xarxa mòbil[32]. Habiten molts dispositius també com a sistemes incrustats; en aquest cas s'anomenen eSIM (Embedded SIM). Qualsevol dispositiu que es connecti a xarxes mòbils pot contenir eSIM; càmeres de seguretat, mòbils, cotxes[32]... 1.1. Funcionament d’un targeta SIM El propòsit d’usar una targeta SIM com autenticació en xarxa mòbil és aïllar lA informació i processos d’atacs i errors. Per a dur a terme aquesta tasca tenen un microcontrolador al centre d'aquestes, un circuit integrat amb tots els elements necessaris per executar un programa; memòria, processador i perifèrics de comunicació amb l'exterior. Aquests són de mida i capacitats reduïdes, compten de molt poca memòria, processadors lents i d’instruccions simples[41]. 1.1.1. Comandes APDU Les targetes SIM contenen un sistema operatiu encarregat de gestionar els serveis que ofereix. La unitat de comunicació és la comanda Application Protocol Data Unit (APDU), estructura definida en estàndard ISO/IEC 7816[45]. Les comandes APDU són missatges enviats per lectors de targetes que encapsulen comandes. Formats per una capçalera de 5 bytes codificant instrucció i classe de la comanda, i fins a 255 bytes de dades opcionals. La capçalera conté el següent format. ● CLA (Class). Byte codificant la classe de comanda. ● INS (Instruction). Byte codificant la instrucció de la comanda. ● P1 (Parameter 1). Byte codificant informació particular de la comanda. ● P2 (Parameter 2). Byte codificant informació particular de la comanda. ● Lc (Lenght of Command Data) . Byte codificant la mida del payload (tràiler) amb dades. Seguit de la capçalera tenim. ● Data. Payload opcional contenint dades de la comanda. Tamany codificat per Lc. ● Le (Expected Response Length). Byte opcional codificant el número de bytes esperat en la resposta. 5 Anàlisi de rendiment i optimització en targetes SIM En resposta de la comanda, la targeta retornarà un missatge APDU response amb el següent format. ● Data. Payload (tràiler) opcional contenint dades de la resposta. Tamany codificat pel paràmetre Le. ● SW (Status Word). Missatge resposta de la comanda codificat en 2 bytes. En la figura veiem d’exemple una instrucció de Select del Master File (MF), sense Le[24]. Figura 1: Exemple d’APDU SELECT acord a especificació 3GPP. Una resposta típica de la targeta seria respondre 90 00. Aquest és el missatge més comú per comanda executada satisfactòriament. Exemples de les comandes APDU més comunes, per l’especificació de ISO 7816 són[45]. ● SELECT. Selecciona fitxer o aplicació. ● READ BINARY. Llegeix contingut de fitxer. ● UPDATE BINARY. Actualitza contingut de fitxer. ● GET DATA. Llegeix contingut de dades identificades per etiqueta (tag). ● EXTERNAL AUTHENTICATE. Autentica la targeta usant valor únic generat en la sessió. ● VERIFY. Verifica PIN o contrasenya. ● GET RESPONSE. Retorna més dades en cas que l’anterior comanda APDU tingui més dades disponibles (la targeta respon amb SW 61 XX, on XX és el nombre de bytes pendents). 6 Anàlisi de rendiment i optimització en targetes SIM 1.2. Image Trusted Loader (ITL) El sistema operatiu ha de ser carregat al xip. També és necessari incloure dades úniques per la targeta o família d'aquestes. Aquest procés s'anomena personalització. Les dades són emmagatzemades en el procés de producció de la targeta. Exemples comuns de dades carregades en la personalització són aplicacions o claus per identificar els usuaris[35]. Com qualsevol altre dispositiu amb Software, és vulnerable a errors o necessita actualitzacions. Per actualitzar el sistema operatiu sense necessitat de recollir físicament les targetes, a Giesecke+Devrient es va desenvolupar un update agent o ITL (Image Trusted Loader). A més, aquest procés permet guardar i recuperar en la nova versió les dades de la personalització, que són produïdes en un entorn segur (aquestes no poden ser modificades). Farem servir el terme ITL i update agent indistintament[36]. Els passos que segueix el ITL per actualitzar el sistema operatiu són. ● El ITL pren control de la SIM. ● Rep una imatge (programa en format executable) del sistema operatiu a través de comandes APDU i la càrrega al secure element. ● La imatge s’instal·la actualitzant el sistema operatiu. ● En un pas final el ITL retorna el control al nou sistema operatiu de la SIM. En el següent diagrama veiem aquest procés[7]. 7 Anàlisi de rendiment i optimització en targetes SIM 5. Planificació En aquest apartat es profunditzarà en la planificació temporal del projecte. Inicia el 23 de setembre amb data final de presentació el 24 de gener de 2025. Primerament, la part de gestió de projectes ocuparà de l’inici del projecte el 23 de setembre fins a fi d’assajar la presentació, s’estima tenir llesta aquesta el 15 de gener. Les 2 primeres setmanes fent el plantejament seran 20 hores setmanals. La redacció de la memòria seran 80 hores en total, és treballarà finsa la setmana de l’entrega segons avanci el projecte. La preparació de la presentació seran 30 hores totals. En total 170 hores. La part més tècnica del projecte es treballarà, majoritàriament, entre-setmana dins les oficines de Giesecke+Devrient del 14 d’octubre al 13 de desembre. Es dedicarà de mitjana 20 hores setmanals de feina en oficines, un total de 200 hores fixes. Complementada d’estudi 20 hores d’estudi addicional. 5.1. Descripció de les tasques Les tasques estan dividides en grups segons la naturalesa de la tasca, cada un dels següents subapartats conté un tipus. 5.1.1. Gestió del projecte Totes les tasques de gestió de projecte seran treballades en remot. ● GP1 - Planejament inicial. Primera tasca. Comença amb l’estudi del context, definició d’abast del projecte. Seguidament de la planificació. En darrera instància estudi de sostenibilitat i pressupost. Són les tasques a entregar en la primera entrega de GEP. Es planeja dedicar 20 hores durant tres setmanes, un total de 60 hores. ● GP2 - Memòria. Redacció del document per l’entrega final, des de la setmana de l’entrega de GEP s’espera dedicar 80 hores en total. Existeix dependència amb GP1 - Plantejament inicial. ● GP3 - Lectura del Treball. Es dedicarà 10 hores setmanals al llarg de tres setmanes (30 en total) a preparar presentació; incloent-hi creació d’aquesta i assaig. Existeix dependència amb GP2 - Memòria. 5.1.2. Mesura de rendiment Primer pas en el projecte és la mesura de rendiment, sense les eines adequades i coneixement del rendiment real no es pot treballar cap de les altres tasques. ● MR1 - Investigació de solucions actuals. Analitzar en profunditat les solucions actuals. De resultat s’extraurà solucions que es desenvoluparà en 14 Anàlisi de rendiment i optimització en targetes SIM el següent pas. La durada serà de 10 hores, aquest treball serà enterament remot. Existeix dependència amb GP1 - Plantejament inicial, necessita acabar aquest per començar a treballar. ● MR2 - Desenvolupament d’eines de perfilament. Disseny i desenvolupament de les eines que s’usaran per mesurar el rendiment del Sistema Operatiu. Durada de 50 hores en les oficines. Existeix dependència amb MR1 - Investigació de solucions actuals, abans de fer el disseny és necessita saber el tipus d’eines que s’han de desenvolupar. ● MR3 - Presa i automatització de resultats. Creació d’eina per poder recollir i visualitzar els resultats fàcilment. Alhora documentar el procés i resultats extrets. S’invertiran unes 15 hores in situ. Existeix dependència amb MR2 - Desenvolupament d’eines de perfilament, es necessita l’eina primer. 5.1.3. Anàlisi de resultats Un cop s’ha obtingut resultats és necessitarà traçar un pla. Aquí s’analitzaran possibles solucions i millores a alt nivell i s’indagarà en compiladors. ● AR1 - Anàlisi dinàmica. Com anteriorment esmentat aquest analitza en profunditat el flux del codi. Un cop conegudes les parts del codi que consumeixen més temps s’analitzarà la solució actual i es pensarà en possibles estratègies de millora de rendiment, cada una d’aquestes constarà d’un tiquet. S’invertiran unes 50 hores. Totalment treballat en oficines. Existeix dependència amb MR3 - Presa i automatització de resultats. ● AR2 - Anàlisi del compilador. El compilador és una eina clau per la millora de qualsevol codi. S’investigarà la solució actual, possibles millores i estratègies a aplicar. Seran 10 hores en remot. Existeix dependència amb MR3 - Presa i automatització de resultats per començar a mesurar l’impacte real de les diferents opcions de compilació. 5.1.4. Desenvolupament Les últimes tasques seran treballar amb l’anàlisi prèviament feta i mesurar millores. ● DV1 - Aplicació de millora dinàmica. Dels diferents tiquets creats en l’anàlisi es desenvoluparan les diferents propostes i mesurarà l’impacte. Invertirem 40 hores en aquest. Existeix dependència amb AR1 - Anàlisi dinàmica. ● DV2 - Aplicació de millora del compilador. Diferents estratègies i mesura del rendiment. Es treballarà 15 hores in situ. Té dependència amb tasca AR2 - Anàlisi del compilador. 15 Anàlisi de rendiment i optimització en targetes SIM ● DV3 - Millora estàtica. Tant les funcions més accedides com les que consumeixen més temps seran analitzades estàticament en profunditat, això es farà mirant el codi compilat i original. S’estarà 30 hores en aquesta part del projecte in situ. Existeix dependències amb DV1 - Aplicació de millora dinàmica i DV2 - Aplicació de millora del compilador, ja que es pretén estudiar el codi màquina. 5.1.5. Resum La següent taula conté totes les tasques, dependències i temps total. ID Tasca Hores Dependències GP Gestió del projecte 170 - GP1 Plantejament inicial 60 - GP2 Memòria 80 GP1 GP3 Lectura del Treball 30 GP2 MR Mesura del rendiment 75 - MR1 Investigació de solucions actuals 10 - MR2 Desenvolupament d’eines de perfilament 50 MR1 MR3 Presa i automatització de resultats 15 MR2 AR Anàlisi de resultats 60 - AR1 Anàlisi dinàmica 50 MR3 AR2 Anàlisi del compilador 10 MR3 D Desenvolupament 85 - D1 Aplicació de millora dinàmica 40 AR1 D2 Aplicació de millora del compilador 15 AR2 D3 Millora estàtica 30 D1, D2 Taula 1: Resum de tasques. Elaboració pròpia. 16 Anàlisi de rendiment i optimització en targetes SIM 5.2. Diagrama de Gantt De l’anterior taula deriva el següent diagrama. Elaborat amb l’eina GANTTproject. Figura 3: Diagrama Gantt del projecte. Elaboració pròpia. És pot apreciar que els Sprints comencen el 14 d’octubre. L’única tasca que queda partida entre Sprints és l’anàlisi dinàmica, que es dividirà en 2 tiquets. Un petit desnivell en hores treballada en alguns Sprints per acomodar les tasques. 17 Anàlisi de rendiment i optimització en targetes SIM 5.3. Recursos En primera instància, el projecte serà dut enterament per l’autor, assumirà els rols de gestió i desenvolupament. El rol dels responsables dins Giesecke+Devrient i l’UPC serà de seguiment del projecte, amb reunions esporàdiques. Primerament, el Hardware, en oficines comptaré amb ordinador propietat de l’empresa, lectors de targetes SIM i les targetes. A casa, treballaré amb ordinador personal usant Windows. El Software usat fora d’oficines serà Google Meet, Google Drive, GanttProject. La documentació es farà mitjançant Google Docs. Dins l’àrea de l’empresa s’utilitzarà eines com Jira, Git i Confluence per documentació. En última instància, es farà servir també programari propi pel desenvolupament de sistemes operatius en targetes SIM. 5.4. Gestió de riscs Essencial per qualsevol projecte és preveure accidents i adaptar a imprevists. ● Endarreriments. El principal risc a causa de la dependència d'implementacions amb anàlisi i creació d'eines. Com es treballa amb metodologia àgil, si és necessari és possible modificar el pla. Si s'hi haguessin de retallar hores d'alguna tasca seria primerament d'anàlisi estàtica i, en cas de fer falta, en segon lloc, la millora i anàlisi de compilador. ● Errors. Risc mitjà. El testing ha de ser rigorós, ja que el ITL forma part d’un secure element i tracta amb dades i processos sensibles. L’aparició d'errors és comú en qualsevol desenvolupament, normalment el sistema operatiu ofereix protecció d'errors de codi, pel fet que gestiona tots els recursos del Hardware. S’ha de mantenir un bon històric de commits. Per sort, facilitarà la feina el fet de reballar sobre un sistema ja funcionant i amb tests. ● Complexitat. Risc mitjà. La complexitat de la tecnologia i processos poden causar que el projecte sigui molt més difícil del que s'ha estimat. Pot ser que no es trobi bona solució de perfilament i l'anàlisi sigui limitat. Si es donés el cas, s’hauría de reavaluar els objectius i tasques del projecte. ● Falls de Hardware. Suposen un risc mínim. Tot es treballa en servidors i existeixen backups. Pel que fa a les targetes SIM sempre se’n té una quantitat extra al poc cost que tenen. 5.5. Desviació en planificació Hi ha hagut desviacions grans respecte al plantejament inicial. Tot comença en el desconeixement previ a l’inici del projecte, una contextualització no prou profunda ha ocasionat en la infravaloració de la tasca 18 Anàlisi de rendiment i optimització en targetes SIM d’analitzar les eines de perfilament en Hardware embedded, això a conseqüència de tenir un parell d’anys d’experiència embedded en l’empresa. Per això s’ha canviat també el títol del treball de “Optimització en actualitzacions de sistemes operatius embedded” a “Anàlisi de rendiment i optimització en Targetes SIM”. Solucions existien, però cap era compatible amb la tecnologia de targetes SIM a cause principalment de la interfície ISO 7816-2 i varietat de models d’aquestes. S’ha intentat contendre amb varies eines pròpies de fabricants, inicialment considerant fer una solució sobre complicada instrumentalitzant Keil. Finalment, s’ha decidit que la millor opció era crear 2 eines separades i més senzilles per prendre traces i temps. La part de la creació d’eines ha sigut la que ha consumit més temps del projecte i ha sigut la que ha donat millors resultats. Un cop creat les eines de mesura de rendiment, també s’ha infravalorat els resultats que es podien extreure de l’anàlisi. El update agent compta de diferents components. Els resultats són privats, però majoritàriament s’ha vist que el cost en protocols de comunicació i escriptura de memòria és menja gran part del temps inevitablement, i existeix conflictes en capes de seguretat amb l’eficiència. A mencionar de la tasca d’anàlisi estàtica, que també ha donat pocs resultats. La major part de les vegades s’aconseguia temps negligibles. Potser, en altres productes més petits hi hauria impacte, però en aquest cas els resultats eren escassos. La tasca de compilació va ser ràpidament desestimada. Fent inicialment proves d’empènyer al màxim l’optimització del codi s’han apreciat canvis petits, alentint tot el procés de Build. Llavors, s’ha desestimat (com més alt el nivell de compilació, major el temps d’aquest). Últim aspecte que s’ha sobrevalorat, és la velocitat de redacció. Sembla una estimació correcta, però ha pres bastant temps la recerca i documentació per ser tòpic molt poc documentat, més la pròpia lentitud de l’autor en redactar. Comptant tots els retards, sobretot amb la redacció, s’han excedit les hores de projecte. Però entrarà dins el risc reservat de 12,5% en l’apartat 6.1.5. Riscs. 5.6. Estat final de les tasques La taula a continuació mostra l’estat actual de les tasques. La columna d’hores reals mostra. ● Tasca a temps. En cas de de finalitzar-se en data prevista. ● Tasca amb retràs. En cas de no finalitzar-se amb data prevista. ● Tasca desestimada. Degut a l’anàlisi previ s’ha desestimat la tasca. 19 Anàlisi de rendiment i optimització en targetes SIM La tasca de GP3 - Lectura del Treball ha sigut omesa, ja que la presentació és posterior a la memòria. ID Tasca Hores estimades Hores reals GP Gestió del projecte 140 160 GP1 Plantejament inicial 60 60 GP2 Memòria 80 100 MR Mesura del rendiment 75 100 MR1 Investigació de solucions actuals 10 40 MR2 Desenvolupament d’eines de perfilament 50 50 MR3 Presa i automatització de resultats 15 10 AR Anàlisi de resultats 60 45 AR1 Anàlisi dinàmica 50 40 AR2 Anàlisi del compilador 10 5 D Desenvolupament 85 50 D1 Aplicació de millora dinàmica 40 40 D2 Aplicació de millora del compilador 5 0 D3 Millora estàtica 30 10 - Total 390 355 Taula 2: Estat actual del projecte. Elaboració pròpia. 20 Anàlisi de rendiment i optimització en targetes SIM 6. Gestió econòmica A continuació es calcularà el pressupost del projecte; material i recursos humans. 6.1. Pressupost 6.1.1. Cost de personal Es dividirà el projecte en 4 rols: ● Cap de projecte. Encarregat d’organitzar, planejar i monitorar el progrés del projecte. ● Desenvolupador Embedded. Dura a terme les tasques de desenvolupament i anàlisi del codi del xip. ● Tester. Encarregat de testejar. Revisar tot desenvolupament d’eines i solucions noves. També de documentar i analitzar els resultats. ● DevOps. Encarregat d’automatització i unificació de processos. Important per desenvolupar les eines necessàries per mesurar el rendiment del xip. El sou dels diferents rols serà extret del portal GlassDoor[37], aquesta reporta valor mitjà de treballadors reals anual en Espanya i serà dividit per 2080 hores[27] que són jornada completa. Llavors al sou extret s’afegirà una aproximació de Seguretat Social multiplicant per 1,3. S’obtenen els següents resultats. Rol Sou brut (€/h) Sou total (€/h) CP - Cap de projecte 17,79 23,13 DE - Desenvolupador Embedded 16,34 21.24 T - Tester 10,58 13.75 DO - DevOps 17,31 22.50 Taula 3: Sou mitjans dels rols. Elaboració pròpia. 21 Anàlisi de rendiment i optimització en targetes SIM Llavors, d’acord amb les tasques definides, el cost total de les tasques en recursos humans s’aprecia en la següent taula. ID Tasca Hores Cost (€) Total CP DE T DO GP Gestió del projecte 170 125 15 15 15 3.732,36 GP1 Plantejament inicial 60 45 5 5 5 1.307,06 GP2 Memòria 80 50 10 10 10 1.731,40 GP3 Lectura del Treball 30 30 0 0 0 693,90 MR Mesura del rendiment 75 0 15 5 45 1.624,85 MR1 Investigació de solucions actuales 10 0 0 0 10 225,00 MR2 Desenvolupament d’eines de perfilament 50 0 15 0 35 1.106,10 MR3 Presa i automatització de resultats 15 0 0 5 10 293,75 AR Anàlisi de resultats 60 0 50 10 0 1.167,80 AR1 Anàlisi dinàmica 50 0 40 10 0 987,10 AR2 Anàlisi del compilador 10 0 10 0 0 212,40 D Desenvolupament 85 0 78 12 0 1.715,52 D1 Aplicació de millora dinàmica 40 0 35 5 0 812,15 D2 Aplicació de millora del compilador 15 0 13 2 0 303,62 D3 Millora estàtica 30 0 25 5 0 599,75 Total 390 125 158 42 60 8.240,53 Taula 4: Cost de les tasques. Elaboració pròpia. 6.1.2. Cost del Hardware Aquest apartat no reflectirà el material usat en Giesecke+Devrient, si no s’usarà material genèric de desenvolupament. Per targetes SIM, primer s’emprarà lectors genèrics marca Omnikey. S’aproximarà el cost de les targetes utilitzant un model genèric per usos industrials, ja que els preus reals no són públics. 22 Anàlisi de rendiment i optimització en targetes SIM El cost d'amortització es calcularà usant vida mitjana d’un portàtil, de 4 anys d’ús[31]. Es deriva la següent fórmula. 𝐴𝑚𝑜𝑟𝑡𝑖𝑡𝑧𝑎𝑐𝑖ó = 𝐶𝑜𝑠𝑡 * ℎ𝑜𝑟𝑒𝑠 𝑑'ú𝑠 𝑉𝑖𝑑𝑎 ú𝑡𝑖𝑙 (𝑎𝑛𝑦𝑠) * ℎ𝑜𝑟𝑒𝑠 𝑙𝑎𝑏𝑜𝑟𝑎𝑏𝑙𝑒𝑠 𝑎𝑛𝑢𝑎𝑙𝑠 Obtenint les hores laborables anuals en apartat anterior[27], la fórmula és simplifica. 𝐴𝑚𝑜𝑟𝑡𝑖𝑡𝑧𝑎𝑐𝑖ó = 𝐶𝑜𝑠𝑡 * 390 4 * 2080 𝐴𝑚𝑜𝑟𝑡𝑖𝑡𝑧𝑎𝑐𝑖ó = 𝐶𝑜𝑠𝑡 *0. 046875 El total llavors es reflecteix en la següent taula. El cost de les targetes serà comptat al complet, a causa de l’extens ús que pateixen en desenvolupament. Hardware Cost (€) Amortització (€) Cost en Projecte (€) Portàtil Lenovo IdeaPad Slim 3[56] 549,00 25,73 25,73 Pack teclat + ratolí Bluetooth - HP[55] 29,99 1,40 1,40 Monitor IPS Samsung 27”[54] 99,00 4,64 4,64 3 x Lector targetes SIM Omnikey 3121[1] 71,97 3,37 3,37 6 x targetes SIM[28] 33,42 - 33,42 Total 816,80 35,14 68,56 Taula 5: Cost del Hardware. Elaboració pròpia. 6.1.3. Cost de l’espai Primer s’aproximarà el cost de l’espai, usant valors genèrics a Barcelona, a continuació el cost de material d’oficina. El volum mínim per treballador en oficines d’acord amb el Decret Real 486/1997 estipula mínim 10 metres quadrats per treballador no ocupats, i 2 metres de superfície lliure, un total de 12 metres quadrats[43]. Aproximant a 15 metres quadrats d’oficina per cautela resulta en 259,05 euros de cost mensual prenent el cost de lloguer mitjà de Barcelona en agost 2024 de 17,27 euros el metre quadrat[2]. Partint de la mitja de 15 metres quadrats s’obté un consum elèctric de 65.62 Kwh mensual dels 15 metres, partint de consum anual de 52,5 Kwh/m2[30]. Sent el preu de la llum en agost 2024 0,1463 €/KWh[26], el total resulta en 9,59 € mensuals. 23 Anàlisi de rendiment i optimització en targetes SIM ● Conjunt d’instruccions Thumb o Thumb-2. Thumb compta amb instruccions de 16 bits, juntament amb un conjunt equivalent d’instruccions 32 bits ARM. Està compost per les instruccions ARM de 32 bits més comunes. Per executar una o altra el processador té dos estats d’execució; ARM o Thumb. El mode Thumb opera amb valors més petits, però és més ràpid[17]. Thumb-2 és extensió de Thumb que afegeix algunes instruccions de 32 bits amb interoperabilitat amb les de 16 bits. També, introdueix condicionalitat a la majoria d’instruccions d’ARM[18]. ● Mesures de protecció Hardware. Per protegir contra atacs físics, com manipulació del voltatge o atacs amb làser per provocar errors. ● System timer (SysTick). Temporitzador de 24 bits que compta enrere des de valor en el registre de refresc a 0, amb capacitat d’induir interrupció en assolir aquest valor[14]. ● Integrated Nested Vectored Interrupt Controller (NVIC). Permet la configuració d’interrupcions i rutines d’interrupcions d’aquestes[12]. ● Wakeup Interrupt Controller (WIC). Controlador per despertar el processador en estat de dormir, rellevant per protocols de comunicació[16]. ● Memory Protection Unit (MPU). Permet definir regions de memòria i els permisos de lectura, escriptnvura i execució[15]. ● ETM (Electro Trace Macrocell), Instrumentation Trace (ITM). Components opcionals de perfilació. No estan implementats per cap de les targetes amb què es treballa, però s’expliquen en més detall en el següent apartat Perifèrics per la perfilació en processadors Cortex-m. ● Joint Test Action Group (JTAG) i Serial Wire. Ports i interfícies opcionals per poder depurar. Permeten la configuració de Breakpoints i Watchpoints. No estan implementats per cap de les targetes amb què es treballa, rellevants pel funcionament de les eines en l’apartat Perifèrics per la perfilació en processadors Cortex-m. 8.1.2. Diferències Les principals diferències deriven de que SC300 és un chip més antic. En primer lloc, el conjunt d’instruccions és Armv7-M per SC300, mentre que M35P és Armv8-M with Mainline extension. El darrer inclou instruccions addicionals[3]. Altres diferencies són menors, M35P conté més mesures de seguretat, cache opcional d’instruccions, opcionalment eines de procés de senyals digitals, etc. 8.2. Memòria Flash La memòria flash és memòria NVM (Non-Volatile Memory), és a dir, memòria que emmagatzema dades que no són perdudes en reinici del xip (pèrdua de corrent), a diferència de memòria RAM (Random Access Memory). La terminologia difereix 30 Anàlisi de rendiment i optimització en targetes SIM respecte a microcontroladors, i la font serà especificacions de les targetes SIM mencionades precedentment. Per ambdós processadors tant dades com codi resideixen en la mateixa memòria. Això implica que el sistema operatiu i les dades que guarda residiran en flash. La memòria NVM es divideix en pàgines. L’estat inicial d’una pàgina és esborrat, és quan tots els seus bits tenen el valor 1. Escriure en una pàgina comporta transformar els dígits 1 en 0. L’escriptura té granularitat bit, short o word. En contrast, l’esborrament transforma els zeros en uns i la granularitat és en pàgina. Mides típiques de pàgina per targetes SIM oscil·len els 128 a 512 bytes. Les operacions en flash són lentes i suposaran un cul d’ampolla pel rendiment. Per la confidencialitat temps específics no poden mostrar-se, però agafant de referència un microcontrolador d’especificacions similars. En la següent taula estan els temps d’escriptura i esborrat pel microcontrolador STM32F1. S’ha escollit per usar processador Cortex-M3[74]. Taula 10: Taula amb temps de memòria flash de STM32F1. Elaboració pròpia. Cura de no confondre bit amb byte. També no caure en la trampa què 1 MiB equival a 1024 KB, a diferència de 1 MB que són 1.000 KB, però STM usa la represaentació binària amb el acrònim i nom de la decimal[75]. Tot i que tots els temps agafats són el pitjor cas, ja es pot veure una limitació en la tecnologia d’aquestes. Els microcontroladors no són xips optimitzats per a tractar amb processament de moltes dades. Els temps calculats per 1 MB, així mateix, no compta amb el temps derivat del processament entre escriptures i esborrats. 8.3. Interfícies de comunicació Existeixen múltiples protocols de comunicació implementats en els microcontroladors esmentats. Això no significa que totes les interfícies estiguin implementades per tots els productes. Per exemple, en targetes SIM el format principal és l’especificat per ISO/IEC 7816, amb el que es treballarà. En el següent diagrama s’aprecia la interfície ISO/IEC 31 Operació Mida mínima Temps màxim per mida mínima Temps per 1 MB Escriptura (tprog) 2 B 70 μs 36.700.160 μs (~36,7 s) Esborrat (tERASE) 1024 B 40.000 μs 40.960.000 μs (40,96 s) Esborrat + escriptura 1024 B 75.840 μs 77.660.160 μs (~77,67 s) Anàlisi de rendiment i optimització en targetes SIM 7816 amb els pins de control, implementada tant per USB com per ISO/IEC 7816-3[44]. Figura 5: Interfície especificada per ISO/IEC 7816 per targetes SIM. Les parts més importants del protocol són. ● En encendre la targeta aquesta envia un ATR (Answer to Reset) amb paràmetres del protocol de comunicació com freqüència de rellotge de comunicacióm voltatge, etc. ● Existeixen 2 protocols de transmissió de bytes. T=0 transmet bytes individualment, T=1 transmet bytes per paquets. ● L’especificació defineix la comanda de comunicació és APDU. Format vist en l’apartat 1.1.1. Comandes APDU. Com a exemple contrari, en canvi, una embedded SIM esta soldada a un dispositiu major, llavors no tindrà implementada aquesta interfície (implementa l’interfície I2C). En la següent figura es mostren els diferents formats de targetes, juntament amb embedded SIM (eSIM)[46]. 32 Anàlisi de rendiment i optimització en targetes SIM Figura 6: Formats de targetes SIM, juntament amb eSIM. 8.4. Components addicionals Exemples rellevants de components addicionals són. ● Memòria RAM. En taula 9 reisdeixen el tamany de les memòries RAM de targetes SIM del treball. El valor ronda els 40 a 80 KB. ● Perifèrics per assistir en criptografia. Ja que el cost de les operacions criptogràfiques és generalment alt, algunes contenen perifèrics per assistir en aquestes. Exemples són coprocessadors per algoritmes AES o DES en targetes SLI37CMA1M0 o el generador de nombres aleatoris en ST33K1M5A. ● Temporitzadors. Totes les targetes compten amb més temporitzadors que SysTick, per assistir en tasques de seguretat o comunicació. 33 Anàlisi de rendiment i optimització en targetes SIM 9. Perfilació en targetes SIM En aquest apartat s’estudiaràn les diferents solucions per perfilació en targetes SIM. Essencialment, es volen conèixer 2 dades, en primera instància temps d’execució, en segona les crides i sortides de funcions per poder analitzar en profunditat el flux de codi. Primerament, dos conceptes clau per l’apartat són. ● Instrumentalització. La instrumentalització és la tècnica d’injectar codi per extreure informació del comportament d’un programa o aplicació. Tècnica fonamental per assolir els objectius. ● Simulació d’embedded Software. Procés de replicar el funcionament d’un sistema embedded, amb l’objectiu d’imitar com es comporta el sistema en execució de codi sense necessitat de tenir els dispositius en mà. En el primer apartat aplacarà les components de perfilació dins el xip, la resta les diferents opcions per perfilar. 9.1. Perifèrics per la perfilació en processadors Cortex-M En l’apartat 8.1. Processadors (SecureCore SC300/Cortex-M35P) s’ha esmentat breument els perifèrics dels processadors Cortex-M3 per depurar. Aquestes no estan implementades per targetes com anteriorment esmentat, a causa que el nexe de comunicació són els pins de la interfície ISO-7816. No obstant, si estan implementats per simuladors i emuladors, per això. Llavors, seran explicats breument. 9.1.1. Data Watchpoint and Trace (DWT) El Data Watchpoint and Trace (DWT) és un mòdul del processador contenint diverses funcionalitats de debugging. Rellevant per traçar el codi conté les següents funcionalitats[7]. ● Permet mostreig del registre apuntant a l’actual instrucció executant-se, el Program Counter (PC). Llegeix el PC periòdicament per reconstruir el flux d’execució, amb freqüència configurada en registre DWT_CTRL. Depèn del xip si permet mostrejar en cada cicle. ● Mesura els cicles del processador. Com aspecte positiu, és la facilitat d’ús per operar. Però és més limitat, ja que fa de mostreig en comptes d’operar amb els cicles del processador, i té un ample de banda més baix que ETM, explicat seguidament. 34 Anàlisi de rendiment i optimització en targetes SIM 9.1.2. Embedded Trace Macrocell (ETM) L’Embedded Trace Macrocell (ETM) és un mòdul del processador que proporciona instruccions i dades derivades d’un processador. Els principals elements d’un ETM són[11]. ● Generació de traces. Generació d’entrades i sortides de funcions a temps real, captura cada instrucció executada per la CPU. ● Filtratge i Triggers. Permet filtrar els resultats i especificar quines accions o requisits són necessaris per a la generació de traces. Com l’ample de banda és més gran, requreix de component específica per transport de les dades, anomenat Trace Port Analyzer (TPA). 9.1.3. Instrument Trace Macrocell (ITM) L’Instrument Trace Macrocell (ITM) és un mòdul del processador encarregat de la generació de missatges i esdeveniments, permet depurar codi en estil printf per rastrejar esdeveniments i generar informació de diagnòstic del sistema[8]. 9.1.4. Diagrama de les components de depuració amb ARM En darrera instància, en la següent figura es mostra l’estructura de les components estudiades de depuració en processadors ARM[9]. CTI és sigles de Cross Trigger Interface, component encarregada de coordinar esdeveniments entre les diferents components de depuració. ATB són les sigles de Advanced Trace Bus. Finalment, TPIU és Trace Port Interface Unit, component encarregada de formatar i enviar els missatges d’ETM i ITM al PC. CoreSight és el nom d’aquesta tecnologia. 35 Anàlisi de rendiment i optimització en targetes SIM Figura 7: Diagrama d’ETM i ITM en Cortex-M3. 9.2. Perfilació amb Keil µVision Keil MDK (Microcontroller Development Kit) és un conjunt d’eines de desenvolupament per microcontroladors ARM. Entre elles, existeix Keil µVision, la qual és un entorn integrat de desenvolupament (en anglès Integrated development environment, IDE) oferint eines per simular i depurar amb emulador les targetes SIM[19]. En la figura venidora, es mostra la interfície del programa en depuració de codi. A recalcar les funcionalitats següents, que no són les úniques oferides per Keil, opcions de control de l’execució, valors dels registres, codi màquina (Dissassembly) i codi font sent executat, pila de funcions, visualització de continguts de memòria[48]. 36 Anàlisi de rendiment i optimització en targetes SIM Figura 8: Finestra de Keil µVision en depuració de codi. 9.2.1. Performance Analyzer Keil µVision conté l’eina Performance Analyzer que ens deixa estudiar el temps d’execució en relació als mòduls (fitxers objecte) o funcions. En la figura a continuació, es mostra la visualització de l’eina en un exemple donat per Keil. El mòdul Serial és 95 % del temps d’execució, dins d’aquest, la funció getkey és responsable del 93 % del total de temps d’execució amb un total de 2 crides[50]. 37 Anàlisi de rendiment i optimització en targetes SIM Figura 9: Finestra de Performance Analyzer de Keil µVision. El Performance Analyzer és limitat, ja que només mostra temps d’execució i nombre de crides. En cas de desitjar una anàlisi profunda del flux del codi és necessari d’eines addicionals. 9.2.2. Trace Recording Keil µVision conté eina addicional per anàlisi de l’execució, Trace Recording, permet guardar un rècord de les instruccions executades. A continuació es mostra d’exemple d’una traça de codi. La primera columna mostra el número de l’execució de la instrucció, seguidament de l’adreça i informació d’aquesta, la primera és BPL (Branch if Plus), emmagatzemada en la direcció 0x00000158[49]. 38 Anàlisi de rendiment i optimització en targetes SIM Figura 10: Finestra de Instruction Trace de Keil µVision. El registre d’execució pot ser importat a fitxer text, copiant i enganxant. Performance Analyzer és una eina potent, que dona molta informació sobre el codi executat. Això sí, no està formatada de manera que sigui llegible per execucions grans, una eina hauria de ser necessitada de desenvolupar. 9.2.3. Funcions de depuració en Keil µVision Keil µVision permet l’execució de Scripts de depuració en el codi. Aquests són referits com INI scripts. Els INI scripts s’executen des del PC i no el xip, llavors no poden ser afegits directament en el codi font, però si permeten la definició de Breakpoints i funcions per executar en aquests[20]. Primer, s’ha de definir una funció de depuració. Com a exemple, a continuació es mostra, usant les comandes FUNC i LOG, funció per emmagatzemar contingut de direcció específica (com a valor uint32_t) en un fitxer anomenat log.txt[21]. // Funció per emmagatzemar contingut en 0x20000000. FUNC LogFunction() { LOG >> "C:\log.txt" "%08X", *(uint32_t*)0x20000000 } Configurar un Breakpoint és possible amb la comanda BreakSet, exemples d’ARM. En que afegim un a la funció main per cridar al mètode creat anteriorment[21]. // Configura Breakpoints. 39 Anàlisi de rendiment i optimització en targetes SIM 10. Descripció de la solució L’objectiu de perfilar el codi és per obtenir aquestes dues dades. ● Traces de codi per cada comanda. Les traces ens permeten una anàlisi del flux del codi en profunditat. ● Mesurar temps d’execució. Volem podem comparar diferents solucions i saber quines parts de cada comanda ofereixen millor. Seguidament, es plantejarà les conclusions de l’anàlisi feta en l’apartat previ i en darrer pas s’explicarà breument les 2 implementacions, cadascuna comptarà amb el seu apartat en què s’explicarà en més detall la solució. 10.1. Conclusions Tot i que a primera vista, l’emulació o simulació amb Keil, vista en 9.2. Perfilació amb Keil µVision, són les opcions que poden donar la millor informació en aquests dos objectius. El gran desavantatge és la dependència amb eines dels fabricants. Aquestes eines són difícils i lentes de configurar, i diferents productes tenen diferències subtils en el comportament i estructuració de les eines pels desenvolupadors. Llavors, la millor opció és la creació d’eines propietàries. Com a punt final sobre Keil, la instrumentalització d’aquest suposa igualment la creació d’aquestes, afegint diferents capes d’eines i configuració. Com s’ha vist en 9.5. Instrumentalització del codi en targetes SIM, existeix conflicte en la presa de traces i la mesura del temps, ja que la primera és una eina altament intrusiva. En conseqüència, es fara 2 eines diferents, la primera per analitzar el flux de les comandes APDU, i la segona per prendre els temps de les diferents parts del codi. 10.2. Traces de codi per cada comanda Per facilitat per al desenvolupador, s’ha decidit implementar la solució final en simulador Software funcional, com explicat en l’apartat 9.3. Simulació Software funcional de sistemes embedded. Ja que no ens importa el fet que els temps no siguin exactes, i la simulació és més fàcil de fer servir (no necessites lectors o targetes, és ràpid i es pot accedir als valors directament) i serveix per a totes les arquitectures. S’implementarà l’eina especificada en 9.5.3. Instrumentalització per l’obtenció de traces en targetes SIM, però en el simulador. Afegint funció hook a cada crida i sortida és guardara aquestes accions en un fitxer. Per visualitzar els resultats s’usarà l’eina pública de SpeedScope, aquesta permet la visualització interactiva del flux del codi[77]. 46 Anàlisi de rendiment i optimització en targetes SIM També ens permetrà, en un futur si es necessari, facilitar la creació de l’eina en targetes reals si es desitja fer. 10.3. Mesura de temps Per tal de calcular el temps d’execució és desnvolouparà la solució descrita en 9.5.1. Instrumentalització per la mesura de temps. Es crearà una eina que el desenvolupador pugui emprar de manera senzill en les parts del codi. Existeix l’inconvenient que no serà cent per cent automàtic, però com hi ha suport de l’eina de Speedscope, els punts a mesurar seran fàcilment descobribles, ja que donà una visió global de la lògica del codi que per indicar les funcions crucials a mesurar i poder comparar les diferents solucions. L’eina serà anomenada Debug Timer i permetrà començar a comptar, guardar marques de temps en els punts desitjats. 47 Anàlisi de rendiment i optimització en targetes SIM 11. Speedscope Speedscope és una eina web interactiva de visualització de perfils de rendiment open-source. Accepta múltiples formats d’entrada per mostrar els registres en format de gràfic. Existeixen mòduls per llenguatges com Python i Javascript, en aquest cas s'haurà de generar manualment i transformar els registres a un dels 3 formats genèrics suportats[78]. ● Format JSON particular de Speedscope. ● Format de pila col·lapsat de Brendan Gregg. ● Trace Event Format de Google. Per visualitzar el gràfic, només fa falta arrossegar el fitxer a l’eina des del navegador. L’eina és pública, com anteriorment mencionat, i pot veure’s en (encara que no és necessari d’accés a Internet si et baixes el fitxer html). https://www.speedscope.app/ Figura 12: Interfície de l’eina Speedscope en inici. 11.1. Obtenció dels registres Com s’ha esplaiat en 10.3. Mesura de temps, es continuarà amb la idea d’un hook a crides i sortides de funcions. 48 Anàlisi de rendiment i optimització en targetes SIM 11.1.1. Opcions de compilació Aquest cop, es compila amb Microsoft Visual C++ (MSVC). Les opcions de compilació són /Gh i /GH. Respectivament, afegeixen les funcions hooks en entrada i sortida de qualsevol funció[60][61]. Farà falta discernir el llistat de fitxers que compilar amb les opcions. Per exemple, cap funció que sigui cridada per aquestes hauria de compilar-se afegint el hook, o es crearia un cicle infinit de crides recursives. Alhora, potser es vol ometre alguns mètodes de depuració, o s’estimen irrellevants per l’anàlisi. 11.1.2. Funcions hooks Les funcions hooks són. void __declspec(naked) __cdecl _penter( void ); void __declspec(naked) __cdecl _pexit( void ); A diferència dels hooks de Clang aquests no tenen arguments. Compten en el manual de referència de Microsoft de 2 modificadors de funcions, extensions de compilador específiques de Microsoft. __cdecl dicta com passar arguments al stack, només canvia com es declara la funció en aquest cas[59]. __declspec(naked) deshabilita el pròleg i epíleg de les funcions. Per exemple, treu el retorn automàtic, tampoc gestiona automàticament el stack a l’inici de la funció, etc[62]. Per obtenir punter void* amb la següent instrucció de la funció que ha fet la crida. MSVC compta amb funció _ReturnAddress()[63]. Per obtenir el temps s’usarà QueryPerformanceCounter([out] LARGE_INTEGER *lpPerformanceCount), funció de Windows API que retorna el valor actual d’un comptador de rendiment d’alta resolució[64]. Les funcions són executades per cada crida. S’ha creat mecanisme de control per començar a escriure els valors en inici d’APDU i distingir les traces de cada comanda. 11.1.3. Format d’emmagatzematge Per cada entrada i sortida de funcions es registraran 3 valors. ● Caràcter per indicar el tipus d’event. ● Direcció de la funció. ● Temps. 49 Anàlisi de rendiment i optimització en targetes SIM Per poder visualitzar correctament és necessari els noms de les funcions, però en mig d’execució és costós d’aconseguir. Per això en el hook només s’ha de guardar la direcció de la funció que crida, més tard amb un Script es pot relacionar els valors de cada funció amb el fitxer mapa obtingut de la compilació (a més, permet formatar correctament en el format adequat). Com a exemple, en si es crida _penter() des de la funció foo() amb direcció 0x8000000. Un cop calculat l’inici de la funció foo(), hauriem de registrar el següent codi. B800000020000000 ● B denota l’event d’entrada. ● 0x8000000 denota la direcció d’entrada. ● 0x20000000 denota el temps. 11.1.4. Format de traces S’ha decidit usar el format de traces d’events de Google a causa de la seva senzillesa. A continuació es mostra l’exemple anterior usant el format de Google[29]. { "name": "foo", "ph": "B", "ts": “20000000” }, S’aprecien els següents pars de “clau” : “valor”. ● name conté el nom de la funció foo. ● ph conté el tipus d’event B. ● ts conté marca de temps 20000000. El tipus d’event rellevants són B de Begin en entrada a funció i E d’End en sortida a funció. 11.2. Funcionament de l’eina El format Flame Graph, el format que Speedscope usa per visualitzar els registres, mostra les crides a funcions de forma jeràrquica a través del temps. Les crides a funcions es representen com a flames (forma de barra), l’amplada representa al temps d’execució, i les subrutines s’amunteguen a sobre com a flames addicionals. No només permet saber l’ordre cronològic de les crides, també permeten saber la profunditat de les funcions, el nombre d’invocacions. En la següent imatge es mostra un exemple de traces donat pels creadors de Speedscope. S’explicarà les eines i visualització d’aquest[77]. 50 Anàlisi de rendiment i optimització en targetes SIM Figura 13: Log en Speedscope mostrat de manera temporal. 1. A la cantonada esquerra superior hi ha 4 opcions de visualització, ara mateix es mostra el gràfic en ordre temporal (Time Order). Els tipus de visualització són Time Order, Left Heavy, Sandwich i per últim una finestra d’ajuda. Es mostren, respectivament, en la figura 14 i figura 15 . 2. Gràfic de navegació, contenint totes les traces i una finestra a l’actual tram del Flame Graph que s'està visualitzant. Tenim la funcionalitat de fer Zoom per visualitzar amb més granularitat i navegar per tot el gràfic. 3. Flame Graph, en aquest exemple hi ha seleccionada la funció mergeAdjacentFrames(), cridada per map() cap al segon 2.51 i acaba aproximadament al segon 2.53. La resta de crides la funció seleccionada estan ressaltades en blau. 4. La pestanya inferior mostra informació de la funció seleccionada. En aquest cas, de tota l’execució mergeAdjacentFrames() s’executa durant 120.38 microsegons en aquesta crida (un 1.4% de tot el temps d’execució) i en totes les crides tarda 361.99 microsegons (un 8.7% de tota l’execució). La columna de Total conté els temps sumant les subrutines, i la columna Self només conté el temps en subrutines. En la següent figura es visualitza la finestra Left Heavy és similar a Time Order, però en contra d’usar ordre cronològic ordena les rutines pel temps d’execució[77]. 51 Anàlisi de rendiment i optimització en targetes SIM Figura 14: Visualització del Log en format Left Heavy A continuació, es mostra la vista en forma Sandwich. En aquest exemple, s’ha escollit la funció startsWithKeyword, en la part d’amunt s’exposa les rutines que la criden, en Callers. En la part inferior hi ha les subrutines de startsWithKeyboard, en Callees[77]. Figura 15: Visualització del Log en format Sandwich 52 Anàlisi de rendiment i optimització en targetes SIM 11.5. Anàlisi de traces Per concloure, Speedscope és una eina molt eficaç en l'anàlisi deguda a la visualització interactiva, intuïtiva i jeràrquica. Tècniques comunes per analitzar són. ● Identificació de hotspots usant la vista Left Heavy. ○ Les funcions més executades s’ha d’analitzar si s’està fent feina repetida. ○ Les funcions amb més amplada s’ha d’analitzar si la lògica pot millorar per ser més eficient, encara que el temps no sigui exacte en targeta, la tendència és que si una funció conté més instruccions, tardarà més. ● Cerca de patrons repetits. En solucions Software amb múltiples capes és comú que existeixi feina repetida. Diferents capes poden estar fent les mateixes verificacions, extracció o càlcul de valors. Es poden identificar com flames contenint les mateixes rutines i subrutines idèntiques al llarg de la comanda. ● Cerca d’events importants. Com a exemples, les escriptures a NVM, excepcions, operacions criptogràfiques. Rellevant per entendre en profunditat el procés de la comanda i implicacions en el sistema. ● Anàlisi de les dependències entre mòduls. Si un mòdul específic és constantment invocat en una rutina d'un mòdul diferent, pot ser signe que falta un mètode per la component invocad per simplificar la lògica i potencialment millorar el rendiment. ● Desglossar funcions grans en més petites. En cas d’un mètode gran, poder veure les subrutines més importants permet entendre els punts claus d’una funció. Ja que, sol existir correlació en temps d’execució i importància. 53 Anàlisi de rendiment i optimització en targetes SIM 12. Debug Timer El primer impediment a treballar en targetes SIM, s’ha conclòs, és la limitació en interfícies que dificulta el testatge. Llavors, és necessari d’eines de fabricants per obtenir la major precisió, dificultant la portabilitat i automatització del desenvolupament. Amb l’eina de Debug Timer es vol crear una API per a mesurar temps d’execució, emmagatzemar aquests, i extreure’ls via APDU. Necessitant així només la targeta i el lector de targetes per mesurar el rendiment. La primera eina, Speedscope, hauria de mostrar la lògica de cada comanda. Es pot identificar redundàncies i entendre les parts del codi clau. Llavors amb Debug Timer és possible mesurar en Hardware real i comparar diferents solucions. Existeixen 2 objectius amb el disseny final. ● Oferir una interfície als desenvolupadors amigable. ● Separar la capa d’execució única per cada targeta SIM per fàcil expansió de l’eina. Qualsevol representació de codi, o nom de funció, no és idèntic a la solució implementada en Giesecke+Devrient. 12.1. Temporitzador Hardware en targetes SIM Tot i que el nombre i funcionament de temporitzadors en targetes SIM varia model a model, però són semblants al SysTick i qualsevol altre temporitzador en Embedded. A continuació es llista les característiques comunes entre les implementacions, per poder entendre les solucions en els següents apartats. ● Registre de comptatge o valor. Contindrà el nombre de tics del temporitzador actual. S’ha de tenir en compte, alguns temporitzadors compten amunt o avall, depèn si cada tic augmenta en 1 el valor de comptatge o disminueix en 1. ● Registre de recàrrega. En cas que el valor desbordi, si el temporitzador sobrepassa el valor màxim o mínim, depenent si conta amunt o avall respectivament, el valor d’aquest registre serà carregat al registre de comptatge. ● Preescaladors. Els temporitzadors permeten aplicar preescaladors, ajusten la freqüència del rellotge. Normalment, es fa canviant la ràtio que els tics del processador corresponen als tics del temporitzador, per exemple pot configurar-se perquè un tic de processador sigui un de temporitzador, però si es vol fer servir en execució llarga, és possible augmentar en 16 o 32 o 64 tics de processador per temporitzador. 54 Anàlisi de rendiment i optimització en targetes SIM ● Registres de control i estat. Cada xip tindrà diferents maneres d’activar, parar i consultar l’estat del temporitzador. Exemples són, consultar si desbordament ha ocorregut, comprovar si està corrent el temporitzador. ● Interrupcions. En cas de desbordament pot disparar interrupció si l’habilitem. S’habilitarà un temporitzador per xip per comptar el temps. En reinici de la targeta sempre està apagat i s’haurà de configurar i activar quan es desitgi utilitzar, tenint en compte que no creï conflictes per el Hardware. 12.2. Representació del temps La unitat de mesura d’un temporitzador són els cicles. En general, una instrucció necessita un cicle de fetch i altre d’execució. Per això, el processador paral·lelitza la feina de buscar la següent instrucció amb execució de l’actual en xips moderns, així instruccions senzilles ronden el cicle d’execució. Salts de codi, emmagatzematge de dades i cerca en memòria són operacions més lentes[6]. Agafant de referència la targeta més ràpida en el treball (SLI37CMA1M0) amb un processador de 100 MHz, tenim el següent nombre de cicles per segon en màxima potència (per restriccions en consum de voltatge pot no ser la freqüència real d’execució). 100 𝑀ℎ𝑧 = 108 𝐻𝑧 = 100. 000.000 𝑐𝑖𝑐𝑙𝑒𝑠 𝑝𝑒𝑟 𝑠𝑒𝑔𝑜𝑛 En un segon tenim 100 milions de cicles. Els temporitzadors tenen uns 16 bits de representació de temps. El màxim valor representat per 16 bits és. 𝑉𝑎𝑙𝑜𝑟 𝑚à𝑥𝑖𝑚 =2 16 − 1 = 65.535 Fins i tot amb prescalador alt com 256, ocasionarà en desbordament en el següent nombre de cicles. 65.535 𝑐𝑖𝑐𝑙𝑒𝑠 * 256 =16. 777.216 𝑐𝑖𝑐𝑙𝑒𝑠 A causa d’aquesta limitació s’ha decidit usar 32 bits per representar el temps, així el màxim sense prescalador és. 𝑉𝑎𝑙𝑜𝑟 𝑚à𝑥𝑖𝑚 =2 32 − 1 = 4.294. 967.295 Per mesurar amb 32 bits de precisió s’haurà de comptar els cops que s’ha desbordat el temporitzador, cada desbordament sumarà 1 al valor alt del temps. S’han implementat 2 estratègies a escollir pel desenvolupador. ● Comprovació del desbordament usant registres de control. Cada cop que es guarda una marca de temps, es consulta els registres de control. En cas d’haver-hi desbordament, s’incrementa el comptador de desbordaments i es neteja el marcador en el registre. 55 Anàlisi de rendiment i optimització en targetes SIM 13. Mesures, anàlisi i millores Aquest apartat documenta els resultats de les últimes etapes del treball, sense entrar en específics. Les eines desenvolupades en aquest treball permeten mesurar el rendiment dins el codi, però els resultats de les propostes són mesurats en els temps de comandes. A causa de la privacitat de l’ITL, no es concretarà en profunditat solucions i peculiaritats del codi. 13.1. Mesura Com a recordatori, tenim en la figura 2 el procés de l’ITL. Cada pas llistat compta de múltiples comandes, aquests són. ● Establir connexió segura. El procés de creació d’un canal segur requereix autenticació i operacions criptogràfiques. ● Recepció imatge. El procés de recepció i emmagatzematge d’imatge requereix d’un nombre alt de comandes, com anteriorment mencionat el màxim nombre de dades en comanda APDU són 255 bytes. ● Autentificació, personalització i emmagatzematge de la imatge. Requereixen en tot pas de comprovacions de seguretat i emmagatzematge de dades. En el següent punt expandirem en aquestes mesures, punt estretament relacionat amb el de mesures. 13.2. Anàlisi dinàmic Per aplacar aquesta tasca és clau buscar les comandes que siguin cul d’ampolla. Alguns dels passos crucials són. ● Codi relacionat amb el despatx de comandes. ● Mòduls d’emmagatzematge de dades. ● Sistema d’autenticació i mòdul de criptografia. El procés de carregar una nova imatge, i reemplaçar l’actual, és bastant lent i comporta múltiples passos, coordinació de diferents components internes i moltes comandes. S’ha centralitzat esforços en aquests tres perquè és un procés de complexitat elevada i existeix la possibilitat d’extreure una immesurable quantitat d’informació. És important centralitzar els esforços en els punts més claus. Malgrat això, els resultats del treball no són satisfactoris pel que fa a l’anàlisi del sistema. Els principals obstacles han sigut la limitació en temps, complexitat, diversitat en tasques i la grandària del codi. I, en processos de criptografia, comunicació o emmagatzematge de dades, estàs molt limitat pels recursos dels 62 Anàlisi de rendiment i optimització en targetes SIM xips. El gruix de les execucions solen ser processos més directes dels quals no existeix gran espai de maniobra. En darrera instància, i obstacle major, un dels problemes és que en tot moment el codi ha de tenir present la possibilitat de pèrdues de corrent, comandes fora d’ordre i errors o atacs propagats en altres capes del codi. En el següent apartat s’expandeix més sobre aquest cul d’ampolla, la seguretat. 13.2.1. Codi segur Un dels aspectes més complexos és la seguretat de la solució. Les mesures de seguretat suposen un cost en rendiment, ja que comporten la repetició de processos o afegiment d’aquests. El codi en tot moment ha de ser protegit d’errors i atacs. En el cas d’elements segurs el codi s’ha de desenvolupar tenint en compte possibles atacs físics als xips. Aquests inclouen atacs amb làsers als registres per alterar el comportament del xip[52]. Exemples de mesures de seguretat són. ● Usar enters en comptes de booleans per codificar retorns. En tot valor tenir en compte la distància Hamming (mesura la diferència entre 2 valors)[38]. ● Emmagatzemar valors segurs en execució de parts de codi per comprovar haver passat per aquestes parts. ● Eliminar dades crítiques després de cada ús. ● Repetir càlculs segurs. ● Re-comprovació de condicionals. ● Valors checksum en dades crítiques. 13.3. Compilació L’optimització amb compilador és mitjançant les flags (opcions passades per controlar el procés de compilació). En ARM la principal opció per alterar el rendiment és el nivell d’optimització. Els principals són[10]. ● -O0. Mínima optimització, el codi objecte hauria de correspondre amb el font. Per depuració és millor, i per més ràpid temps de compilació. ● -O1. Optimització restringida. ● -O2. Optimització alta. ● -O3. Optimització molt alta. ● -Ofast. Optimització agressiva. Pot arribar a trencar normes del llenguatge de programació. ● -Oz. Optimització amb l’objectiu de limitar la dimensió del codi. 63 Anàlisi de rendiment i optimització en targetes SIM La primera prova millorant el nivell d’optimització és mesurar la mida del codi, s’aprecia un augment de 0,1%, un bon senyal. Però, en mesurar el temps de les comandes el rendiment, la millora mesurada podia arribar a ser 0,5% en els millors dels casos. Diferents hipòtesis existeixen. ● L’agressivitat en inlining (inserció del codi de funcions en comptes de crides) i desplegament de bucles pot augmentar el tamany de les funcions fent que el codi no càpiga en les cache d’instruccions. ● Els sets d’instruccions més simples no compten amb totes les eines per optimitzar el codi. Per exemple, SIMD (Single instruction, multiple data) que emmagatzemen múltiples valors simultàniament. ● Limitacions en la tecnologia, com lentitud d’escriptura a memòria flash, o protocols lents de comunicació ocupen la major part del temps d’execució. ● Llibreries importades de fabricants o externs no són compilades, no existeix canvi. Tampoc en processos Hardware agnòstics al codi. L’estratègia era, ja que cada nivell d’optimització agrupa diferents flags, investigar quines eren les més importants canvien entre nivells de compilació manualment. Per això, vist el poc temps a guanyar s’ha desestimat la tasca perquè l’augment en nivell d’optimització també comporta més temps de compilació i més diferenciació entre el codi font i objecte (possibles regressions). 13.4. Anàlisi estàtic Encara que el codi en embedded sigui codi de mesura més petita i temps més crítics, analitzant el codi objecte ràpidament es va descobrir que millorant funció a funció pots estalviar cicles comptats en cadascuna, resultats negligibles. Les hipòtesis dels resultats menors en analitzar estàticament el codi són. Primerament, els majors culs d’ampolla resideixen en protocols de comunicació, emmagatzematge de dades i criptografia. Millores petites en la resta del codi provoquen en menor guany de rendiment. Finalment, juntament amb la limitació de recursos en les SIM i la grandària de la solució, no són uns pocs punts estrenyent el rendiment, sinó un conjunt de petites pèrdues en múltiples mòduls. 64 Anàlisi de rendiment i optimització en targetes SIM 14. Conclusions 14.1. Resum Els resultats d’aquest projecte no han assolit plenament els objectius inicials, principalment a causa d’un mal plantejament en les fases inicials. Malgrat això, Speedscope i de Debug Timer són solucions pràctiques, funcionals i efectives per a l’anàlisi de rendiment en targetes SIM. El disseny modular d’aquestes fa que siguin una opció portable i fàcil de mantenir en el futur. Com a conclusió, el desenvolupament en targetes SIM és un procés que pot ser increïblement propietari, presenta de molts reptes respectius als sistemes embedded en entorns restringits. El treball serveix com a advertiment i guia per a aproximacions similars, l’èxit en l’optimització de sistemes crítics com les SIM requereixen rigor tècnic, flexibilitat i coneixement en un camp increïblement divers de la informàtica; protocols de comunicació, sistemes d’integració, sistemes embedded… 14.2. Compliment d’objectius 14.2.1. Objectiu Principal 1. Optimitzar el rendiment de l’ITL mitjançant la creació d’eines per mesurar els temps en targeta. No assolit enterament. Els resultats finals han sigut menys satisfactoris del plantejament inicial. 14.2.2. Objectius Secundaris 2. Eines de perfilació. 2.1. Obtenir valors reals de rendiment del Hardware. Assolit. El fet de poder mesurar internament el rendiment ens treu dubtes de si altres elements en el procés de comunicació afegeixen soroll. 2.2. Estandarditzar les eines desenvolupades en el projecte per ser fàcilment re-usables, automatitzar tots els processos possibles per major facilitat d’ús. Assolit. Les eines funcionen. El fet de tenir 2 eines separades és un petit compromís acceptable donades les limitacions tecnològiques. 3. Anàlisi. 3.1. Extreure els punts del codi que consumeixen més temps. 65 Anàlisi de rendiment i optimització en targetes SIM Assolit. 3.2. Aconseguir llistat d’estratègies per millorar els temps d’execució. Assolit parcialment. No s’ha aconseguit extreure un catàleg exhaustiu de solucions, però sí que s’ha expandit el coneixement del rendiment i impacte de les solucions. 4. Implementació. 4.1. Implementar diferents idees del punt anterior i mesurar la millora de cadascuna d’elles. Assolit parcialment. Els resultats mostren marges d’optimització més modests dels esperats. A més, diverses propostes comporten restriccions de seguretat. 14.3. Assoliment de competències ● CTI1.2. Seleccionar, dissenyar, desplegar, integrar, gestionar xarxes i infraestructures de comunicació en una organització. ● CTI2.2. Administrar i mantenir aplicacions, sistemes informàtics i xarxes de computadors. ● CTI3.1. Concebre sistemes, aplicacions i serveis basats en tecnologies de xarxa, tenint en compte Internet, web, comerç electrònic, multimèdia, serveis interactius i computació ubiqua. L’eina d’ITL és una eina interna per actualitzar sistemes operatius en els nostres xips. El canvi del focus en el treball, tenint més pes la primera part de mesura de rendiment, i menys la segona de millores en l’eina, ocasionen en competències més enfocades en l’apartat d’embedded que el de comunicació de sistemes. Tanmateix, el treball ha requerit coneixement en múltiples camps, tot el relacionat amb sistemes operatius requereix coneixement tècnic d’infraestructura en totes les capes d’un sistema, incloses comunicació i emmagatzematge de dades. 14.4. Adequació al coneixement del grau Com anteriorment esmentat, les particularitats de treballar en targetes SIM requereixen d’aptitusds transversal en especialitats del grau d’informàtica. Primer, és un sistema embedded, el codi és executat en xips i existeix accés directe als registres i components Hardware. Per això, està estretament relacionada amb l’especialitat d’Engyinyeria de Computadors. En segona instància, les targetes compten de múltiples protocols d’informació i el seu propòsit final és connectar-se a xarxes mòbils. Per això han de gestionar tots els recursos del xip per emmagatzemar i gestionar informació per poder identificar l’usuari. Els sistemes operatius serveixen també per donar suport als 66 Anàlisi de rendiment i optimització en targetes SIM seus usuaris i aplicacions. I l’ITL és l’encarregat de mantenir els sistemes operatius desplegats en milions de xips. Per tot això, també està relacionada amb l’especialitat de Tecnologies de la Informació. Finalment, com el propòsit era millorar el rendiment, s’analitza del disseny en el context de l’eficiència i seguretat. La limitació dels recursos, èmfasi a protegir d’atacs i errors, i alta manipulació de dades, causen que la solució s’hagi de meditar en profunditat. També està relacionada amb l’especialitat de Computació. 14.5. Treball futur Per mesura de rendiment, existeix espai per reutilitzar eines de Debug Timer i el perfilador del simulador per crear un perfilador amb targetes reals. També pot ser adaptat en eines de simulació o depuració (com Keil). Pel que fa a mesura de rendiment, aquesta és una tasca que pot ser treballada infinitament. Existeixen dues conclusions, la primera és que és millor treballar en punts precisos, com més específic sigui el punt que vulguis millorar el rendiment més fàcil serà treballar, per això és important comptar amb bones eines de perfilació. El punt final és ser meticulós en tot desenvolupament, retroactivament millorar el rendiment suposa un sobrecost. 14.6. Opinió personal La subestimació de la complexitat en el desenvolupament d’eines de perfilació per a targetes SIM, juntament amb expectatives poc realistes sobre el seu impacte, han conduït a desviacions significatives. No es va dedicar prou temps a una fase exploratòria sòlida per avaluar alternatives tècniques o limitacions de Hardware abans d’implementar solucions. Això comporta certa decepció i sentiment de derrota. Tanmateix, ha sigut una experiència altament formativa. Aspectes que s’han aprofunditzat molt han sigut per exemple en arquitectura de microcontroladors, compiladors, rendiment de sistemes, eines de depuració en embedded. I una visió més global de la solució de l’ITL. 67 Anàlisi de rendiment i optimització en targetes SIM 15. Glossari En aquest treball ens és referirà a les SIM com targetes, el desenvolupament es fa en aquestes encara que eventualment vagin a sistemes embedded. També s'usarà el terme xip com a sinònim. La llista de terminologia, recomanat de visitar si cau qualsevol dubte llegint el projecte. ● APDU (Application Protocol Data Unit). Unitat de comunicació entre lector i targeta SIM. L'estructura d'un APDU està definida en els estàndards ISO/IEC 7816. ● ATR (Answer To Reset). Missatge enviat per la targeta SIM en encendre’s, contenint paràmetres de per establir comunicació amb el lector. ● Breakpoint. Punt en el codi on s’atura l’execució per permetre depuració. ● Cortex-M35P. Processador ARM per secure elements, utilitzat en targetes SIM. ● Data Watchpoint and Trace (DWT). Mòdul de processadors ARM usat per depuració i traça de dades. ● Debugging. Depuració. Procés d’anàlisi de funcionament de codi executant aquest o amb eines que treguin informació de l’execució. ● Element segur (secure element). Sistema operatiu residint en xip amb mesures de seguretat per tal de protegir dades i serveis. ● Embedded Trace Macrocell (ETM). Mòdul de processadors ARM usat per generar traces d’instruccions en temps real. ● eSIM (Embedded SIM). SIM incrustada en dispositiu. ● Hook. Mecànisme d’injectació de codi, un hook captura l’execució actual per executar codi diferent. ● Integrated Development Environment (IDE). Entorn integrat de desenvolupament. Interfície que combina editors de codi amb altres eines per assistir en el desenvolupament del codi, com compiladors i consola per comandes. ● ISO/IEC 7816. Estàndard internacional per a secure elements que defineix interfície de contacte i missatges APDU i ATR. ● ITL (Image Trusted Loader). Component desenvolupada per Giesecke+Devrient encarregada d’actualitzar el sistema operatiu de secure elements. ● Keil µVision. IDE per a sistemes embedded, conté eines de simulació, emulació, editors de codi, etc. ● Memòria flash. Tipus d’emmagatzematge de dades no volàtil; en cas de pèrdua de corrent no es perden els valors guardats. ● Non-Volatile Memory (NVM). Memòria no volàtil. Tipus de memòria que reté els valors emmagatzemats encara que no hi hagi corrent activa (en cas d’apagat del xip). ● Personalització. Procés de carregar dades úniques en una SIM específica. 68 Anàlisi de rendiment i optimització en targetes SIM ● Perfilació. Procés d’utilitzar eines per fer anàlisi de rendiment sobre programes o aplicacions, identificant punts crítics que consumeixen major part de recursos. ● SecurCore SC300. Processador ARM per secure elements, utilitzat en targetes SIM. ● Scrum. Metodologia àgil de desenvolupament de Software per a gestió de projectes. ● SIM (Subscriber Identity Module). Circuit integrat amb propòsit de permetre l’accés d’un usuari a xarxa mòbil. ● SysTick. Temporitzador de sistema. Temporitzador de processadors ARM. ● Targeta intel·ligent (Smart Card). Targeta amb microxip integrat, normalment Secure Element. 69 Anàlisi de rendiment i optimització en targetes SIM 16. Bibliografia 1. Amazon. “HID Omnikey 3121”. Amazon. (s.d.). https://www.amazon.es/HID-Omnikey-electr%C3%B3nico-Tarjetas-Inteligen tes/dp/B06XY2XLWF. Extret 10/2024. 2. Àrea metropolitana de Barcelona. “Evolución del mercado inmobiliario de oficinas i locales”. Àrea metropolitana de Barcelona. (s.d.). https://oficinesilocals.amb.cat/es/Indicadors. Extret 10/2024. 3. Arm. “Compatibility between Armv6-M, Armv7-M, and Armv8-M architectures”. developer.arm. (s.d.). https://developer.arm.com/documentation/107706/0100/Introduction-to-th e-Armv8-M-exception-Model/Compatibility-between-Armv6-M--Armv7-M-- and-Armv8-M-architectures. Extret 03/2025. 4. Arm. “Compiler Command-line Options - --gnu_instrument, --no_gnu_instrument”. arm.developer. (s.d.). https://developer.arm.com/documentation/dui0472/k/Compiler-Commandline-Options/--gnu-instrument----no-gnu-instrument. Extret 03/2025. 5. Arm. “Cortex-M35P”. (s.d.). developer.arm. https://developer.arm.com/Processors/SecurCore%20SC300#Technical-Spec ifications. Extret 03/2025. 6. Arm. “Cortex-M3 Technical Reference Manual r1p1 - Processor instruction timings”. arm.developer. (s.d.). https://developer.arm.com/documentation/ddi0337/e/BABBCJII. Extret 03/2025. 7. Arm. “Cortex-M3 Technical Reference Manual r2p0 - Chapter 8. Data Watchpoint and Trace Unit”. developer.arm. (s.d.). https://developer.arm.com/documentation/ddi0337/h/data-watchpoint-andtrace-unit?lang=en. Extret 03/2025. 8. Arm. “Cortex-M3 Technical Reference Manual r2p0 - Chapter 9 - Instrumentation Trace Macrocell Unit”. developer.arm. (s.d.). https://developer.arm.com/documentation/ddi0337/h/instrumentation-trac e-macrocell-unit?lang=en. Extret 03/2025. 9. Arm. “Arm Cortex-M3 Processor Technical Reference Manual Revision r2p1 - ETM block diagram”. developer.arm. (s.d.). https://developer.arm.com/documentation/100165/0201/Embedded-Trace-M acrocell/ETM-functional-description/ETM-block-diagram?lang=en. Extret 03/2025. 10. Arm. “Arm C/C++ Compiler Reference Guide Version 19.3.0 - Optimization options”. (s.d.). https://developer.arm.com/documentation/101458/1930/Compiler-options/O ptimization-options. Extret 03/2025. 11. Arm. “Embedded Trace Macrocell Architecture Specification”. developer.arm. (s.d.). https://developer.arm.com/documentation/ihi0014/q. Extret 03/2025. 70 Anàlisi de rendiment i optimització en targetes SIM 12. Arm. “NVIC”. developer.arm. (s.d.). https://developer.arm.com/documentation/ddi0337/e/Introduction/Compon ents--hierarchy--and-implementation/NVIC. Extret 03/2025. 13. Arm. “SecurCore SC300”. developer.arm. (s.d.). https://developer.arm.com/Processors/SecurCore%20SC300#Technical-Spec ifications. Extret 03/2025. 14. Arm. “System timer, SysTick”. developer.arm. (s.d.). https://developer.arm.com/documentation/dui0552/a/cortex-m3-peripherals /system-timer--systick. Extret 03/2025. 15. Arm. “The optional Memory Protection Unit”. developer.arm. (s.d.). https://developer.arm.com/documentation/dui0552/a/cortex-m3-peripherals /optional-memory-protection-unit. Extret 03/2025. 16. Arm. “The optional Wakeup Interrupt Controller”. developer.arm. (s.d.). https://developer.arm.com/documentation/dui0552/a/the-cortex-m3-proces sor/power-management/the-optional-wakeup-interrupt-controller. Extret 03/2025. 17. Arm. “The Thumb instruction set”. developer.arm. (s.d.). https://developer.arm.com/documentation/ddi0210/c/CACBCAAE. . Extret 03/2025. 18. Arm. “Thumb-2 technology”. developer.arm. (s.d.). https://developer.arm.com/documentation/dui0471/m/key-features-of-armarchitecture-versions/thumb-2-technology. Extret 03/2025. 19. Arm. “µVision User's Guide”. developer.arm. (s.d.). https://developer.arm.com/documentation/101407/0542/About-uVision. Extret 03/2025. 20. Arm. “µVision User's Guide - Debug Scripting”. developer.arm. https://developer.arm.com/documentation/101407/0542/Debugging/Debug -Scripting. Extret 03/2025. 21. Arm. “µVision User's Guide - Debug Scripting - Debug Commands”. developer.arm. (s.d.). https://developer.arm.com/documentation/101407/0542/Debug-Commands ?lang=en. Extret 03/2025. 22. Atlassian. “Confluence pricing. Atlassian”. Atlassin. (s.d.). https://www.atlassian.com/software/confluence/pricing. Extret 10/2024. 23. Atlassian. “Jira Pricing. Atlassian”. Atlassian. (s.d.). https://www.atlassian.com/software/jira/pricing. Extret 10/2024. 24. Celer, V. “Tarjeta SIM como Módulo de Seguridad (HSM)”. CelerSMS. 12/2021. https://www.celersms.com/android-SIM-HSM-es.htm. Extret 10/2024. 25. Clang. “Clang command line argument reference”. Clang. (s.d.). https://clang.llvm.org/docs/ClangCommandLineReference.html. Extret 03/2025. 26. CostEEnergía. “Evolución del precio de la luz para agosto de 2024”. CostEEnergía. (s.d.). https://www.costeenergia.es/historico/pvpc-agosto. Extret 10/2024. 71