[c/c++] plugin manager

[Verwijderd]

Ik ben met een projectje bezig, waar ik een bepaalde functionele core in heb. Die core bevat een soort van virtueel file-systeempje. Waar ik tekst, binaire data en functies in kan mouten.

Het word een soort van (bash, maar toch ook weer helemaal niet, achtige) shell. Je tikt het path in van een funtie en dan voert ie dat uit. Allemaal vanuit het RAM.

Nu moeten de functies per pakketje uit een dll gehaald worden, die dynamisch ingeladen word. Je kan zo dus runtime de functionalitiet van de core uitbreiden.
Dat werkt nog niet helemaal, maar dat moet geen probleem worden, zoek ik allemaal nog wel uit.

Waar ik wel mee zit, de beveiliging. Ik wil het uiteindelijk multi-user gaan maken. Maar stel je voor je bent als user ingelogd en je laad een module in voot het afspelen van mp3's. Wat vanaf dan mogelijk is vanuit mijn shell. Als die module een vette bug genereerd, is dat een probleem, omdat niet alleen de mp3-module door het OS het geheugen uit word gepleurd, maar ook de core.
Die draaien immers in dezelfde process space.

Ik heb hier nog niet echt een idee voor, en om nou elk plugin-pakketje in een appart process op te laten starten en dan via sockets (ofzo) te gaan communiceren lijkt me ook een beetje omslachtig.

Iemand suggesties...

[Verwijderd]

Hmm out of process com wellicht een idee?

[LordLarry]

Of gewoon die excepties afvangen?

[MSalters]

Tsja, welk OS je gebruikt en welke compiler, dat maakt veel uit. Onder DOS kan een dikke bug in zo'n plugin je PC crashen, geen bescherming tegen mogelijk. En dan kan je core niet veel meer als die geen CPU tijd meer krijgt.
IHA kun je jezelf alleen beschermen als je zelf nog CPU tijd kunt krijgen, du het moet multi-threaded/multi-process. Bovendien moet je je core data beschermen, en het gemiddelde OS biedt alleen processen memory protection. Dus dat wordt dan een out-of-process component.

[Verwijderd]

Out of proces component??? never heard of...

Maar het moet uiteindelijk redelijk platvorm onafhankelijk worden. Dan moet je niet aan DOS gaan denken, maar wel zowel unix/linux als win32. Nu is het niet erg om dan twee versies te maken, als het princiepe maar hetzelfde is.

Als je exceptions afvangt vangt die dan alle exceptions af, onafhankelijk van hoe *diep* ze aangeroepen worden. En werkt dit op elk OS zo goed als hetzelfde.
Want dan is het opzich een goed idee, de eerste de beste exception zorgt dat mijn handler het plugin-pakketje als het ware netjes 'unmount' en een melding geeft, maar wel netjes door blijft draaien... Maaruh.. vangt ie dan echt ALLES af ??

De bescherming van core date heb ik wel een ideetje voor, de plugins zullen nooit achter de pointer naar de core-structuren kunnen komen.

[MSalters]

Op woensdag 17 juli 2002 14:54 schreef unteraarsch het volgende:
Out of proces component??? never heard of...

Maar het moet uiteindelijk redelijk platvorm onafhankelijk worden. Dan moet je niet aan DOS gaan denken, maar wel zowel unix/linux als win32. Nu is het niet erg om dan twee versies te maken, als het princiepe maar hetzelfde is.

Als je exceptions afvangt vangt die dan alle exceptions af, onafhankelijk van hoe *diep* ze aangeroepen worden. En werkt dit op elk OS zo goed als hetzelfde.

Exceptions, ja. Stack smashes, nee.

Want dan is het opzich een goed idee, de eerste de beste exception zorgt dat mijn handler het plugin-pakketje als het ware netjes 'unmount' en een melding geeft, maar wel netjes door blijft draaien... Maaruh.. vangt ie dan echt ALLES af ??

Nee dus.

De bescherming van core date heb ik wel een ideetje voor, de plugins zullen nooit achter de pointer naar de core-structuren kunnen komen.

Tsja:

code:

extern int main();
unsigned char* ptr = (unsigned char*)&main;
// of unsigned char* ptr = 0
do
{
  *ptr = 0;
  ++ptr;
}
while ( ptr );

Wat het precies overschrijft hangt van het OS af, maar 't is niet leuk.

[Verwijderd]

Out of proces component??? never heard of...

Er wordt outer-process communicatie bedoeld.
Ofwel, communiceren tussen processen.
Je operating system heeft daar vast wel een hele set van mogelijkheden voor, onder andere misschien wel:

- named pipes
- messages
- network sockets
- shared memory

Bij sommige vormen (zoals bijvoorbeeld shared memory) kan je te maken krijgen met synchronisatie problemen, maar daar heeft je operating system vast ook wel een set van mogelijkheden voor.

Welk operating system praten we eigenlijk over? Je noemt bash en filesystems, dus ik neem aan iets van linux of een variant?

[Verwijderd]

Ik ben het nu onder win32 aan het ontwikkelen, maar af en toe port ik het (voor zover het kan) naar linux. Om te testen of het nog wel OS onafhankelijk genoeg is. Maar ik maakte meer een vergelijking met bash omdat een vergelijking met command.com niet helemaal op zijn plek is...

Maar de communicatie via sockets of messages zie ik niet zo zitten, shared memory klinkt al weer beter. Want sockets / messages (sowiezo alleen onder win32, als kan je linux misschien SIGNALS gebruiken) vereisen dat je er een heel protocol omheen maakt, wat waarschijnlijk weer veel andere beveiligings problemen met zich meer kan brengen.

Shared memory heb ik wel eens over gelezen in een linux programmeer boek, maar is dit ook in windows toepasbaar?

Als ik in windows de GlobalAlloc gebruik, is het gealloceerde geheugen dan ook alleen bruikbaar vanuit het process die dit gealloceerd heeft, of moet je daar een LocalAlloc (ofzo) voor gebruiken.

Want dan zet ik alle core-data op een private heap, en alle plugin data op een shared memory block. Zodat de core wel de plugin kan benaderen maar niet andersom...
(Nu wil ik eigenlijk ook weer niet dat plugin-A data van plugin-B kan lezen/schrijven, maar hier is bij de shared mem implementatie vast wel rekening mee gehouden.. toch?)

[Verwijderd]

Wat jij probeert zijn allemaal typische OS dingetjes. Een OS is een zeer lowlevel iets en wordt bij het bieden van zijn diensten (dingen als beveiliging van geheugen enzo) ondersteund door de hardware. Als je dus OS-achtige functionaliteit wilt bieden moet je gebruik maken van de mogelijkheden die je OS daar voor biedt. Windows en UNIX zijn dusdanig verschillend dat het bijna onmogelijk is om iets te maken wat voldoende beveiliging biedt EN platform onafhankelijk is.

Ik zou zelf voor die plugins ook kiezen voor een out-of-process aanpak. Communicatie zou ik doen via pipes denk ik, aangezien zowel UNIX als Windows die dingen hebben en het verschil tussen beide aanpakken redelijk beperkt is. Shared memory zou ik niet als een optie kiezen omdat het een dienst is die een OS wel biedt, maar die vaak nogal wat nare implicaties heeft en je je allerlei synchronisatie problemen op de hals haalt...

[Fuzzillogic]

Wat ik eens heb gedaan in Win32 is dit:

code:

__try {
    CallToDLLFunction();
}
__except (true) {
    FlikkerDLLUitGeheugen();
    ZegFoeiTegenUser();
}

Dat werkt redelijk, maar het blijft idd goed mogelijk dat de DLL dermate foute dingen uithaalt dat het hele process om zeep geholpen wordt. Lijkt me dat het dan m.n. gaat om overschrijven van data van de core zelf dat de brokken kan maken.

Om het echt veilig te maken zul je toch met verschillende processen aan de slag moeten gaan. In win32 is het mogelijk dat je een nieuw process aanmaakt, zonder daarvoor dingen naar HD te schrijven. Maar voor de portabiliteit is het misschien handig als je een kleine exe maakt, die de betreffende DLL aanroept en de communicatie met de core kan verzorgen.

My €0.02

[MSalters]

Op woensdag 17 juli 2002 22:27 schreef unteraarsch het volgende:
...
Maar de communicatie via sockets of messages zie ik niet zo zitten, shared memory klinkt al weer beter. Want sockets / messages (sowiezo alleen onder win32, als kan je linux misschien SIGNALS gebruiken) vereisen dat je er een heel protocol omheen maakt, wat waarschijnlijk weer veel andere beveiligings problemen met zich meer kan brengen.

TCP naar 127.0.0.1 doet't op Linux ook hoor.

Shared memory heb ik wel eens over gelezen in een linux programmeer boek, maar is dit ook in windows toepasbaar?

'Tuurlijk. Check MSDN maar.

Als ik in windows de GlobalAlloc gebruik, is het gealloceerde geheugen dan ook alleen bruikbaar vanuit het process die dit gealloceerd heeft, of moet je daar een LocalAlloc (ofzo) voor gebruiken.

Nee, en bovendien is GlobalAlloc() bedoeld voor de implementatie van malloc/new, niet direct voor jouw gebruik.

Want dan zet ik alle core-data op een private heap, en alle plugin data op een shared memory block. Zodat de core wel de plugin kan benaderen maar niet andersom...
(Nu wil ik eigenlijk ook weer niet dat plugin-A data van plugin-B kan lezen/schrijven, maar hier is bij de shared mem implementatie vast wel rekening mee gehouden.. toch?)

Ja; shared memory wordt alleen geshared door de processen die daarom vragen. Dus block A voor plugin A is alleen toegankelijk voor de manager en plugin A.
Overigens wil je niet alle data van plugin A in dat block zetten, dat wordt veel te complex. Het probleem is nl. dat dat block wel dezelfde bytes bevat gezien vanuit de verschillende processen, maar niet op hetzelfde adres. Je kunt dus in zo'n block geen pointer naar een ander veld in dat block zetten; die pointer verschilt tussen de twee processen.

[MSalters]

Op donderdag 18 juli 2002 02:45 schreef Nexxennium het volgende:
Wat ik eens heb gedaan in Win32 is dit:

code:

__try {
    CallToDLLFunction();
}
__except (true) {
    FlikkerDLLUitGeheugen();
    ZegFoeiTegenUser();
}

Dat werkt redelijk, maar het blijft idd goed mogelijk dat de DLL dermate foute dingen uithaalt dat het hele process om zeep geholpen wordt.

Zoals exit(0);