CHE COS’È UN KERNEL DI SEPARAZIONE?

Documento revisionato a partire da testi su architetture di sistema create da Tim Loveless

_______________

Avendo costruito sia kernel di separazione che sistemi operativi in ​​tempo reale e supportato i clienti che li utilizzano in un’ampia gamma di settori, Tim Loveless conosce i pro e i contro di ciascun software tecnologico, nonché il loro impatto su sicurezza, protezione, affidabilità su progetti di sistemi complessi. Tuttavia, nonostante forniscano notevoli vantaggi in termini di sicurezza e protezione e siano alla base di alcuni dei più grandi sistemi mission-critical del mondo, i kernel di separazione rimangono in gran parte sconosciuti e poco conosciuti. In questo articolo, ci auguriamo di:

1. Portare un po ‘di chiarezza sull’argomento dei kernel di separazione rispetto ai sistemi operativi in ​​tempo reale (RTOS) e agli hypervisor incorporati
2. Discutere i vantaggi e gli svantaggi dell’utilizzo di un kernel di separazione come base software per la progettazione dei sistemi incorporati
3. Introdurre LynxSecure®, il nostro kernel di separazione

KERNEL DI SEPARAZIONE DEFINITI

Un kernel di separazione è un tipo speciale di hypervisor bare metal che esegue solo la separazione. Più specificamente, è un minuscolo pezzo di codice accuratamente predisposto (piccolo quanto 15 KB) che utilizza le moderne funzionalità di virtualizzazione dell’hardware per (1) definire fisse macchine virtuali(VM) e (2) controllare i flussi di informazioni.

I kernel di separazione non contengono driver di dispositivo, modello utente, accesso alla shell e memoria dinamica; queste attività ausiliarie vengono tutte trasferite nel software guest in esecuzione nelle VM. Questa architettura semplice ed elegante si traduce in un’implementazione minima che, sebbene meno conveniente per l’uso desktop, si adatta perfettamente ai sistemi embedded real-time e critici per la sicurezza. Tuttavia, un kernel di separazione è molto più di una semplice implementazione hypervisor minima.

SFRUTTARE L’HARDWARE MODERNO

I moderni processori multi-core contengono una ricca serie di risorse. Oltre a più core, includono periferiche, memoria e funzionalità di virtualizzazione avanzate che consentono di trattarli come un set LEGO di componenti per la creazione di configurazioni di macchine virtuali (VM). Sebbene ampiamente utilizzate nei data center cloud, queste moderne tecnologie hardware sono spesso scarsamente supportate da RTOS e hypervisor incorporati.

I kernel di separazione possono essere utilizzati per partizionare le risorse hardware del processore in VM ad alta garanzia che sono sia a prova di manomissione che non bypassabili e per impostare flussi di informazioni strettamente controllati tra VM e periferiche, in modo che le VM siano isolate tranne dove esplicitamente consentito. Pensa a un kernel di separazione come a un “sistema di partizionamento del processore” che consente ai costruttori di sistemi embedded di sfruttare i vantaggi dei moderni processori multi-core completi.

Figura 1: Viste 2D + 3D di RTOS rispetto all’architettura del kernel di separazione

FORNITURA DELL’APPROCCIO MODULARE SISTEMI APERTI (MOSA)

Implementato correttamente, kernel di separazione:

• semplificare le analisi di protezione e sicurezza
• Rafforzare le proprietà di garanzia
• Aumentare il controllo dell’hardware
• Sbloccare le opzioni di progettazione del sistema modulare irraggiungibili dal sistema operativo tradizionale Architetture OS)

I kernel di separazione consentono di estendere e applicare in modo efficiente i principi di progettazione di MOSA. Con una base di separazione del kernel, i moduli VM agnostici del sistema operativo (OS) evitano il vincolo del fornitore e supportano uno spettro più ampio di carichi del sistema operativo; da bare metal, a RTOS, a sistemi operativi aziendali. La libertà di progettazione e la flessibilità sono migliorate, consentendo l’utilizzo di un mix “Riccioli d’oro” di RTOS appena sufficiente . In questo senso, i kernel di separazione promuovono la scelta consentendo a più combinazioni di tecnologia di adattarsi insieme.

STORIA

PROGETTAZIONE E VERIFICA DI SISTEMI SICURI

Il concetto di kernel di separazione è stato descritto per la prima volta da John Rushby nel suo documento del 1981 Design and Verification of Secure Systems. Rushby scrive:

“… il compito di un kernel di separazione è creare un ambiente che sia indistinguibile da quello fornito da un sistema distribuito fisicamente: deve apparire come se ogni regime sia una macchina separata e isolata e che le informazioni possano fluire solo da da una macchina all’altra lungo le linee di comunicazione esterne note. “

L’idea di Rushby è che la separazione è troppo importante per essere gestita dal sistema operativo. Il sistema operativo è grande, complesso e responsabile di molte cose e quindi estremamente difficile da rendere “impermeabile” dal punto di vista della sicurezza. Si rese conto che il modo migliore per costruire un sistema informatico sicuro sarebbe stato quello di scomporre la gestione della separazione dal sistema operativo in un nuovo tipo di kernel incentrato esclusivamente sulla separazione. Ha chiamato questo nuovo kernel un kernel di separazione. Il kernel di separazione dovrebbe essere abbastanza piccolo e semplice da poter essere esaminato intimamente e compreso appieno al punto da essere formalmente dimostrato di essere corretto. Nel 1982, Rushby continuò descrivendo, in Proof of Separability, come utilizzare metodi formali per verificare matematicamente la correttezza di un tale kernel di separazione.

I casi d’uso del kernel di separazione erano inizialmente workstation sicure responsabili di applicazioni governative ead alta sicurezza che DoD richiedevano la separazione delle classificazioni di informazioni top secret, segrete e riservate. Sono seguiti sistemi di comunicazione di rete militari incorporati come gateway radio protetti e più recentemente i kernel di separazione hanno trovato applicazione come hypervisor superiore nei sistemi embedded e nei sistemi avionici critici per la sicurezza che cercano una separazione più forte per gestire le interferenze multi-core. Nonostante ciò, i kernel di separazione sono rimasti un concetto di nicchia riconosciuto solo nel settore della sicurezza.

MILS, CRITERI COMUNI E SKPP

MILS (Multiple Independent Levels of Security) è un’architettura di sicurezza ad alta garanzia progettata per consentire l’hosting di applicazioni di sicurezza miste su hardware di computer comuni. I Common Criteria for Information Technology Security Evaluation (ISO / IEC 15408) è uno standard internazionale per i prodotti IT. Common Criteria definisce i livelli di garanzia di valutazione della sicurezza (EAL) che vanno da EAL1 (meno sicuro) a EAL7 (più sicuro) per descrivere il livello di sicurezza raggiunto dagli obiettivi di sicurezza (componenti) valutati (testati) rispetto a un profilo di protezione.

Per alcuni anni a partire dal 2007, i Common Criteria includevano un profilo per i kernel di separazione chiamato Separation Kernel Protection Profile (SKPP) che i fornitori di sistemi operativi in ​​tempo reale (RTOS) come Lynx, Wind River Systemse Green Hills Software hanno creato prodotti verso. Pur essendo un concetto robusto, lo SKPP era purtroppo tramonto nel 2011 da NIAP dopo i problemi con la prima valutazione. I Common Criteria rimangono uno standard utile, ma non saranno accettate ulteriori valutazioni SKPP e l’SKPP è effettivamente morto. Invece, NIAP supporta direttamente il processo di certificazione e accreditamento per i sistemi critici. NIST La pubblicazione speciale del800-53, “Controlli di sicurezza e privacy per i sistemi e le organizzazioni di informazione federali” è un approccio di sicurezza più generale che colma in parte il divario SKPP.

Senza uno standard per misurare la robustezza della sicurezza dei kernel di separazione, MILS ha più o meno fallito. Il mondo è un posto meno sicuro senza uno standard come SKPP, sfortunatamente, e qualsiasi implementazione di virtualizzazione può affermare di essere sicura o di essere un kernel di separazione.

KERNEL DI SEPARAZIONE VS. Hypervisor BASATI SU RTOS 

TERMINOLOGIA

Gli hypervisor di tipo 1 sono più desiderabili del tipo 2 perché sono più piccoli, più veloci e più sicuri. Quindi, se sei ospitato su qualcosa di meno di un sistema operativo generico (come Windows), è vantaggioso chiamarti Type-1. Il termine è stato tuttavia sovrautilizzato, in modo tale che qualsiasi cosa ospitata su meno di un’impresa Linux senza GUI viene descritta come Tipo 1. Come vedremo, un kernel di separazione, come descritto da John Rushby, è ancora più piccolo e più sicuro di altri hypervisor.

I kernel di separazione sembrano simili ai tradizionali hypervisor di tipo 1 basati su RTOS e i termini sono spesso confusi. Molti sistemi operativi e RTOS sono stati estesi per trasformarli in hypervisor e sono descritti come kernel di separazione, hypervisor di tipo 1, hypervisor bare metal, hypervisor incorporati o hypervisor in tempo reale. Secondo Lynx, questi sono tutti ospitati hypervisor, ovvero hypervisor di tipo 2. Anche se il sistema operativo host è un piccolo RTOS, è comunque un sistema operativo. Lynx ritiene che i kernel di separazione siano l’unica implementazione di hypervisor non ospitata, ovvero bare metal. Questa è una distinzione importante che i fornitori di RTOS vogliono offuscare perché li aiuta a vendere più RTOS e blocca il loro RTOS in profondità nelle fondamenta del tuo sistema embedded.

I kernel di separazione non hanno il compito di assumere funzioni RTOS ausiliarie. Anche se queste funzioni sono veramente piccole (come lo sono in un RTOS), non è la loro dimensione che conta, ma la loro completa assenza, che rende un kernel di separazione pulito, sicuro, robusto e RTOS-agnostico.

ARCHITETTURA COMUNE DI HYPERVISOR

Quasi tutti gli hypervisor seguono un’architettura aperta centralizzata. Ciò include hypervisor “bare metal”, Type-1, Type-2, “embedded” e “real-time”. Sono centralizzati poiché sono costruiti attorno a un “sistema operativo principale” (o RTOS) centrale che possiede le risorse hardware e gestisce le VM. Sono aperti poiché sono in grado di ospitare qualsiasi sistema operativo nelle loro VM. Nel mercato embedded, praticamente tutti gli hypervisor sono RTOS che sono stati estesi in un hypervisor. L’uso di un tale hypervisor spesso significa che sei costretto a prendere (almeno una versione ridotta) l’RTOS del fornitore, anche se tutti i guest sono esclusivamente open source.

Ciò viene in genere fatto per 3 motivi:

• consente all’hypervisor di eseguire il piggyback sul catalogo esistente del fornitore di RTOS BSP, mitigando il costo di un BSP
• È più facile creare VM dall’interno di un RTOS che possiede tutti i core della CPU, tutta la memoria e tutti i dispositivi piuttosto che scrivere un kernel di separazione Le
• toolchain RTOS del fornitore (IDE e compilatore) sono spesso pacchettizzate con l’hypervisor

Figura 2: Architetture/ hypervisor comuni

RTOSHYPERVISORI BASATI SU

RTOS Sia gli hypervisor basati su RTOS che i kernel di separazione si basano sulle stesse estensioni di virtualizzazione hardware , ma c’è sostanzialmente più codice presente in un hypervisor RTOS. Conterrà i driver di dispositivo, un heap di memoria dinamico e l’accesso alla shell con una password per accedere a un interprete dei comandi per la creazione, la visualizzazione e l’avvio di VM. Lo scheduler RTOS sarà presente, pianificando sia le attività che le VM. Potresti anche avere un multiplexer per console per ottenere un comodo accesso alle console guest delle VM e servizi di rete virtuale per consentire alle VM di condividere una scheda di interfaccia di rete fisica (nic). Questo codice è una responsabilità per la sicurezza ed è inaccettabile in un kernel di separazione.

L’unico codice comune con un kernel di separazione e un hypervisor basato su RTOS è il codice che configura le VM. In un kernel di separazione, tale lavoro viene eseguito al momento dell’avvio e, per motivi di sicurezza, il codice viene “gettato via” una volta configurate le VM. Questo è il motivo per cui la configurazione della VM del kernel di separazione è statica, poiché il codice per modificarla viene eliminato dopo l’avvio.

Tutto questo codice extra in un hypervisor basato su RTOS è una superficie di attacco che rappresenta un rischio per la sicurezza. È codice in esecuzione a livello di hypervisor privilegiato che, se va storto, ha il potere di violare la sicurezza del sistema. Quel codice è anche incredibilmente grande per dimostrarsi formalmente corretto. Questo codice ausiliario è prezioso e fornisce funzionalità utili, ma secondo un’architettura del kernel di separazione non deve trovarsi nell’hypervisor, ma invece essere inserito nelle VM guest. L’approccio di avere solo il codice minimo in una posizione di potere è noto come il principio del privilegio minimo. Isistema operativo microkernel del seguono lo stesso modello di progettazione, ovvero spingono i componenti del sistema operativo ausiliario dallo spazio del kernel allo spazio utente.

ARCHITETTURA APERTA DISTRIBUITA

I kernel di separazione promuovono un’architettura di sistema aperta e distribuita. È distribuito poiché non esiste un RTOS master che possieda tutte le risorse hardware. In altre parole, non esiste un RTOS “traffic cop” da cui altri software nel sistema devono richiedere l’accesso a tempo CPU, memoria e dispositivo I / O tramite le sue API. Invece, un kernel di separazione è un insieme di gestori e una macchina a stati che espone un sottoinsieme dei core, della memoria e dei dispositivi della CPU reale come VM al sistema operativo guest.

Il sistema è distribuito nel senso che l’RTOS master viene eliminato e i servizi forniti vengono distribuiti nelle VM. Ogni VM è in grado di eseguire il mix “Goldilocks” di RTOS appena sufficiente per svolgere il proprio lavoro e per soddisfare le esigenze del progetto, siano esse costo, sicurezza, compatibilità, determinismo, protezione, riutilizzo o longevità. Una VM bare-metal potrebbe eseguire uno stretto ciclo di controllo in tempo reale ed essere certificata per un’elevata garanzia di sicurezza, i moduli open source come littlefs e mbedtls (ssl) possono essere portati e riutilizzati in altre VM bare metal, insieme a VM che ospitano completamente open RTOS sorgente come FreeRTOS o Micrium µC / OS. Qualsiasi combinazione di tali VM può essere combinata in un sistema in modo da evitare il compromesso unico per la scelta di un unico RTOS master. Le tue opzioni sono aperte, abbondanti e più appetibili rispetto all’essere bloccati in un RTOS.

ARCHITETTURA DI SISTEMI MODULARI

Con disciplina, qualsiasi sistema software può essere costruito con un’architettura di sistema modulare; cioè scomposto in componenti con interfacce e responsabilità ben definite. Un buon software è progettato in questo modo, ma il problema è che solo la disciplina lo mantiene in questo modo. I programmatori codificano le variabili, le API e l’ambito che crea l’architettura del sistema modulare. Senza disciplina, possono creare altrettanto facilmente scorciatoie, variabili globali e interfacce laterali che lo aggirano. Tali bypass creano sorprese e dipendenze nascoste che, se lasciate crescere nel corso degli anni, fanno sì che un sistema diventi ingombrante e inaffidabile.

Invece di basare un design modulare sui processi all’interno di un RTOS, puoi uscire dal mondo del sistema operativo e creare moduli software ausiliari come VM del kernel di separazione. Tali VM traggono vantaggio dall’applicazione dell’hardware delle loro interfacce. Ovvero, il kernel di separazione definisce quali regioni di memoria sono accessibili alla VM, quali sono di sola lettura, quali sono di lettura-scrittura e quali sono condivise con altre VM. Questa definizione viene impostata nella MMU dal kernel di separazione dalla modalità hypervisor privilegiato e non può essere modificata o aggirata dalla VM. Anche le periferiche come le porte seriali, le interfacce di rete, la grafica e i dispositivi di archiviazione vengono allocate alle VM e l’accesso viene imposto dal kernel di separazione utilizzando l’hardware (programmando il controller di interrupt e IOMMU). In questo modo è possibile costruire un’architettura di sistema software altamente modulare con un’applicazione efficiente e robusta dei confini dei moduli.

MACCHINA VIRTUALE GENERICA in

I sistemi operativi guest (GOS) dellaesecuzione all’interno delle VM richiedono ancora i pacchetti di supporto della scheda (BSP) per adattarli alla mappa di memoria e alle periferiche della VM. Ma il kernel di separazione può giocare un bel trucco e mappare lo stesso set minimo di memoria, una porta seriale e un nic virtuale agli stessi indirizzi in modo che un generico RTOS BSP possa essere riutilizzato per diverse schede di destinazione. Questo BSP è una linea di base di lavoro che può essere estesa più facilmente (rispetto a partire da zero) per supportare dispositivi specifici per una particolare scheda di destinazione.

RISORSE HARDWARE

Un effetto collaterale dell’utilizzo di un kernel di separazione è che è necessario considerare le risorse hardware con maggiore attenzione. I sistemi operativi cercano di astrarre l’hardware e farlo sembrare infinito. La memoria virtuale dà l’aspetto di RAM illimitata e fork () dà l’aspetto di risorse CPU illimitate, entrambe importanti caratteristiche del sistema operativo per abilitare la portabilità delle applicazioni sui computer desktop e server.

In qualità di progettista che utilizza un kernel di separazione, è necessario allocare le risorse hardware alle VM in modo statico al momento dell’avvio e qualsiasi condivisione deve essere organizzata in modo speciale. È comune utilizzare 1 core della CPU per VM ed è utile disporre di schede di rete e porte seriali extra per accedere alle VM. Ovviamente, IPC  sono supportatitra VM e dispositivi virtuali e core CPU con suddivisione del tempo, ma il punto è che un kernel di separazione, beh, separa le cose. Questo può essere meno conveniente se sei abituato a tutto ciò che è disponibile all’interno dell’ambito globale di un RTOS. Soprattutto con i sistemi embedded, le risorse hardware sono invariabilmente limitate. In Lynx crediamo sia salutare per gli ingegneri embedded essere profondamente consapevoli dei limiti del proprio hardware. Senza tale consapevolezza è fin troppo facile sovraccaricare l’hardware.

Leggi: hai bisogno di un sistema operativo in tempo reale (RTOS)?

GUEST OS OVERHEAD I

GOS in esecuzione in una VM del kernel di separazione non hanno bisogno di sapere di essere virtualizzati. Hanno il controllo hardware diretto del core della CPU, della propria MMU e delle proprie periferiche. Possono tranquillamente funzionare in modalità kernel e programmare la loro MMU normalmente per impostare il proprio spazio utente per eseguire i processi utente. Durante il funzionamento in una giornata di sole non c’è overhead dell’hypervisor. Ciò consente ai GOS di essere eseguiti senza modifiche, una funzionalità estremamente potente. Lynx ha eseguito con successo Windows 7, Windows 10, CentOS, Ubuntu e Android su LynxSecure. Qualsiasi software aggiuntivo necessario al GOS, come un BIOS, viene inserito nella VM insieme al GOS. I sistemi operativi incorporati come FreeRTOS, ETAS RTA-OS, BAE STOP ™ OS, LynxOS-178®, Buildroot Linux, Yocto Linux, Xilinx PetaLinux funzionano anche su LynxSecure. Questa configurazione funziona sorprendentemente bene, risulta che i sistemi operativi sono contenuti in esecuzione su sottoinsiemi hardware limitati.

LYNX SECURE®

INTRODUZIONE

LynxSecure è un kernel di separazione come descritto da John Rusby nel suo documento del 1981 Design and Verification of Secure Systems. Rilasciato per la prima volta come prodotto autonomo nel 2006, è un prodotto maturo e ampiamente distribuito sviluppato da Lynx Software Technologies. Dopo le distribuzioni iniziali in applicazioni governative ad alta garanzia, il prodotto è stato implementato in volume in applicazioni commerciali e industriali mission-critical e in tutti i settori di mercato tra cui automobilistico, avionica, IoT industriale, robotica, trasporti e UAV. LynxSecure ha trovato applicazione come hypervisor superiore nei sistemi embedded e nei sistemi avionici critici per la sicurezza che cercano una separazione più forte per gestire le interferenze multicore. Supporta i sistemi di destinazione che eseguono Intel x86, Arm e PowerPC. Lynx Software Technologies ha un contratto per la certificazione di sicurezza LynxSecure a RTCA DO-178C DAL-A. Lynx offre anche un NIST Pacchetto diSP 800-53 come certificazione di sicurezza.

HARDWARE DI VIRTUALIZZAZIONE

Su Intel x86, il LynxSecure® kernel di separazioneutilizza VT-x, EPT*, VT-d† e SR-IOV per fornire controllo CPU annidato, controllo MMU annidato, isolamento DMA e controllo DMA annidato. L’hypervisor viene eseguito su Ring -1 (modalità hypervisor VT-x) e costruisce VM mappando memoria, periferiche, interrupt e DMA ai core della CPU. Usare l’hardware per fare il lavoro pesante è efficiente ed elegante e fa sì che LynxSecure sia un minuscolo (45 KB su x86) ma un pezzo di codice hardware-intimo. All’avvio, il compito di LynxSecure è configurare le sue VM e poi togliersi di mezzo. Durante il funzionamento, tutto ciò che rimane sono tabelle di pagine per mappare gli indirizzi fisici degli ospiti (GPA) negli indirizzi fisici dell’host (HPA) e gestori di eventi per reindirizzare gli interrupt e gestire le ipercall degli ospiti come il ripristino o lo spegnimento.

Le stesse funzionalità hardware utilizzate da LynxSecure (VT-x, EPT, VT-d e SR-IOV) sono già ampiamente utilizzate per il cloud computing nei data center. In questi sistemi, grandi stack di software basati su Linux come OpenStack consentono alle macchine virtuali che eseguono server Web Internet di essere attivate e disattivate dinamicamente per rispondere alle mutevoli richieste di traffico Internet. Tali sistemi dispongono di pool di risorse di archiviazione, di elaborazione e di rete virtuali che sono collegati insieme in proporzioni diverse per creare macchine virtuali su misura per carichi di lavoro diversi. È così che “funziona” Internet moderno. I kernel di separazione utilizzano la stessa tecnologia collaudata VT-x, EPT, VT-d e SR-IOV, ma in un modo integrato che configura le VM all’avvio e le blocca fino allo spegnimento.

LYNXSECURE NELLA PRATICA

Come lavorate con LynxSecure nella pratica? Qual è il flusso di lavoro per configurare il target, le VM e i GOS come desideri? Entrambe sono grandi domande, poiché l’utilizzo di un kernel di separazione è un cambio di paradigma. Non è più necessario solo un pacchetto di supporto della scheda (BSP) per dare il controllo del proprio hardware a un RTOS. Invece, il tuo kernel di separazione deve essere eseguito per primo.

La configurazione di LynxSecure è un processo in due fasi:

1. utilizzare l’utilità di rilevamento hardware di Lynx per recuperare il catalogo hardware dalla destinazione. Questa è un’utilità di avvio su x86 e legge daldella scheda di destinazione file dell’albero dei dispositivi (DTF)su Arm e PowerPC
2. Utilizza il nostro linguaggio di modellazione per definire le VM allocando le risorse dal catalogo (core, RAM, dispositivi) e popola le VM con le immagini del sistema operativo

Una volta completati questi passaggi, è sufficiente premere un pulsante ei nostri strumenti compilano tutto in uno speciale file bootloader binario che chiamiamo pacchetto di risorse di sistema (SRP). L’SRP avvia il target, programma l’VT-x, EPT*, VT-d† hardwaree SR-IOV per creare le VM, copia le immagini del sistema operativo e le esegue. Per avviare l’immagine SRP, dovrebbe essere posizionata nello stesso posto in cui sarebbe collocata un’immagine del kernel Linux (cioè, su una chiavetta USB o HDD per l’avvio UEFI o syslinux, o copiata in una flash accessibile da uboot, ecc.).

La “magia” avviene nello strumento LynxSecure che genera l’SRP. Si tratta di uno speciale strumento generatore che sa come creare un bootloader che, quando eseguito sul target, configura qualsiasi combinazione valida di core, RAM e dispositivi che scegli, nelle VM. Questo strumento esegue gran parte del lavoro di inizializzazione normalmente svolto da un RTOS BSP. Concettualmente è una sorta di generatore di BSP in grado di far fronte a qualsiasi configurazione BSP. Lo strumento LynxSecure SRP conosce SoC specifici come Xilinx Zynq UltraScale +, NXP S32V, LS1046A e T2080. A parte gli obiettivi Intel, che sono ampiamente compatibili, supportare un nuovo SoC è per noi un compito impegnativo.

SISTEMI DI COSTRUZIONE SU LYNXSECURE

Quali sono le implicazioni pratiche della scelta di LynxSecure per il tuo progetto? I kernel di separazione si basano su hardware di virtualizzazione avanzato come VT-x, EPT*, VT-d†e, in quanto tali, sono disponibili solo su CPU di fascia alta create pensando agli hypervisor. Ma, con la legge di Moore dalla nostra parte, sono disponibili molte opzioni SoC integrate. Su Arm, LynxSecure richiede l’architettura Armv8-A, ovvero la variante A (applicazione) vs R (tempo reale) o M (microcontrollore) della v8. I core che utilizzano Armv8-A includono Cortex-A53 e Cortex-A72 usati da Xilinx, NXP e altri. Il core PowerPC e6500 di NXP dispone anche di hardware di virtualizzazione avanzato ed è supportato.

KERNEL DI SEPARAZIONE: UN SEGRETO APERTO

I kernel di separazione aprono un mondo completamente nuovo di libertà di progettazione e flessibilità per i progetti. Forniscono un’importante opportunità per avere un grande impatto sull’architettura software del tuo sistema embedded. Il concetto è solido, pubblico, maturo e collaudato e tuttavia sorprendentemente è rimasto in gran parte inutilizzato. Il kernel di separazione è particolarmente rilevante oggi poiché è una soluzione elegantemente elegante per processori multi-core e per processori con funzionalità di virtualizzazione hardware avanzate. Con un kernel di separazione, un processore così completo può essere trattato come un set di componenti Lego da cui sono possibili dozzine di combinazioni di configurazioni VM. Il numero di VM e l’hardware che ciascuno possiede può essere personalizzato per adattarsi all’architettura di sistema desiderata. Le VM possono essere trattate come schede virtuali per consentire il consolidamento a grana grossa di una manciata di applicazioni legacy basate su RTOS, oppure puoi andare in città e definire dozzine di VM leggere connesse in una lunga catena di servizi o qualsiasi combinazione intermedia. I kernel di separazione consentono questi casi d’uso perché sono più efficienti di altri hypervisor. Si affidano all’hardware per fare il lavoro pesante ed evitare di imporre un RTOS di supporto ai propri utenti. Il loro ingombro ridotto, i bassi costi generali e la configurazione statica si allineano bene con le esigenze dei sistemi integrati, in tempo reale e critici per la sicurezza.

Con un kernel di separazione, i principi di progettazione MOSA possono essere estesi oltre il software applicativo alle VM e rafforzati applicando le interfacce a tali VM nell’hardware. Le risorse hardware del processore possono essere suddivise in modo affidabile in VM con sovraccarico quasi pari a zero popolate con una combinazione di sistemi operativi, RTOS e applicazioni bare metal di vari fornitori. Non solo questo rompe il vincolo del fornitore, ma supportando una gamma più ampia di carichi software, da Linux completo, a RTOS e applicazioni bare-metal, consente di utilizzare il mix “Goldilocks” di RTOS appena sufficiente .

È possibile costruire sistemi di sicurezza a criticità mista che riducano al minimo il numero elevato di DAL righe di codice (SLOC)per ridurre i costi di certificazione. I sistemi di sicurezza multi-core possono essere costruiti in modo estremamente ridotto per mitigare i problemi di interferenza, ad esempio, con una configurazione VM che utilizza esclusivamente applicazioni bare-metal senza RTOS, senza scheduler, senza condivisione del core della CPU e senza condivisione di dispositivi i / o.

In breve, i kernel di separazione consentono la scelta. Nessun fornitore, Lynx incluso, può offrire tutte le opzioni, né ogni combinazione di tecnologia è compatibile. Ma ciò che fa un kernel di separazione è aprire le porte e abilitarne di più combinazioni per combaciare rispetto a prima. In qualità di ingegnere integrato, questo ti offre una maggiore scelta di design. La scelta di essere più innovativi e l’opportunità di costruire un prodotto migliore nel tuo mercato in qualunque dimensione tu scelga, che si tratti di dimensioni, prezzo, flessibilità, caratteristiche, manutenibilità, protezione, sicurezza o prestazioni. Ci sono una miriade di opzioni di progettazione, architetture di sistema e componenti software a tua disposizione. Assicurati di comprendere il quadro completo per evitare di limitare inutilmente le tue opzioni. Non prendere accidentalmente un hypervisor se un kernel di separazione sarebbe stato migliore. Prenditi il ​​tuo tempo, fai la tua ricerca e mantieni le tue opzioni aperte per trovare la migliore tecnologia per il tuo progetto.

* Tabelle pagine estese

†virtualizzazione hardware equivalenti vengono utilizzate su Arm (EL2 e SMMU) e PowerPC (E.HV).

‡ Fatta eccezione per il kernel di separazione stesso

Ti serve una consulenza tecnica? Contattami e vedrò di trovare la risorsa IT più adeguata