Programim dhe zhvillim, javascript, python, php, html

Kur zbatoni një thirrje sistemi, si e ekspozoni numrin e thirrjes së sistemit në territorin e përdoruesit?

Po merrem me thirrjet e sistemit. Kam shtuar dy të reja dhe kam verifikuar se funksionojnë duke përdorur telefonatat në syscall.

Do të doja që numrat e syscall-it të ishin në një kokë, në mënyrë që hapësira e përdoruesve të mos ketë nevojë ta dijë në mënyrë eksplicite numrin e syscall-it.

Në arch/x86/syscalls/syscall_64.tbl kam:

317     64      krun_read_msrs                  sys_krun_read_msrs
318     64      krun_reset_msrs                 sys_krun_reset_msrs

Dhe disa grepping sugjerojnë që kbuild ka gjeneruar automatikisht makrot për sistemet e reja:

$ ag __NR_krun *
arch/x86/include/generated/uapi/asm/unistd_64.h
321:#define __NR_krun_read_msrs 317
322:#define __NR_krun_reset_msrs 318

Emri i skedarit sugjeron që nuk kam nevojë t'i shtoj shënimet me dorë, por kjo është në kundërshtim me atë që duhet të thonë dokumentet e kernel Linux:

Some architectures (e.g. x86) have their own architecture-specific syscall tables, but several other architectures share a generic syscall table. Add your new system call to the generic list by adding an entry to the list in include/uapi/asm-generic/unistd.h:

#define __NR_xyzzy 292
__SYSCALL(__NR_xyzzy, sys_xyzzy)

Epo, sistemet e mia janë specifike x86_64, pasi ato lexojnë dhe shkruajnë MSR që gjenden vetëm në çipat Intel. Kështu që pas kësaj, unë shkova duke gërmuar për të parë nëse mund të gjeja kokën specifike të harkut për sistemin tim amd64.

Ju do të prisni që të jetë nën arch/x86_64, por nuk ka fare përfshirje atje. Pra, supozoj se x86_64 trashëgon nga x86. Duke qenë kështu, titulli specifik i harkut duhet të jetë:

arch/x86/include/uapi/asm/unistd.h

Nëse e hapni atë, është vetëm një mbështjellës i vogël për t'u dërguar në bazë të harkut:

# ifdef __i386__                                                                
#  include <asm/unistd_32.h>                                                    
# elif defined(__ILP32__)                                                       
#  include <asm/unistd_x32.h>                                                   
# else                                                                          
#  include <asm/unistd_64.h>                                                    
# endif

Pra, me sa duket është projektuar për të marrë /usr/include/x86_64-linux-gnu/asm/unistd.h, por kjo nuk përfshin ende numrat e mi të ri syscall.

Unë do të prisja që objektivi headers_install të instalonte titujt e rinj (ndoshta), por mjerisht jo.

Jam konfuz. A duhet t'i shtoj syscal-et e mia të reja në një skedar manualisht apo jo? Nëse po, cili skedar? Nëse jo, si mund t'i ekspozoj makrot __NR_* të krijuara automatikisht në hapësirën e përdoruesit në një vendndodhje standarde?

Faleminderit

c linux linux-kernel system-calls
24.07.2017

  • Ju nuk keni nevojë domosdoshmërisht, nëse zbatoni funksione mbështjellëse në një bibliotekë për të thirrur syscalls. Kjo është, në fund të fundit, pjesa më e madhe e asaj që bëjnë bibliotekat C në sistemet POSIXy. Ju mund të bëni që skedarët e kokës së bibliotekës të ekspozojnë numrat e syscall (të përshtatshme për arkitekturën aktuale). Për të përfshirë sisteme të reja për të gjithë përdoruesit e Linux-it, do t'ju duhet ta shtyni patch-in në rrjedhën e sipërme si në kernelin Linux (nëpërmjet LKML), ashtu edhe në bibliotekën GNU C, ose në shpërndarje specifike, në mënyrë që ata të shtojnë ndryshimet në titujt e sistemit të tyre. . 24.07.2017
  • Po, kjo nuk është vërtet e realizueshme, pasi syscalls nuk janë të përshtatshme për përdorim të përgjithshëm. 24.07.2017
  • Çfarë (nuk është e realizueshme), duke i mbështjellë syscalls në funksione? (Nëse do të thotë ta shtysh atë në rrjedhën e sipërme, unë jam dakord.) Megjithatë, duhet të konsiderosh mbështjelljen e syscalls në funksione; edhe nëse funksionon po aq statik inline në një skedar header, duke zgjedhur numrin e duhur të syscall-it bazuar në harkun dhe madhësinë e fjalës (duke përdorur makrot e paraprocesorit). Është shumë më e lehtë të sigurohet skedari i titullit ekstra së bashku me kernelin e modifikuar (ose modifikimet e kernelit), sesa të përfshihen artikujt shtesë në skedarët standard të kokës. 24.07.2017
  • Të kesh funksione mbështjellëse do të ishte mirë, po, por hapi i parë është vërtet të provosh të eksportosh __NR_* dhe miqtë. A nuk do të vareshin funksionet e mbështjellësit që propozoni nga ato gjithsesi? Më duhet vetëm një mënyrë për të ditur numrin e syscall-it, i cili mund të ndryshojë sipas versionit të harkut ose kernelit. 24.07.2017
  • Ah, tani e kuptoj. Problemi është se shumica e shpërndarjeve Linux nuk përdorin titujt e hapësirës së përdoruesit të ofruar nga kerneli; në vend të kësaj, ata përdorin skedarë kokë të ofruar nga biblioteka C dhe çdo bibliotekë tjetër zhvillimi të instaluar. Për shembull, Debian (dhe derivatet e Debian si Ubuntu, Mint, e kështu me radhë) i mban kokat e kernelit në /usr/src/linux-headers-$(uname -r)/ (për atë aktual); numrat e syscall-it për kernelin aktual janë në /usr/src/linux-headers-$(uname -r)/uapi/asm-generic/unistd.h. Funksioni wrapper mund të përdorë funksionin e bibliotekës uname() C për të marrë rrymën [...] 24.07.2017
  • [...] versioni i kernelit, dhe zgjidhni numrin e syscall-it bazuar në atë. Unë personalisht do të ofroj skedarin e kokës së bashku me paketën e kernelit, me ndërtimin e kernelit tuaj të zgjeruar me të dyja patch-in tuaj, si dhe një patch që gjeneron skedarin e kokës për atë kernel specifik. Nëse numri syscall ndryshon nga kerneli në kernel, atëherë qasja uname() është e nevojshme (në thirrjen e parë); duhet të mjaftojë një grup i thjeshtë i versioneve të kernelit (dhe madhësia e fjalës në x86-64) me numrin syscall. Lehtësia e mirëmbajtjes është çelësi në këto raste. 24.07.2017
  • ok, kështu që unë do të përpiqem që ndërtimi i kernelit të instalojë një kokë të krijimit tim. 24.07.2017
  • @EddBarrett, syscalls janë sipas përkufizimit, për përdorim të përgjithshëm. Nëse nuk po i shkruani për këtë qëllim, ndoshta problemi juaj nuk është i përcaktuar mirë. Ndërfaqja juaj me kernelin do të duhet të rregullohet ndërsa kerneli evoluon dhe ambientet tuaja të shkrimit të thirrjeve të sistemit duhet të plotësojnë këtë kërkesë. Nëse telefonatat e sistemit tuaj nuk do të jenë të përdorimit të përgjithshëm, thjesht mos i shkruani ato. 26.07.2017
  • Thirrjet e sistemit janë për një pjesë të kërkimit shkencor. E tillë është natyra e hulumtimit kam frikë. 01.08.2017

Përgjigjet:


1

Numrat aktual të thirrjeve të sistemit të caktuar nga procesi i ndërtimit të kernelit janë pjesë e procesit të ndërtimit të kernelit... kështu që ju nuk merrni numrat aktualë përfundimtarë, por vetëm në një kernel të ndërtuar tashmë. Ndërtoni kernelin tuaj dhe do të shihni detyrat aktuale në një skedar të ndërtuar me kokë. Kam frikë se jeni përpjekur t'i kërkoni në një burim të pastër kernel, dhe kjo është arsyeja që nuk e gjeni skedarin e duhur të përfshirjes.

Nga ana tjetër, fshehja e numrit aktual të thirrjes së sistemit është mjaft e zakonshme dhe bëhet nga një rutinë mbështjellëse që përfshin kokën e kernelit të përmendur më sipër dhe përdor simbolin #defined për të përfaqësuar numrin e thirrjes për të bërë thirrjen aktuale __SYSCAL(...). Kjo është normalisht edhe e nevojshme, pasi çdo thirrje sistemi ka normalisht një ndërfaqe të ndryshme. Të gjitha thirrjet normale të sistemit që përdorni kanë përfshirë mbështjellës në stdlib, por i riu nuk do të përfshihet. Ju keni dy qasje këtu: të rregulloni bibliotekën standarde C për të përfshirë (dhe shkruani një skedar standard të kokës për prototipin e funksionit diku në /usr/include) OSE për të përfshirë skedarin mbështjellës mySysCall.o (ky emër është në lehtësinë tuaj ) në të gjitha programet ku do të përdorni syscall-in e ri.

26.07.2017

2

Epo, unë kam një përgjigje të pjesshme. I pjesshëm sepse është specifik për Debian.

Nëse përdorni objektivin make deb-pkg në burimet e kernelit, atëherë paketat .deb krijohen në drejtorinë prind. Nëse më pas i instaloni këto, atëherë titujt tuaj do të instalohen në sistem.

Pasi ta bëj këtë për kernelin tim të përshkruar më sipër:

$ grep krun /usr/include
/usr/include/asm/unistd_64.h:#define __NR_krun_read_msrs 317
/usr/include/asm/unistd_64.h:#define __NR_krun_reset_msrs 318
25.07.2017
Materiale të reja
Masterclass Coroutines: Kapitulli-3: Anulimi i korutinave dhe trajtimi i përjashtimeve.
Mirë se vini në udhëzuesin gjithëpërfshirës mbi Kotlin Coroutines! Në këtë seri artikujsh, unë do t'ju çoj në një udhëtim magjepsës, duke filluar nga bazat dhe gradualisht duke u thelluar në..
Faketojeni derisa ta arrini me të dhënat false
A e gjeni ndonjëherë veten duke ndërtuar një aplikacion të ri dhe keni nevojë për të dhëna testimi që duken dhe duken më realiste ose një grup i madh të dhënash për performancën e ngarkesës...
Si të përdorni kërkesën API në Python
Kërkesë API në GitHub për të marrë depot e përdoruesve duke përdorur Python. Në këtë artikull, unë shpjegoj procesin hap pas hapi për të trajtuar një kërkesë API për të marrë të dhëna nga..
Një udhëzues hap pas hapi për të zotëruar React
Në këtë artikull, do të mësoni se si të krijoni aplikacionin React, do të mësoni se si funksionon React dhe konceptet thelbësore që duhet të dini për të ndërtuar aplikacione React. Learning..
AI dhe Psikologjia — Pjesa 2
Në pjesën 2 të serisë sonë të AI dhe Psikologji ne diskutojmë se si makineritë mbledhin dhe përpunojnë të dhëna për të mësuar emocione dhe ndjenja të ndryshme në mendjen e njeriut, duke ndihmuar..
Esencialet e punës ditore të kodit tim VS
Shtesat e mia të preferuara - Git Graph 💹 Kjo shtesë është vërtet e mahnitshme, e përdor përpara se të filloj të punoj për të kontrolluar dy herë ndryshimet dhe degët më të fundit, mund të..
Pse Python? Zbulimi i fuqisë së gjithanshme të një gjiganti programues
Në peizazhin gjithnjë në zhvillim të gjuhëve të programimit, Python është shfaqur si një forcë dominuese. Rritja e tij meteorike nuk është rastësi. Joshja e Python qëndron në thjeshtësinë,..