|
|
On Fri, 04 Dec 2009 20:57:45 +0000, Philip Paeps wrote:
> Philip Paeps <philip+usenet@xxxxxxxx> wrote:
>> goarilla <kevin.paulus@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>> On Fri, 04 Dec 2009 18:28:44 +0000, Philip Paeps wrote:
>>>> Frank Van Damme <frank.vandamme@xxxxxxxxx> wrote:
>>>>> Op Fri, 04 Dec 2009 10:18:00 +0000, schreef Philip Paeps:
>>>>>>> Had het ook al geprobeerd, verbazingwekkend.
>>>>>>
>>>>>> Waarom is dat zo verbazingwekkend, dan?
>>>>>
>>>>> Omdat je uw cpu geen instructies kan geven om uit te voeren? Mij
>>>>> leek het een onlogische zaak dat je "niets" kan uitvoeren.
>>>>
>>>> Er zit ook nog een kernel tussen hÃ. :-)
>>>
>>> ja maar is het niet beter om de kernel zo weinig mogelijk erbij te
>>> halen als het gaat om userspace code
>>
>> Eh, zo werkt Unix niet.
>>
>>> /bin/true zou toch in pure ASM moeten geschreven worden en dan
>>> geassembled worden met de assembler die het het beste doet (yasm/nasm/
>>> masm ...)
>>
>> Why? Als je die assembled code wil draaien, moet je nog steeds door
>> exec() gaan. De enige manier om uit de kernel te blijven, is door in
>> de context van je draaiende proces te blijven. In casu dat de shell
>> het builtin heeft. De meeste shells hebben een builtin "true".
>>
>>> is het niet beter om $0 te proppen in eax dan int 20 te roepen om dan
>>> terug controle the geven aan het OS (dit komt van ver uit mijn
>>> geheugen -- en voornamelijk uit het boek 'programming from the ground
>>> up' -- kritiek op dit en op dit boek (philip ik kijk naar jouw) is
>>> zeker geapprecieerd) ?
>>
>> Dit is architectuur-afhankelijk (i386). INT 20h is inderdaad de
>> "terminate program" interrupt onder DOS. Ik weet niet hoe Linux die
>> interrupt afhandelt, maar ik kan me voorstellen dat die niet zo
>> triviaal is als onder DOS.
>>
>> Op Unix kan je niet gewoon "code beginnen te draaien". Je hebt er een
>> proces voor nodig. Je shell doet dat door een kopie van zichzelf te
>> fork()en en jouw image erin te exec()en. Als jouw image "leeg" is,
>> geeft de image activator 0 terug en de kous is af.
>>
dat was il eventjes vergeten
het is theorie en ik haat theorie tenzij ik hetzelf
praktisch hebben kunnen testen
dan steekt het boven in het brein voor altijd
>> Uiteraard mag je, als je dat leuk vindt, de code in dat image in
>> assembler schrijven, en daar mag je ook 0 returnen. But why bother?
>> Als het image leeg is, krijg je ook 0 terug, en dat zonder een
>> instructie meer door te fietsen.
>
impliciet verklaart dat wel
wrom je niet gewoon memtest kunt draaien onder linux zonder ...
de kernel en je draaiend systeem te verliezen
> Voor alle duidelijkheid: voor er nog maar een instructie van jouw image
> gezien wordt, zijn er al minstens twee context switches gebeurd.
>
> - Philip
ja ok maar dit is toch wel een beetje x86 specifiek
gaat de arm ook van real mode naar protected mode zo
vaak als de x86? (dat is toch een context-switch in hw)
(ja ik zuig dit uit mijn duim, ik heb mijn eigen theorieen gemaakt over de
werking van de pc, er zit een heus simulatiekanon in mijn brein - die raar
maar waar, veel te menselijk is en dus ongeloofelijk incorrect )
simulatie begint in het hoofd en niet in de vm !
|
|