Sikkerhet og Cortex-M MPU.

Ettersom innebygde systemer er trukket mer inn i IoT, blir sikkerhet i form av beskyttelse av kritiske ressurser stadig viktigere. Effektiv beskyttelse kan kun oppnas via maskinvare.

Cortex-M Memory Protection Unit (MPU) er vanskelig a bruke, men det er det viktigste verktoyet for maskinvarehukommelsesbeskyttelse som er tilgjengelig for de fleste Cortex-M-prosessorer. Disse prosessorene er i utbredt bruk i sma og mellomstore embedded systemer. Derfor behover det oss a l re a bruke denne MPUen effektivt for a oppna palitelighet, sikkerhet og sikkerhet som moderne innebygde systemer krever.

A utvikle en god beskyttelsesstrategi for et innebygd system er vanskelig nok uten a matte handtere overdreven kompleksitet pa lavt niva. Sistnevnte er ikke bare frustrerende, men kan fore til utilstrekkelig systembeskyttelse. MPU-programvare er nodvendig for a overvinne maskinvarekompleksitet og gir et solid grunnlag for a skape beskyttede, sikre systemer og for a oppdage og handtere sikkerhetsbrudd. Dette er det forste i en serie blogger som presenterer en programvare tiln rming for a tilfredsstille dette behovet.

Cortex-M prosessorer har tre driftsformer:

handteringsmodus – privilegert modus for ISRer, feilbehandlere, SVC Handler og PendSV Handler. Denne modusen kan bare angis via et unntak. privilegerte tradmodus – privilegerte oppgaver (ptasks) kjorer i denne modusen. Det kan bare skrives inn fra handteringsmodus. ubehovlet tradmodus – ubehagelige oppgaver (utasks) kjores i denne modusen. Den kan skrives inn fra en av de to ovennevnte modusene.

I de diskusjonene som folger, blir de to forste modene kollektivt kalt pmode og den tredje modusen kalles umode. Pa samme mate refererer denne og de etterfolgende bloggene til kode, ucode, pSSRs, uSSRs, etc. Disse er ikke bransjestandige betingelser, men heller introduseres her for a forenkle diskusjoner.

Det grunnleggende malet med beskyttelse er a kjore palitelig programvare i pmode og a kjore all mindre palitelig programvare i umode. Eksempler pa klarert kode er RTOSer, ISRer, handterere og lavnivadrivere. Eksempler pa mindre palitelig kode er uprovd kode, tredjeparts programvare eller programvare av ukjent stamtavle (SOUP), og kode som er sarbar for skadelig programvare, for eksempel protokollstabler og hoytliggende drivere. Dette malet kan brytes inn i delmal for umode:

Forhindre direkte tilgang til RTOS-tjenester og data Forhindre tilgang til begrensede RTOS-tjenester med utasks Beskytt prosessorens kjerneressurser (f.eks. SysTick-timer) Beskytt eksterne enheter fra utilsiktet modifikasjon Forhindre kjoring av kode fra RAM Forhindre direkte tilgang til kritisk systemkode og data Begrens utgaver og utaskgrupper til Kun tilgang til angitt kode og data Tillat isolering av utasker og utask grupper fra hverandre Oppdag oppgavestap og bufferoverlasting umiddelbart Oppdag inntrengninger og feil og sla dem ned, slik at kritiske operasjoner ikke blir forstyrret.

Tydeligvis er graden av beskyttelse som er nodvendig, avhengig av sikkerhets- og sikkerhetskravene til det spesifikke systemet. V r oppmerksom pa at beskyttelse for et system kan okes i fremtidige utgivelser, da det blir mer distribuert og derfor mer sarbart. Denne MPU programvare tiln rming fremmer progressiv beskyttelse forbedring pa denne maten.

Cortex-M0 / 1/3/4 MPUer har 8 spor og Cortex-M7 MPUer har 16 spor. Hvert aktivt spor definerer en minnesregion med egne attributter som storrelse, justering, lese / skrive (RW), skrivebeskyttet (RO), kjor aldri (XN) osv. Spor hvor EN-biten er null er inaktiv og har ingen effekt pa minnetilgang. Derfor er en bruker ikke tvunget til a bruke alle spor. Ubrukte spor er vanligvis fylt med nuller for a deaktivere dem.

To uheldige aspekter ved Cortex-M MPU er at minneomradestorrelsene ma v re 2, som spenner fra 32 byte til 4 GB, og minnesregioner ma starte pa flere forskjellige storrelser. Disse kravene undergraver bruken av MPU ved a gjore det vanskelig a bruke uten a kaste bort betydelig minne. For eksempel, hvis en beskyttet stabel oker fra 256 byte til 260 byte, ma regionen som inneholder den, okes fra 256 byte til 512 byte, og hvis den ikke allerede er pa en 512 byte grense, ma den flyttes opp 256 byte til Den neste 512-byte grensen – nesten 200% slosing med minne. Dette er et problem fordi systemer som bruker Cortex-M-prosessorer, vanligvis har begrenset minne.

En fordel ved MPU er at den tillater definisjon av sv rt sma regioner (sa lite som 32 byte). Dette sammenligner til minst 4096 byte for de fleste MMUer. Derfor er en MPU mer egnet for RTOS-baserte multitasking systemer enn en MMU.

Etter initialisering er MPU i bakgrunnsmodus og alle sporene er deaktivert (dvs. alle er fylt med nuller). I denne modusen er operasjonen det samme som med MPU av eller ingen MPU i det hele tatt. Systeminitialisering utfores i denne modusen. Da er MPU-sporene lastet med regioner.

Konvertering av arvskode.

Hacks og malware angrep blir stadig mer utbredt. Som en folge av dette, onsker mange ledere sannsynligvis at produkter som selskapene deres leverer i dag, har bedre beskyttelse. Ettermontering av arvskode med MPU-beskyttelse er mulig og er et hovedmal for MPU-programvaren som vi skal diskutere.

Eldre kode vil kjore normalt i privilegert modus (pmode) med MPU aktivert i bakgrunnsmodus. Dette er utgangspunktet. Herfra blir mindre palitelige oppgaver og kode gradvis flyttet til unprivileged mode (umode). Denne trinnvise prosessen tillater a handtere den minst palitelige og mest sarbare koden forst, mens du sorger for at systemet fortsetter a kjore riktig etter hvert trinn. Hvis det ikke gjor det, kan trinnet reverseres og problemet (e) er funnet og fikset. Dette tillater en strategi for sikkerhetsoppdateringer for a gjore installerte systemer sikrere ettersom antallet oker.

En annen god tid a legge til MPU-beskyttelse er nar nye funksjoner legges til arvsystemer som har v rt i bruk i noen tid. I dette tilfellet er de nye funksjonene sannsynligvis tilknyttet hovedfunksjonen til utstyret og kan derfor og skal isoleres. Dette ville spesielt v re tilfelle hvis nettverket ble lagt til det som hadde v rt et frittstaende system, for eksempel.

Klarerte kode og klarerte oppgaver er best igjen a kjore i pmode fordi det er enklere og raskere. pcode og pdata er i bakgrunnsomradet og dermed tilgjengelig for alle ptasks og handlers. Dette sikrer at noye utformet, misjonskritisk kode ikke behover a skrives om igjen – den forblir den samme og kjorer det samme. Videre forblir kommunikasjonen det samme om det er mellom ptasks eller mellom ptasks og utasks. Utskrifter er imidlertid isolert og kan ikke utfore begrensede systemtjenester, for eksempel a sla ned eller slette andre oppgaver.

Utvikling av ny kode.

Sikkerhet legger til en ny dimensjon for produktutvikling. Mens teoretisk lyd til a «bygge sikkerhet i fra begynnelsen», kan det ikke v re en overdrevent velkommen dimensjon til prosjekter som allerede har for mange dimensjoner og for liten tid for a oppna dem. Det kan saledes v re behov for a utsette sikkerhetsforanstaltninger til sent i prosjektet, eller til og med etter prosjektet, nar de blir mer fordelaktige og mindre distraherende. Tegningsbeskyttelsesgrenser for oppgaver og kode har stabilisert kan kaste bort betydelig tid.

Bakgrunnsmodus kan v re det beste utgangspunktet for a utvikle ny kode for nye prosjekter, siden feilsoking er enklere. Nar koden imidlertid fungerer rimelig bra, kan den bevege seg til umode, slik at kraften til MPU og SVC (Supervisor Call) kan hjelpe til med feilsokingsproblemer som stabling og bufferoverlop, wild pointers, begrensede operasjoner, etc. Dette er mest nyttig under systemintegrasjonsfasen. Oppgaver kan flyttes fra pmode til umode og tilbake for a spore opp og fikse problemer forarsaket av umode.

Fordelene ved MPU-feilsoking i den siste prosjektfasen kan lett oppveie tiden som kreves for a endre kode og oppgaver for a lope i umode. Noen prosjekter kan imidlertid foretrekke a lide. Hvis det er tilfelle, kan systemoppgraderinger etter opplosning v re mulig. Dette bryter selvsagt alle reglene, men det gir praktisk mening for prosjekter som ligger etter planen og overveldet ved bare a fa nodvendige funksjoner til a fungere.

Nar stovet er lost, er det mulig a ga tilbake, se pa systemets sikkerhetskrav, og begynn a gjore systemet sikrere. I lopet av denne tiden blir produksjons- og installasjonsproblemer langsomt lost av andre mennesker, forsendelsene oker gradvis, og samtidig kan sikkerheten gradvis forbedres.

De kommende artiklene er som folger:

Mer informasjon finner du ogsa pa www.smxrtos.com/mpu.

Ralph Moore, president og grunnlegger av Micro Digital, uteksaminert med en grad i fysikk fra Caltech. Han tilbrakte sin tidlige karriere innen dataanalyse, og flyttet deretter inn i mainframe design og radgivning.