નાના બાળકો માટે BPF, ભાગ એક: વિસ્તૃત BPF

શરૂઆતમાં એક ટેક્નોલોજી હતી અને તેને BPF કહેવામાં આવતું હતું. અમે તેના તરફ જોયું અગાઉના, આ શ્રેણીનો ઓલ્ડ ટેસ્ટામેન્ટ લેખ. 2013 માં, એલેક્સી સ્ટારોવોઇટોવ અને ડેનિયલ બોર્કમેનના પ્રયાસો દ્વારા, આધુનિક 64-બીટ મશીનો માટે ઑપ્ટિમાઇઝ કરાયેલ તેનું સુધારેલું સંસ્કરણ, વિકસાવવામાં આવ્યું અને Linux કર્નલમાં શામેલ કરવામાં આવ્યું. આ નવી ટેકનોલોજીને સંક્ષિપ્તમાં આંતરિક BPF તરીકે ઓળખવામાં આવી હતી, ત્યારબાદ તેનું નામ એક્સટેન્ડેડ BPF રાખવામાં આવ્યું હતું, અને હવે, ઘણા વર્ષો પછી, દરેક તેને ફક્ત BPF કહે છે.

સામાન્ય રીતે કહીએ તો, BPF તમને Linux કર્નલ સ્પેસમાં મનસ્વી રીતે વપરાશકર્તા દ્વારા પૂરા પાડવામાં આવેલ કોડ ચલાવવાની મંજૂરી આપે છે, અને નવું આર્કિટેક્ચર એટલું સફળ બન્યું છે કે તેની બધી એપ્લિકેશનોનું વર્ણન કરવા માટે અમને વધુ ડઝન લેખોની જરૂર પડશે. (વિકાસકર્તાઓએ માત્ર એક જ વસ્તુ સારી રીતે કરી ન હતી, જેમ કે તમે નીચેના પ્રદર્શન કોડમાં જોઈ શકો છો, તે યોગ્ય લોગો બનાવતી હતી.)

આ લેખ BPF વર્ચ્યુઅલ મશીનનું માળખું, BPF સાથે કામ કરવા માટેના કર્નલ ઇન્ટરફેસ, વિકાસ સાધનો, તેમજ હાલની ક્ષમતાઓની ટૂંકી, ખૂબ જ સંક્ષિપ્ત ઝાંખીનું વર્ણન કરે છે, એટલે કે. BPF ના વ્યવહારુ કાર્યક્રમોના ઊંડા અભ્યાસ માટે આપણને ભવિષ્યમાં જરૂર પડશે તે બધું.

લેખનો સારાંશ

BPF આર્કિટેક્ચરનો પરિચય. સૌપ્રથમ, અમે BPF આર્કિટેક્ચરનું પક્ષીદર્શન કરીશું અને મુખ્ય ઘટકોની રૂપરેખા કરીશું.

BPF વર્ચ્યુઅલ મશીનની રજિસ્ટર અને કમાન્ડ સિસ્ટમ. એકંદરે આર્કિટેક્ચરનો પહેલેથી જ ખ્યાલ હોવાથી, અમે BPF વર્ચ્યુઅલ મશીનની રચનાનું વર્ણન કરીશું.

BPF ઑબ્જેક્ટ્સ, bpffs ફાઇલ સિસ્ટમનું જીવન ચક્ર. આ વિભાગમાં, અમે BPF ઑબ્જેક્ટ્સ - પ્રોગ્રામ્સ અને નકશાના જીવન ચક્રને નજીકથી જોઈશું.

bpf સિસ્ટમ કૉલનો ઉપયોગ કરીને ઑબ્જેક્ટનું સંચાલન કરવું. પહેલાથી જ સિસ્ટમની થોડી સમજણ સાથે, અમે આખરે ખાસ સિસ્ટમ કૉલનો ઉપયોગ કરીને યુઝર સ્પેસમાંથી ઑબ્જેક્ટ્સ કેવી રીતે બનાવવી અને તેની હેરફેર કરવી તે જોઈશું - bpf(2).

Пишем программы BPF с помощью libbpf. અલબત્ત, તમે સિસ્ટમ કૉલનો ઉપયોગ કરીને પ્રોગ્રામ્સ લખી શકો છો. પરંતુ તે મુશ્કેલ છે. વધુ વાસ્તવિક દૃશ્ય માટે, પરમાણુ પ્રોગ્રામરોએ એક પુસ્તકાલય વિકસાવ્યું libbpf. અમે એક મૂળભૂત BPF એપ્લિકેશન હાડપિંજર બનાવીશું જેનો અમે અનુગામી ઉદાહરણોમાં ઉપયોગ કરીશું.

કર્નલ હેલ્પર્સ. અહીં આપણે શીખીશું કે કેવી રીતે BPF પ્રોગ્રામ કર્નલ હેલ્પર ફંક્શન્સને એક્સેસ કરી શકે છે - એક સાધન જે નકશા સાથે, ક્લાસિકની સરખામણીમાં નવા BPFની ક્ષમતાઓને મૂળભૂત રીતે વિસ્તૃત કરે છે.

BPF પ્રોગ્રામ્સમાંથી નકશાની ઍક્સેસ. આ બિંદુએ, અમે નકશાનો ઉપયોગ કરતા પ્રોગ્રામ્સ કેવી રીતે બનાવી શકીએ તે બરાબર સમજવા માટે પૂરતા પ્રમાણમાં જાણીશું. અને ચાલો મહાન અને શકિતશાળી વેરિફાયરમાં એક ઝડપી ડોકિયું પણ કરીએ.

વિકાસ સાધનો. પ્રયોગો માટે જરૂરી ઉપયોગિતાઓ અને કર્નલ કેવી રીતે એસેમ્બલ કરવા તે અંગેનો સહાય વિભાગ.

નિષ્કર્ષ લેખના અંતે, જેઓ આટલું વાંચે છે તેઓને પ્રેરક શબ્દો અને પછીના લેખોમાં શું થશે તેનું ટૂંકું વર્ણન મળશે. અમે એવા લોકો માટે સ્વ-અભ્યાસ માટેની સંખ્યાબંધ લિંક્સ પણ સૂચિબદ્ધ કરીશું જેમની પાસે ચાલુ રાખવાની રાહ જોવાની ઇચ્છા અથવા ક્ષમતા નથી.

BPF આર્કિટેક્ચરનો પરિચય

અમે BPF આર્કિટેક્ચરને ધ્યાનમાં લેવાનું શરૂ કરીએ તે પહેલાં, અમે એક છેલ્લી વાર (ઓહ) નો સંદર્ભ લઈશું ક્લાસિક BPF, જે RISC મશીનોના આગમનના પ્રતિભાવ તરીકે વિકસાવવામાં આવી હતી અને કાર્યક્ષમ પેકેટ ફિલ્ટરિંગની સમસ્યાને હલ કરી હતી. આ આર્કિટેક્ચર એટલું સફળ બન્યું કે, બર્કલે UNIX માં ડૅશિંગ નેવુંના દાયકામાં જન્મ્યા પછી, તે મોટાભાગની હાલની ઑપરેટિંગ સિસ્ટમ્સમાં પોર્ટ કરવામાં આવી હતી, તે ક્રેઝી વીસમાં ટકી રહી હતી અને હજુ પણ નવી એપ્લિકેશનો શોધી રહી છે.

નવું BPF 64-બીટ મશીનોની સર્વવ્યાપકતા, ક્લાઉડ સેવાઓ અને SDN (Sઑફવેર-dશુદ્ધ nકામ કરવું). ક્લાસિક BPF માટે સુધારેલ રિપ્લેસમેન્ટ તરીકે કર્નલ નેટવર્ક ઇજનેરો દ્વારા વિકસાવવામાં આવેલ, નવા BPFને શાબ્દિક રીતે છ મહિના પછી Linux સિસ્ટમ્સને ટ્રેસ કરવાના મુશ્કેલ કાર્યમાં એપ્લિકેશન મળી, અને હવે, તેના દેખાવના છ વર્ષ પછી, અમને આખા આગામી લેખની જરૂર પડશે. વિવિધ પ્રકારના કાર્યક્રમોની યાદી બનાવો.

રમુજી ચિત્રો

તેના મૂળમાં, BPF એ સેન્ડબોક્સ વર્ચ્યુઅલ મશીન છે જે તમને સુરક્ષા સાથે સમાધાન કર્યા વિના કર્નલ સ્પેસમાં "મનસ્વી" કોડ ચલાવવાની મંજૂરી આપે છે. BPF પ્રોગ્રામ્સ યુઝર સ્પેસમાં બનાવવામાં આવે છે, કર્નલમાં લોડ થાય છે અને અમુક ઇવેન્ટ સોર્સ સાથે જોડાયેલ હોય છે. ઘટના, ઉદાહરણ તરીકે, નેટવર્ક ઈન્ટરફેસમાં પેકેટની ડિલિવરી, કેટલાક કર્નલ ફંક્શનનું લોન્ચિંગ વગેરે હોઈ શકે છે. પેકેજના કિસ્સામાં, BPF પ્રોગ્રામને પેકેજના ડેટા અને મેટાડેટાની ઍક્સેસ હશે (વાંચવા માટે અને, સંભવતઃ, લખવા માટે, પ્રોગ્રામના પ્રકાર પર આધાર રાખીને); કર્નલ ફંક્શન ચલાવવાના કિસ્સામાં, દલીલો કર્નલ મેમરી વગેરેના નિર્દેશકો સહિત ફંક્શન.

ચાલો આ પ્રક્રિયા પર નજીકથી નજર કરીએ. શરૂ કરવા માટે, ચાલો ક્લાસિક BPF ના પ્રથમ તફાવત વિશે વાત કરીએ, પ્રોગ્રામ્સ જેના માટે એસેમ્બલરમાં લખવામાં આવ્યા હતા. નવા સંસ્કરણમાં, આર્કિટેક્ચરને વિસ્તૃત કરવામાં આવ્યું હતું જેથી પ્રોગ્રામ્સ ઉચ્ચ-સ્તરની ભાષાઓમાં લખી શકાય, મુખ્યત્વે, અલબત્ત, C માં. આ માટે, llvm માટે બેકએન્ડ વિકસાવવામાં આવ્યું હતું, જે તમને BPF આર્કિટેક્ચર માટે બાઇટકોડ જનરેટ કરવાની મંજૂરી આપે છે.

BPF આર્કિટેક્ચરને આંશિક રીતે, આધુનિક મશીનો પર કાર્યક્ષમ રીતે ચલાવવા માટે ડિઝાઇન કરવામાં આવ્યું હતું. આ કાર્યને વ્યવહારમાં કરવા માટે, BPF બાઈટકોડ, એકવાર કર્નલમાં લોડ થઈ જાય છે, જે JIT કમ્પાઈલર નામના ઘટકનો ઉપયોગ કરીને મૂળ કોડમાં અનુવાદિત થાય છેJust In Time). આગળ, જો તમને યાદ હોય, તો ક્લાસિક BPF માં પ્રોગ્રામ કર્નલમાં લોડ કરવામાં આવ્યો હતો અને ઇવેન્ટ સોર્સ સાથે અણુ રીતે જોડાયેલ હતો - સિંગલ સિસ્ટમ કૉલના સંદર્ભમાં. નવા આર્કિટેક્ચરમાં, આ બે તબક્કામાં થાય છે - પ્રથમ, સિસ્ટમ કૉલનો ઉપયોગ કરીને કોડ કર્નલમાં લોડ થાય છે. bpf(2)અને પછી, પછીથી, પ્રોગ્રામના પ્રકારને આધારે બદલાતી અન્ય પદ્ધતિઓ દ્વારા, પ્રોગ્રામ ઇવેન્ટના સ્ત્રોત સાથે જોડાય છે.

અહીં વાચકને એક પ્રશ્ન હોઈ શકે છે: શું તે શક્ય હતું? આવા કોડના અમલની સલામતીની ખાતરી કેવી રીતે આપવામાં આવે છે? વેરિફાયર તરીકે ઓળખાતા BPF પ્રોગ્રામ્સને લોડ કરવાના સ્ટેજ દ્વારા એક્ઝિક્યુશન સેફ્ટીની ખાતરી આપવામાં આવે છે (અંગ્રેજીમાં આ સ્ટેજને વેરિફાયર કહેવામાં આવે છે અને હું અંગ્રેજી શબ્દનો ઉપયોગ કરવાનું ચાલુ રાખીશ):

વેરિફાયર એ સ્ટેટિક વિશ્લેષક છે જે ખાતરી કરે છે કે પ્રોગ્રામ કર્નલની સામાન્ય કામગીરીમાં વિક્ષેપ પાડતો નથી. આનો અર્થ એ નથી કે પ્રોગ્રામ સિસ્ટમના ઑપરેશનમાં દખલ કરી શકતો નથી - BPF પ્રોગ્રામ્સ, પ્રકાર પર આધાર રાખીને, કર્નલ મેમરીના વિભાગો વાંચી અને ફરીથી લખી શકે છે, ફંક્શનના મૂલ્યો પરત કરી શકે છે, ટ્રિમ, એપેન્ડ, ફરીથી લખી શકે છે. અને નેટવર્ક પેકેટો પણ ફોરવર્ડ કરો. વેરિફાયર બાંહેધરી આપે છે કે BPF પ્રોગ્રામ ચલાવવાથી કર્નલ ક્રેશ થશે નહીં અને તે પ્રોગ્રામ કે જે નિયમો અનુસાર, લખવાની ઍક્સેસ ધરાવે છે, ઉદાહરણ તરીકે, આઉટગોઇંગ પેકેટનો ડેટા, પેકેટની બહાર કર્નલ મેમરીને ઓવરરાઇટ કરી શકશે નહીં. BPF ના અન્ય તમામ ઘટકોથી પરિચિત થયા પછી, અમે સંબંધિત વિભાગમાં થોડી વધુ વિગતમાં ચકાસણીકર્તાને જોઈશું.

તો આપણે અત્યાર સુધી શું શીખ્યા? વપરાશકર્તા C માં પ્રોગ્રામ લખે છે, તેને સિસ્ટમ કૉલનો ઉપયોગ કરીને કર્નલમાં લોડ કરે છે bpf(2), જ્યાં તે વેરિફાયર દ્વારા તપાસવામાં આવે છે અને મૂળ બાયટેકોડમાં અનુવાદિત થાય છે. પછી તે જ અથવા અન્ય વપરાશકર્તા પ્રોગ્રામને ઇવેન્ટ સ્રોત સાથે જોડે છે અને તે ચલાવવાનું શરૂ કરે છે. બૂટ અને કનેક્શનને અલગ પાડવું ઘણા કારણોસર જરૂરી છે. પ્રથમ, વેરિફાયર ચલાવવું પ્રમાણમાં ખર્ચાળ છે અને તે જ પ્રોગ્રામને ઘણી વખત ડાઉનલોડ કરીને આપણે કમ્પ્યુટરનો સમય બગાડીએ છીએ. બીજું, પ્રોગ્રામ કેવી રીતે કનેક્ટ થયેલ છે તે તેના પ્રકાર પર આધાર રાખે છે, અને એક વર્ષ પહેલાં વિકસિત એક "યુનિવર્સલ" ઇન્ટરફેસ નવા પ્રકારના પ્રોગ્રામ્સ માટે યોગ્ય ન હોઈ શકે. (જોકે હવે આર્કિટેક્ચર વધુ પરિપક્વ બની રહ્યું છે, આ ઇન્ટરફેસને સ્તરે એકીકૃત કરવાનો વિચાર છે. libbpf.)

સચેત વાચક કદાચ નોંધ લેશે કે અમે હજી ચિત્રો સાથે સમાપ્ત થયા નથી. ખરેખર, ઉપરોક્ત તમામ સમજાવતા નથી કે શા માટે BPF ક્લાસિક BPF ની સરખામણીમાં ચિત્રને મૂળભૂત રીતે બદલે છે. બે નવીનતાઓ કે જે નોંધપાત્ર રીતે લાગુ થવાના અવકાશને વિસ્તૃત કરે છે તે શેર્ડ મેમરી અને કર્નલ હેલ્પર ફંક્શનનો ઉપયોગ કરવાની ક્ષમતા છે. BPF માં, શેર્ડ મેમરીને કહેવાતા નકશાનો ઉપયોગ કરીને લાગુ કરવામાં આવે છે - ચોક્કસ API સાથે શેર કરેલ ડેટા સ્ટ્રક્ચર્સ. તેમને કદાચ આ નામ મળ્યું કારણ કે દેખાવાનો પ્રથમ પ્રકારનો નકશો હેશ ટેબલ હતો. પછી એરે દેખાયા, સ્થાનિક (સીપીયુ દીઠ) હેશ કોષ્ટકો અને સ્થાનિક એરે, સર્ચ ટ્રી, બીપીએફ પ્રોગ્રામના નિર્દેશક ધરાવતા નકશા અને ઘણું બધું. હવે અમારા માટે રસપ્રદ બાબત એ છે કે BPF પ્રોગ્રામ્સ હવે કૉલ્સ વચ્ચે સ્ટેટમેન્ટ ચાલુ રાખવાની અને તેને અન્ય પ્રોગ્રામ્સ અને યુઝર સ્પેસ સાથે શેર કરવાની ક્ષમતા ધરાવે છે.

સિસ્ટમ કૉલનો ઉપયોગ કરીને વપરાશકર્તા પ્રક્રિયાઓમાંથી નકશાને ઍક્સેસ કરવામાં આવે છે bpf(2), અને સહાયક કાર્યોનો ઉપયોગ કરીને કર્નલમાં ચાલતા BPF પ્રોગ્રામ્સમાંથી. વધુમાં, સહાયકો માત્ર નકશા સાથે કામ કરવા માટે જ નહીં, પણ અન્ય કર્નલ ક્ષમતાઓને ઍક્સેસ કરવા માટે પણ અસ્તિત્વ ધરાવે છે. ઉદાહરણ તરીકે, બીપીએફ પ્રોગ્રામ પેકેટોને અન્ય ઈન્ટરફેસ પર ફોરવર્ડ કરવા, પર્ફ ઈવેન્ટ્સ જનરેટ કરવા, કર્નલ સ્ટ્રક્ચર્સને એક્સેસ કરવા વગેરે માટે હેલ્પર ફંક્શનનો ઉપયોગ કરી શકે છે.

સારાંશમાં, BPF કર્નલ સ્પેસમાં આર્બિટરી, એટલે કે વેરિફાયર-ટેસ્ટેડ, વપરાશકર્તા કોડને લોડ કરવાની ક્ષમતા પ્રદાન કરે છે. આ કોડ કૉલ્સ વચ્ચેની સ્થિતિને બચાવી શકે છે અને વપરાશકર્તા સ્પેસ સાથે ડેટાનું વિનિમય કરી શકે છે, અને આ પ્રકારના પ્રોગ્રામ દ્વારા મંજૂર કરાયેલ કર્નલ સબસિસ્ટમ્સની ઍક્સેસ પણ ધરાવે છે.

આ પહેલેથી જ કર્નલ મોડ્યુલો દ્વારા પૂરી પાડવામાં આવેલ ક્ષમતાઓ જેવું જ છે, જેની તુલનામાં BPF ના કેટલાક ફાયદા છે (અલબત્ત, તમે ફક્ત સમાન એપ્લિકેશન્સની તુલના કરી શકો છો, ઉદાહરણ તરીકે, સિસ્ટમ ટ્રેસિંગ - તમે BPF સાથે મનસ્વી ડ્રાઇવર લખી શકતા નથી). તમે નીચી એન્ટ્રી થ્રેશોલ્ડ નોંધી શકો છો (કેટલીક ઉપયોગિતાઓ કે જે BPF નો ઉપયોગ કરે છે તેમાં વપરાશકર્તાને કર્નલ પ્રોગ્રામિંગ કૌશલ્ય અથવા સામાન્ય રીતે પ્રોગ્રામિંગ કૌશલ્ય હોવું જરૂરી નથી), રનટાઇમ સલામતી (જેઓ લખતી વખતે સિસ્ટમ તોડી નથી તેમના માટે ટિપ્પણીઓમાં તમારો હાથ ઊંચો કરો. અથવા મોડ્યુલોનું પરીક્ષણ કરો), એટોમીસીટી - મોડ્યુલોને ફરીથી લોડ કરતી વખતે ડાઉનટાઇમ હોય છે, અને BPF સબસિસ્ટમ ખાતરી કરે છે કે કોઈ ઇવેન્ટ ચૂકી ન જાય (ઉચિત કહું તો, આ તમામ પ્રકારના BPF પ્રોગ્રામ્સ માટે સાચું નથી).

આવી ક્ષમતાઓની હાજરી BPF ને કર્નલના વિસ્તરણ માટે એક સાર્વત્રિક સાધન બનાવે છે, જે વ્યવહારમાં પુષ્ટિ થયેલ છે: BPF માં વધુ અને વધુ નવા પ્રકારના પ્રોગ્રામ ઉમેરવામાં આવે છે, વધુ અને વધુ મોટી કંપનીઓ લડાયક સર્વર 24×7 પર BPF નો ઉપયોગ કરે છે. સ્ટાર્ટઅપ્સ બીપીએફ પર આધારિત એવા સોલ્યુશન્સ પર તેમનો વ્યવસાય બનાવે છે. BPF નો ઉપયોગ દરેક જગ્યાએ થાય છે: DDoS હુમલાઓ સામે રક્ષણ કરવા, SDN બનાવવા (ઉદાહરણ તરીકે, kubernetes માટે નેટવર્ક લાગુ કરવા), મુખ્ય સિસ્ટમ ટ્રેસિંગ ટૂલ અને આંકડા કલેક્ટર તરીકે, ઇન્ટ્રુઝન ડિટેક્શન સિસ્ટમ્સ અને સેન્ડબોક્સ સિસ્ટમ્સ વગેરેમાં.

ચાલો લેખના વિહંગાવલોકન ભાગને અહીં સમાપ્ત કરીએ અને વર્ચ્યુઅલ મશીન અને BPF ઇકોસિસ્ટમને વધુ વિગતવાર જોઈએ.

વિષયાંતર: ઉપયોગિતાઓ

નીચેના વિભાગોમાં ઉદાહરણો ચલાવવા માટે સક્ષમ થવા માટે, તમારે ઓછામાં ઓછી સંખ્યાબંધ ઉપયોગિતાઓની જરૂર પડી શકે છે. llvm/clang bpf આધાર સાથે અને bpftool. વિભાગમાં વિકાસ સાધનો તમે ઉપયોગિતાઓને એસેમ્બલ કરવા માટેની સૂચનાઓ તેમજ તમારી કર્નલ વાંચી શકો છો. અમારી પ્રસ્તુતિની સુમેળમાં ખલેલ ન પહોંચે તે માટે આ વિભાગ નીચે મૂકવામાં આવ્યો છે.

BPF વર્ચ્યુઅલ મશીન રજિસ્ટર અને સૂચના સિસ્ટમ

BPF ની આર્કિટેક્ચર અને કમાન્ડ સિસ્ટમ એ હકીકતને ધ્યાનમાં રાખીને વિકસાવવામાં આવી હતી કે પ્રોગ્રામ્સ C ભાષામાં લખવામાં આવશે અને, કર્નલમાં લોડ થયા પછી, મૂળ કોડમાં અનુવાદિત થશે. તેથી, ગાણિતિક અર્થમાં, આધુનિક મશીનોની ક્ષમતાઓના આંતરછેદ પર નજર રાખીને રજિસ્ટરની સંખ્યા અને આદેશોનો સમૂહ પસંદ કરવામાં આવ્યો હતો. વધુમાં, પ્રોગ્રામ્સ પર વિવિધ નિયંત્રણો લાદવામાં આવ્યા હતા, ઉદાહરણ તરીકે, તાજેતરમાં સુધી લૂપ્સ અને સબરૂટિન લખવાનું શક્ય ન હતું, અને સૂચનાઓની સંખ્યા 4096 સુધી મર્યાદિત હતી (હવે વિશેષાધિકૃત પ્રોગ્રામ્સ એક મિલિયન સૂચનાઓ લોડ કરી શકે છે).

BPF પાસે અગિયાર વપરાશકર્તા-સુલભ 64-બીટ રજિસ્ટર છે r0-r10 અને પ્રોગ્રામ કાઉન્ટર. નોંધણી કરો r10 ફ્રેમ પોઇન્ટર ધરાવે છે અને તે ફક્ત વાંચવા માટે છે. પ્રોગ્રામ્સ રનટાઇમ પર 512-બાઇટ સ્ટેક અને નકશાના રૂપમાં અમર્યાદિત માત્રામાં વહેંચાયેલ મેમરીની ઍક્સેસ ધરાવે છે.

BPF પ્રોગ્રામ્સને પ્રોગ્રામ-પ્રકારના કર્નલ હેલ્પરના ચોક્કસ સેટ અને તાજેતરમાં, નિયમિત કાર્યો ચલાવવાની મંજૂરી છે. દરેક કહેવાય ફંક્શન પાંચ જેટલી દલીલો લઈ શકે છે, રજિસ્ટરમાં પસાર થાય છે r1-r5, અને વળતર મૂલ્યને પસાર કરવામાં આવે છે r0. તે ખાતરી આપવામાં આવે છે કે કાર્યમાંથી પાછા ફર્યા પછી, રજિસ્ટરની સામગ્રીઓ r6-r9 બદલાશે નહીં.

કાર્યક્ષમ પ્રોગ્રામ અનુવાદ માટે, નોંધણીઓ r0-r11 વર્તમાન આર્કિટેક્ચરની ABI વિશેષતાઓને ધ્યાનમાં રાખીને, તમામ સપોર્ટેડ આર્કિટેક્ચર્સ વાસ્તવિક રજિસ્ટરમાં અનન્ય રીતે મેપ કરવામાં આવે છે. ઉદાહરણ તરીકે, માટે x86_64 રજીસ્ટર r1-r5, ફંક્શન પરિમાણો પસાર કરવા માટે વપરાય છે, પર પ્રદર્શિત થાય છે rdi, rsi, rdx, rcx, r8, જેનો ઉપયોગ ફંક્શનમાં પરિમાણો પસાર કરવા માટે થાય છે x86_64. ઉદાહરણ તરીકે, ડાબી બાજુનો કોડ જમણી બાજુના કોડમાં આ રીતે અનુવાદ કરે છે:

1:  (b7) r1 = 1                    mov    $0x1,%rdi
2:  (b7) r2 = 2                    mov    $0x2,%rsi
3:  (b7) r3 = 3                    mov    $0x3,%rdx
4:  (b7) r4 = 4                    mov    $0x4,%rcx
5:  (b7) r5 = 5                    mov    $0x5,%r8
6:  (85) call pc+1                 callq  0x0000000000001ee8

નોંધણી કરો r0 પ્રોગ્રામ એક્ઝેક્યુશનનું પરિણામ પરત કરવા માટે અને રજિસ્ટરમાં પણ વપરાય છે r1 પ્રોગ્રામને સંદર્ભમાં નિર્દેશક પસાર કરવામાં આવે છે - પ્રોગ્રામના પ્રકાર પર આધાર રાખીને, આ, ઉદાહરણ તરીકે, એક માળખું હોઈ શકે છે struct xdp_md (XDP માટે) અથવા માળખું struct __sk_buff (વિવિધ નેટવર્ક પ્રોગ્રામ્સ માટે) અથવા માળખું struct pt_regs (વિવિધ પ્રકારના ટ્રેસીંગ પ્રોગ્રામ માટે), વગેરે.

તેથી, અમારી પાસે નકશાના રૂપમાં રજિસ્ટર, કર્નલ હેલ્પર્સ, સ્ટેક, એક સંદર્ભ નિર્દેશક અને શેર કરેલી મેમરીનો સમૂહ હતો. એવું નથી કે સફરમાં આ બધું એકદમ જરૂરી છે, પણ...

ચાલો વર્ણન ચાલુ રાખીએ અને આ ઑબ્જેક્ટ્સ સાથે કામ કરવા માટે કમાન્ડ સિસ્ટમ વિશે વાત કરીએ. બધા (લગભગ બધા) BPF સૂચનાઓમાં નિશ્ચિત 64-બીટ કદ હોય છે. જો તમે 64-બીટ બિગ એન્ડિયન મશીન પરની એક સૂચના જોશો તો તમે જોશો

તે Code - આ સૂચનાનું એન્કોડિંગ છે, Dst/Src અનુક્રમે રીસીવર અને સ્ત્રોતના એન્કોડિંગ્સ છે, Off - 16-બીટ સહી કરેલ ઇન્ડેન્ટેશન, અને Imm અમુક સૂચનાઓમાં વપરાયેલ 32-બીટ હસ્તાક્ષરિત પૂર્ણાંક છે (cBPF સ્થિર K ની જેમ). એન્કોડિંગ Code બેમાંથી એક પ્રકાર છે:

સૂચના વર્ગો 0, 1, 2, 3 મેમરી સાથે કામ કરવા માટે આદેશો વ્યાખ્યાયિત કરે છે. તેઓ ને બોલાવ્યા હતા, BPF_LD, BPF_LDX, BPF_ST, BPF_STX, અનુક્રમે. વર્ગ 4, 7 (BPF_ALU, BPF_ALU64) ALU સૂચનાઓનો સમૂહ બનાવે છે. વર્ગ 5, 6 (BPF_JMP, BPF_JMP32) જમ્પ સૂચનાઓ ધરાવે છે.

BPF સૂચના પ્રણાલીનો અભ્યાસ કરવા માટેની આગળની યોજના નીચે મુજબ છે: બધી સૂચનાઓ અને તેના પરિમાણોને કાળજીપૂર્વક સૂચિબદ્ધ કરવાને બદલે, અમે આ વિભાગમાં કેટલાક ઉદાહરણો જોઈશું અને તેમાંથી તે સ્પષ્ટ થઈ જશે કે સૂચનાઓ ખરેખર કેવી રીતે કાર્ય કરે છે અને કેવી રીતે BPF માટે કોઈપણ બાઈનરી ફાઇલને મેન્યુઅલી ડિસએસેમ્બલ કરો. લેખમાં પછીથી સામગ્રીને એકીકૃત કરવા માટે, અમે વેરિફાયર, JIT કમ્પાઇલર, ક્લાસિક BPF ના અનુવાદ, તેમજ નકશા, કૉલિંગ ફંક્શન વગેરેનો અભ્યાસ કરતી વખતે વિભાગોમાં વ્યક્તિગત સૂચનાઓ સાથે પણ મળીશું.

જ્યારે આપણે વ્યક્તિગત સૂચનાઓ વિશે વાત કરીએ છીએ, ત્યારે અમે મુખ્ય ફાઇલોનો સંદર્ભ લઈશું bpf.h и bpf_common.h, જે BPF સૂચનાઓના સંખ્યાત્મક કોડને વ્યાખ્યાયિત કરે છે. જ્યારે તમે તમારી જાતે આર્કિટેક્ચરનો અભ્યાસ કરો છો અને/અથવા દ્વિસંગીનું પદચ્છેદન કરો છો, ત્યારે તમે જટિલતાના ક્રમમાં સૉર્ટ કરેલા નીચેના સ્ત્રોતોમાં સિમેન્ટિક્સ શોધી શકો છો: બિનસત્તાવાર eBPF સ્પેક, BPF અને XDP સંદર્ભ માર્ગદર્શિકા, સૂચના સેટ, દસ્તાવેજીકરણ/networking/filter.txt અને, અલબત્ત, Linux સોર્સ કોડમાં - વેરિફાયર, JIT, BPF દુભાષિયા.

ઉદાહરણ: તમારા માથામાં BPF ને ડિસએસેમ્બલ કરવું

ચાલો એક ઉદાહરણ જોઈએ જેમાં આપણે પ્રોગ્રામ કમ્પાઈલ કરીએ છીએ readelf-example.c અને પરિણામી બાઈનરી જુઓ. અમે મૂળ સામગ્રી જાહેર કરીશું readelf-example.c નીચે, અમે બાઈનરી કોડ્સમાંથી તેના તર્કને પુનઃસ્થાપિત કર્યા પછી:

$ clang -target bpf -c readelf-example.c -o readelf-example.o -O2
$ llvm-readelf -x .text readelf-example.o
Hex dump of section '.text':
0x00000000 b7000000 01000000 15010100 00000000 ................
0x00000010 b7000000 02000000 95000000 00000000 ................

આઉટપુટમાં પ્રથમ કૉલમ readelf ઇન્ડેન્ટેશન છે અને અમારો પ્રોગ્રામ આમ ચાર આદેશોનો સમાવેશ કરે છે:

Code Dst Src Off  Imm
b7   0   0   0000 01000000
15   0   1   0100 00000000
b7   0   0   0000 02000000
95   0   0   0000 00000000

આદેશ કોડ સમાન છે b7, 15, b7 и 95. યાદ કરો કે ઓછામાં ઓછા નોંધપાત્ર ત્રણ બિટ્સ સૂચના વર્ગ છે. અમારા કિસ્સામાં, બધી સૂચનાઓનો ચોથો ભાગ ખાલી છે, તેથી સૂચના વર્ગો અનુક્રમે 7, 5, 7, 5 છે. વર્ગ 7 છે BPF_ALU64, અને 5 છે BPF_JMP. બંને વર્ગો માટે, સૂચના ફોર્મેટ સમાન છે (ઉપર જુઓ) અને અમે અમારા પ્રોગ્રામને આ રીતે ફરીથી લખી શકીએ છીએ (તે જ સમયે અમે બાકીની કૉલમને માનવ સ્વરૂપમાં ફરીથી લખીશું):

Op S  Class   Dst Src Off  Imm
b  0  ALU64   0   0   0    1
1  0  JMP     0   1   1    0
b  0  ALU64   0   0   0    2
9  0  JMP     0   0   0    0

ઓપરેશન b વર્ગ ALU64 છે BPF_MOV. તે ગંતવ્ય રજિસ્ટરને મૂલ્ય અસાઇન કરે છે. જો બીટ સેટ છે s (સ્રોત), પછી મૂલ્ય સ્રોત રજિસ્ટરમાંથી લેવામાં આવે છે, અને જો, અમારા કિસ્સામાં, તે સેટ નથી, તો મૂલ્ય ફીલ્ડમાંથી લેવામાં આવે છે Imm. તેથી પ્રથમ અને ત્રીજી સૂચનાઓમાં અમે ઓપરેશન કરીએ છીએ r0 = Imm. આગળ, JMP વર્ગ 1 ઓપરેશન છે BPF_JEQ (જો સમાન હોય તો કૂદકો). અમારા કિસ્સામાં, બીટ થી S શૂન્ય છે, તે ક્ષેત્ર સાથે સ્ત્રોત રજીસ્ટરના મૂલ્યની તુલના કરે છે Imm. જો મૂલ્યો એકરૂપ થાય છે, તો પછી સંક્રમણ થાય છે PC + Offજ્યાં PC, હંમેશની જેમ, આગળની સૂચનાનું સરનામું સમાવે છે. છેલ્લે, JMP વર્ગ 9 ઓપરેશન છે BPF_EXIT. આ સૂચના કર્નલ પર પાછા ફરતા પ્રોગ્રામને સમાપ્ત કરે છે r0. ચાલો આપણા કોષ્ટકમાં એક નવી કૉલમ ઉમેરીએ:

Op    S  Class   Dst Src Off  Imm    Disassm
MOV   0  ALU64   0   0   0    1      r0 = 1
JEQ   0  JMP     0   1   1    0      if (r1 == 0) goto pc+1
MOV   0  ALU64   0   0   0    2      r0 = 2
EXIT  0  JMP     0   0   0    0      exit

અમે આને વધુ અનુકૂળ સ્વરૂપમાં ફરીથી લખી શકીએ છીએ:

     r0 = 1
     if (r1 == 0) goto END
     r0 = 2
END:
     exit

જો આપણે યાદ રાખીએ કે રજિસ્ટરમાં શું છે r1 પ્રોગ્રામને કર્નલ અને રજિસ્ટરમાં સંદર્ભ માટે નિર્દેશક પસાર કરવામાં આવે છે r0 મૂલ્ય કર્નલ પર પાછું આવે છે, પછી આપણે જોઈ શકીએ છીએ કે જો સંદર્ભમાં નિર્દેશક શૂન્ય છે, તો આપણે 1 પરત કરીએ છીએ, અને અન્યથા - 2. ચાલો સ્ત્રોતને જોઈને તપાસ કરીએ કે આપણે સાચા છીએ:

$ cat readelf-example.c
int foo(void *ctx)
{
        return ctx ? 2 : 1;
}

હા, તે એક અર્થહીન પ્રોગ્રામ છે, પરંતુ તે માત્ર ચાર સરળ સૂચનાઓમાં અનુવાદ કરે છે.

અપવાદ ઉદાહરણ: 16-બાઈટ સૂચના

અમે અગાઉ ઉલ્લેખ કર્યો છે કે કેટલીક સૂચનાઓ 64 બિટ્સ કરતાં વધુ લે છે. આ, ઉદાહરણ તરીકે, સૂચનાઓને લાગુ પડે છે lddw (કોડ = 0x18 = BPF_LD | BPF_DW | BPF_IMM) — ક્ષેત્રોમાંથી રજિસ્ટરમાં ડબલ શબ્દ લોડ કરો Imm... હકીકત એ છે કે Imm તેનું કદ 32 છે, અને ડબલ શબ્દ 64 બિટ્સ છે, તેથી એક 64-બીટ સૂચનામાં રજિસ્ટરમાં 64-બીટ તાત્કાલિક મૂલ્ય લોડ કરવું કામ કરશે નહીં. આ કરવા માટે, બે સંલગ્ન સૂચનાઓનો ઉપયોગ ક્ષેત્રમાં 64-બીટ મૂલ્યના બીજા ભાગને સંગ્રહિત કરવા માટે થાય છે Imm. ઉદાહરણ:

$ cat x64.c
long foo(void *ctx)
{
        return 0x11223344aabbccdd;
}
$ clang -target bpf -c x64.c -o x64.o -O2
$ llvm-readelf -x .text x64.o
Hex dump of section '.text':
0x00000000 18000000 ddccbbaa 00000000 44332211 ............D3".
0x00000010 95000000 00000000                   ........

બાઈનરી પ્રોગ્રામમાં માત્ર બે સૂચનાઓ છે:

Binary                                 Disassm
18000000 ddccbbaa 00000000 44332211    r0 = Imm[0]|Imm[1]
95000000 00000000                      exit

અમે સૂચનાઓ સાથે ફરી મળીશું lddw, જ્યારે આપણે સ્થાનાંતરણ અને નકશા સાથે કામ કરવા વિશે વાત કરીએ છીએ.

ઉદાહરણ: પ્રમાણભૂત સાધનોનો ઉપયોગ કરીને BPF ને ડિસએસેમ્બલ કરવું

તેથી, અમે BPF બાઈનરી કોડ્સ વાંચવાનું શીખ્યા છીએ અને જો જરૂરી હોય તો કોઈપણ સૂચનાનું વિશ્લેષણ કરવા માટે તૈયાર છીએ. જો કે, તે કહેવું યોગ્ય છે કે વ્યવહારમાં પ્રમાણભૂત સાધનોનો ઉપયોગ કરીને પ્રોગ્રામ્સને ડિસએસેમ્બલ કરવું વધુ અનુકૂળ અને ઝડપી છે, ઉદાહરણ તરીકે:

$ llvm-objdump -d x64.o

Disassembly of section .text:

0000000000000000 <foo>:
 0: 18 00 00 00 dd cc bb aa 00 00 00 00 44 33 22 11 r0 = 1234605617868164317 ll
 2: 95 00 00 00 00 00 00 00 exit

BPF ઑબ્જેક્ટ્સનું જીવનચક્ર, bpffs ફાઇલ સિસ્ટમ

(આ પેટાવિભાગમાં વર્ણવેલ કેટલીક વિગતો મેં સૌપ્રથમ શીખી પોસ્ટ એલેક્સી સ્ટારોવોઇટોવ માં BPF બ્લોગ.)

BPF ઑબ્જેક્ટ્સ - પ્રોગ્રામ્સ અને નકશા - આદેશોનો ઉપયોગ કરીને વપરાશકર્તા જગ્યામાંથી બનાવવામાં આવે છે BPF_PROG_LOAD и BPF_MAP_CREATE સિસ્ટમ કૉલ bpf(2), અમે આગળના વિભાગમાં આ કેવી રીતે થાય છે તે વિશે વાત કરીશું. આ કર્નલ ડેટા સ્ટ્રક્ચર્સ બનાવે છે અને તે દરેક માટે refcount (સંદર્ભ ગણતરી) એક પર સેટ છે, અને ઑબ્જેક્ટ તરફ નિર્દેશ કરતી ફાઇલ વર્ણનકર્તા વપરાશકર્તાને પરત કરવામાં આવે છે. હેન્ડલ બંધ થયા પછી refcount ઑબ્જેક્ટ એક દ્વારા ઘટાડવામાં આવે છે, અને જ્યારે તે શૂન્ય સુધી પહોંચે છે, ત્યારે ઑબ્જેક્ટ નાશ પામે છે.

જો પ્રોગ્રામ નકશાનો ઉપયોગ કરે છે, તો પછી refcount પ્રોગ્રામ લોડ કર્યા પછી આ નકશામાં એકથી એક વધારો થાય છે, એટલે કે. તેમના ફાઇલ વર્ણનકર્તાઓને વપરાશકર્તા પ્રક્રિયામાંથી અને હજુ પણ બંધ કરી શકાય છે refcount શૂન્ય બનશે નહીં:

પ્રોગ્રામ સફળતાપૂર્વક લોડ કર્યા પછી, અમે સામાન્ય રીતે તેને અમુક પ્રકારના ઇવેન્ટ જનરેટર સાથે જોડીએ છીએ. ઉદાહરણ તરીકે, અમે ઇનકમિંગ પેકેટો પર પ્રક્રિયા કરવા અથવા તેને કેટલાક સાથે કનેક્ટ કરવા માટે તેને નેટવર્ક ઇન્ટરફેસ પર મૂકી શકીએ છીએ tracepoint કોર માં. આ બિંદુએ, સંદર્ભ કાઉન્ટર પણ એકથી વધશે અને અમે લોડર પ્રોગ્રામમાં ફાઇલ વર્ણનકર્તાને બંધ કરી શકીશું.

જો આપણે હવે બુટલોડર બંધ કરીએ તો શું થશે? તે ઇવેન્ટ જનરેટર (હૂક) ના પ્રકાર પર આધારિત છે. લોડર પૂર્ણ થયા પછી બધા નેટવર્ક હુક્સ અસ્તિત્વમાં રહેશે, આ કહેવાતા વૈશ્વિક હુક્સ છે. અને, ઉદાહરણ તરીકે, ટ્રેસ પ્રોગ્રામ્સ જે પ્રક્રિયા તેમને બનાવેલ છે તે સમાપ્ત થયા પછી રિલીઝ કરવામાં આવશે (અને તેથી તેને "સ્થાનિક થી પ્રક્રિયા" સુધી સ્થાનિક કહેવામાં આવે છે). ટેક્નિકલ રીતે, સ્થાનિક હુક્સમાં હંમેશા યુઝર સ્પેસમાં અનુરૂપ ફાઇલ ડિસ્ક્રિપ્ટર હોય છે અને તેથી જ્યારે પ્રક્રિયા બંધ હોય ત્યારે બંધ થાય છે, પરંતુ વૈશ્વિક હુક્સ એવું નથી કરતા. નીચેની આકૃતિમાં, રેડ ક્રોસનો ઉપયોગ કરીને, હું બતાવવાનો પ્રયાસ કરું છું કે લોડર પ્રોગ્રામની સમાપ્તિ સ્થાનિક અને વૈશ્વિક હુક્સના કિસ્સામાં ઑબ્જેક્ટના જીવનકાળને કેવી રીતે અસર કરે છે.

સ્થાનિક અને વૈશ્વિક હૂક વચ્ચે શા માટે તફાવત છે? અમુક પ્રકારના નેટવર્ક પ્રોગ્રામ્સ ચલાવવું એ યુઝરસ્પેસ વિના અર્થપૂર્ણ છે, ઉદાહરણ તરીકે, DDoS સુરક્ષાની કલ્પના કરો - બુટલોડર નિયમો લખે છે અને BPF પ્રોગ્રામને નેટવર્ક ઇન્ટરફેસ સાથે જોડે છે, જે પછી બુટલોડર જઈને પોતાની જાતને મારી શકે છે. બીજી તરફ, તમે દસ મિનિટમાં તમારા ઘૂંટણ પર લખેલા ડિબગીંગ ટ્રેસ પ્રોગ્રામની કલ્પના કરો - જ્યારે તે પૂર્ણ થઈ જાય, ત્યારે તમે ઈચ્છો છો કે સિસ્ટમમાં કોઈ કચરો બાકી ન રહે અને સ્થાનિક હુક્સ તેની ખાતરી કરશે.

બીજી બાજુ, કલ્પના કરો કે તમે કર્નલમાં ટ્રેસપોઇન્ટ સાથે જોડાવા માંગો છો અને ઘણા વર્ષોથી આંકડા એકત્રિત કરવા માંગો છો. આ કિસ્સામાં, તમે વપરાશકર્તાના ભાગને પૂર્ણ કરવા અને સમયાંતરે આંકડા પર પાછા ફરવા માંગો છો. bpf ફાઇલ સિસ્ટમ આ તક પૂરી પાડે છે. તે એક ઇન-મેમરી-ઓન્લી સ્યુડો-ફાઇલ સિસ્ટમ છે જે BPF ઑબ્જેક્ટ્સનો સંદર્ભ આપતી ફાઇલો બનાવવાની મંજૂરી આપે છે અને તેના કારણે વધારો થાય છે. refcount વસ્તુઓ આ પછી, લોડર બહાર નીકળી શકે છે, અને તેણે બનાવેલી વસ્તુઓ જીવંત રહેશે.

BPF ઑબ્જેક્ટ્સનો સંદર્ભ આપતા bpffs માં ફાઇલો બનાવવાને "પિનિંગ" કહેવામાં આવે છે (જેમ કે નીચેના શબ્દસમૂહમાં: "પ્રક્રિયા BPF પ્રોગ્રામ અથવા નકશાને પિન કરી શકે છે"). BPF ઑબ્જેક્ટ્સ માટે ફાઇલ ઑબ્જેક્ટ્સ બનાવવું એ માત્ર સ્થાનિક ઑબ્જેક્ટ્સના જીવનને વધારવા માટે જ નહીં, પણ વૈશ્વિક ઑબ્જેક્ટ્સની ઉપયોગિતા માટે પણ અર્થપૂર્ણ છે - વૈશ્વિક DDoS પ્રોટેક્શન પ્રોગ્રામ સાથેના ઉદાહરણ પર પાછા જઈએ, અમે આંકડાઓ જોવા માટે સક્ષમ બનવા માંગીએ છીએ. સમય સમય પર.

BPF ફાઇલ સિસ્ટમ સામાન્ય રીતે માઉન્ટ થયેલ છે /sys/fs/bpf, પરંતુ તે સ્થાનિક રીતે પણ માઉન્ટ કરી શકાય છે, ઉદાહરણ તરીકે, આની જેમ:

$ mkdir bpf-mountpoint
$ sudo mount -t bpf none bpf-mountpoint

આદેશનો ઉપયોગ કરીને ફાઇલ સિસ્ટમ નામો બનાવવામાં આવે છે BPF_OBJ_PIN BPF સિસ્ટમ કૉલ. સમજાવવા માટે, ચાલો એક પ્રોગ્રામ લઈએ, તેને કમ્પાઈલ કરીએ, તેને અપલોડ કરીએ અને તેને પિન કરીએ bpffs. અમારો પ્રોગ્રામ કંઈપણ ઉપયોગી કરતું નથી, અમે માત્ર કોડ રજૂ કરી રહ્યાં છીએ જેથી કરીને તમે ઉદાહરણનું પુનઃઉત્પાદન કરી શકો:

$ cat test.c
__attribute__((section("xdp"), used))
int test(void *ctx)
{
        return 0;
}

char _license[] __attribute__((section("license"), used)) = "GPL";

ચાલો આ પ્રોગ્રામ કમ્પાઈલ કરીએ અને ફાઈલ સિસ્ટમની સ્થાનિક નકલ બનાવીએ bpffs:

$ clang -target bpf -c test.c -o test.o
$ mkdir bpf-mountpoint
$ sudo mount -t bpf none bpf-mountpoint

હવે યુટિલિટીનો ઉપયોગ કરીને અમારો પ્રોગ્રામ ડાઉનલોડ કરીએ bpftool અને સાથેના સિસ્ટમ કૉલ્સ જુઓ bpf(2) (સ્ટ્રેસ આઉટપુટમાંથી કેટલીક અપ્રસ્તુત રેખાઓ દૂર કરવામાં આવી છે):

$ sudo strace -e bpf bpftool prog load ./test.o bpf-mountpoint/test
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, prog_name="test", ...}, 120) = 3
bpf(BPF_OBJ_PIN, {pathname="bpf-mountpoint/test", bpf_fd=3}, 120) = 0

અહીં આપણે પ્રોગ્રામનો ઉપયોગ કરીને લોડ કર્યો છે BPF_PROG_LOAD, કર્નલમાંથી ફાઇલ વર્ણનકર્તા પ્રાપ્ત થયું 3 અને આદેશનો ઉપયોગ કરીને BPF_OBJ_PIN આ ફાઇલ વર્ણનકર્તાને ફાઇલ તરીકે પિન કર્યું "bpf-mountpoint/test". આ પછી બુટલોડર પ્રોગ્રામ bpftool કામ પૂર્ણ કર્યું, પરંતુ અમારો પ્રોગ્રામ કર્નલમાં જ રહ્યો, જો કે અમે તેને કોઈપણ નેટવર્ક ઈન્ટરફેસ સાથે જોડ્યો નથી:

$ sudo bpftool prog | tail -3
783: xdp  name test  tag 5c8ba0cf164cb46c  gpl
        loaded_at 2020-05-05T13:27:08+0000  uid 0
        xlated 24B  jited 41B  memlock 4096B

અમે ફાઇલ ઑબ્જેક્ટને સામાન્ય રીતે કાઢી શકીએ છીએ unlink(2) અને તે પછી અનુરૂપ પ્રોગ્રામ કાઢી નાખવામાં આવશે:

$ sudo rm ./bpf-mountpoint/test
$ sudo bpftool prog show id 783
Error: get by id (783): No such file or directory

વસ્તુઓ કાઢી રહ્યા છીએ

ઑબ્જેક્ટ્સ કાઢી નાખવા વિશે બોલતા, તે સ્પષ્ટ કરવું જરૂરી છે કે અમે પ્રોગ્રામને હૂક (ઇવેન્ટ જનરેટર) થી ડિસ્કનેક્ટ કર્યા પછી, એક પણ નવી ઇવેન્ટ તેના લોન્ચને ટ્રિગર કરશે નહીં, જો કે, પ્રોગ્રામના તમામ વર્તમાન ઉદાહરણો સામાન્ય ક્રમમાં પૂર્ણ થશે. .

કેટલાક પ્રકારના BPF પ્રોગ્રામ્સ તમને ફ્લાય પર પ્રોગ્રામને બદલવાની મંજૂરી આપે છે, એટલે કે. ક્રમ પરમાણુ પ્રદાન કરો replace = detach old program, attach new program. આ કિસ્સામાં, પ્રોગ્રામના જૂના સંસ્કરણના તમામ સક્રિય ઉદાહરણો તેમનું કાર્ય પૂર્ણ કરશે, અને નવા પ્રોગ્રામમાંથી નવા ઇવેન્ટ હેન્ડલર્સ બનાવવામાં આવશે, અને અહીં "એટૉમિસિટી" નો અર્થ એ છે કે એક પણ ઇવેન્ટ ચૂકી જશે નહીં.

ઇવેન્ટ સ્ત્રોતો સાથે કાર્યક્રમો જોડવું

આ લેખમાં, અમે પ્રોગ્રામને ઇવેન્ટ સ્ત્રોતો સાથે કનેક્ટ કરવાનું અલગથી વર્ણન કરીશું નહીં, કારણ કે ચોક્કસ પ્રકારના પ્રોગ્રામના સંદર્ભમાં આનો અભ્યાસ કરવો અર્થપૂર્ણ છે. સેમી. ઉદાહરણ નીચે, જેમાં અમે XDP જેવા પ્રોગ્રામ્સ કેવી રીતે જોડાયેલા છે તે બતાવીએ છીએ.

bpf સિસ્ટમ કૉલનો ઉપયોગ કરીને ઑબ્જેક્ટ્સની હેરફેર કરવી

BPF કાર્યક્રમો

બધા BPF ઑબ્જેક્ટ્સ સિસ્ટમ કૉલનો ઉપયોગ કરીને વપરાશકર્તા જગ્યામાંથી બનાવવામાં અને સંચાલિત થાય છે bpf, નીચેના પ્રોટોટાઇપ ધરાવે છે:

#include <linux/bpf.h>

int bpf(int cmd, union bpf_attr *attr, unsigned int size);

આ રહી ટીમ cmd પ્રકારના મૂલ્યોમાંનું એક છે enum bpf_cmd, attr — ચોક્કસ પ્રોગ્રામ માટે પરિમાણો માટે નિર્દેશક અને size - પોઇન્ટર અનુસાર ઑબ્જેક્ટનું કદ, એટલે કે સામાન્ય રીતે આ sizeof(*attr). કર્નલ 5.8 માં સિસ્ટમ કોલ bpf 34 વિવિધ આદેશોને સપોર્ટ કરે છે, અને વ્યાખ્યા union bpf_attr 200 રેખાઓ રોકે છે. પરંતુ આપણે આનાથી ડરવું જોઈએ નહીં, કારણ કે આપણે ઘણા લેખો દરમિયાન આદેશો અને પરિમાણોથી પોતાને પરિચિત કરીશું.

ચાલો ટીમ સાથે શરૂઆત કરીએ BPF_PROG_LOAD, જે BPF પ્રોગ્રામ બનાવે છે - BPF સૂચનાઓનો સમૂહ લે છે અને તેને કર્નલમાં લોડ કરે છે. લોડિંગની ક્ષણે, વેરિફાયર લોંચ કરવામાં આવે છે, અને પછી JIT કમ્પાઇલર અને, સફળ અમલીકરણ પછી, પ્રોગ્રામ ફાઇલ વર્ણનકર્તા વપરાશકર્તાને પરત કરવામાં આવે છે. અમે અગાઉના વિભાગમાં તેની સાથે આગળ શું થાય છે તે જોયું BPF વસ્તુઓના જીવન ચક્ર વિશે.

હવે આપણે એક કસ્ટમ પ્રોગ્રામ લખીશું જે એક સાદો BPF પ્રોગ્રામ લોડ કરશે, પરંતુ પહેલા આપણે નક્કી કરવું પડશે કે આપણે કયા પ્રકારનો પ્રોગ્રામ લોડ કરવા માંગીએ છીએ - આપણે પસંદ કરવું પડશે. પ્રકાર અને આ પ્રકારના માળખામાં, એક પ્રોગ્રામ લખો જે વેરિફાયર ટેસ્ટ પાસ કરશે. જો કે, પ્રક્રિયાને જટિલ ન બનાવવા માટે, અહીં એક તૈયાર ઉકેલ છે: અમે એક પ્રોગ્રામ લઈશું BPF_PROG_TYPE_XDP, જે મૂલ્ય પરત કરશે XDP_PASS (બધા પેકેજો છોડો). BPF એસેમ્બલરમાં તે ખૂબ જ સરળ લાગે છે:

r0 = 2
exit

અમે નક્કી કર્યા પછી કે અમે અપલોડ કરીશું, અમે તમને કહી શકીએ કે અમે તે કેવી રીતે કરીશું:

#define _GNU_SOURCE
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/bpf.h>

static inline __u64 ptr_to_u64(const void *ptr)
{
        return (__u64) (unsigned long) ptr;
}

int main(void)
{
    struct bpf_insn insns[] = {
        {
            .code = BPF_ALU64 | BPF_MOV | BPF_K,
            .dst_reg = BPF_REG_0,
            .imm = XDP_PASS
        },
        {
            .code = BPF_JMP | BPF_EXIT
        },
    };

    union bpf_attr attr = {
        .prog_type = BPF_PROG_TYPE_XDP,
        .insns     = ptr_to_u64(insns),
        .insn_cnt  = sizeof(insns)/sizeof(insns[0]),
        .license   = ptr_to_u64("GPL"),
    };

    strncpy(attr.prog_name, "woo", sizeof(attr.prog_name));
    syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));

    for ( ;; )
        pause();
}

પ્રોગ્રામમાં રસપ્રદ ઘટનાઓ એરેની વ્યાખ્યા સાથે શરૂ થાય છે insns - મશીન કોડમાં અમારો BPF પ્રોગ્રામ. આ કિસ્સામાં, BPF પ્રોગ્રામની દરેક સૂચના માળખામાં પેક કરવામાં આવે છે bpf_insn. પ્રથમ તત્વ insns સૂચનાઓનું પાલન કરે છે r0 = 2, બીજી - exit.

પીછેહઠ. કર્નલ મશીન કોડ લખવા અને કર્નલ હેડર ફાઇલનો ઉપયોગ કરવા માટે વધુ અનુકૂળ મેક્રોને વ્યાખ્યાયિત કરે છે tools/include/linux/filter.h અમે લખી શક્યા

struct bpf_insn insns[] = {
    BPF_MOV64_IMM(BPF_REG_0, XDP_PASS),
    BPF_EXIT_INSN()
};

પરંતુ મૂળ કોડમાં BPF પ્રોગ્રામ્સ લખવા એ કર્નલમાં પરીક્ષણો અને BPF વિશેના લેખો લખવા માટે જ જરૂરી હોવાથી, આ મેક્રોની ગેરહાજરી ખરેખર વિકાસકર્તાના જીવનને જટિલ બનાવતી નથી.

BPF પ્રોગ્રામને વ્યાખ્યાયિત કર્યા પછી, અમે તેને કર્નલમાં લોડ કરવા માટે આગળ વધીએ છીએ. અમારા પરિમાણોનો ન્યૂનતમ સમૂહ attr પ્રોગ્રામનો પ્રકાર, સેટ અને સૂચનાઓની સંખ્યા, જરૂરી લાઇસન્સ અને નામનો સમાવેશ થાય છે "woo", જેનો ઉપયોગ અમે ડાઉનલોડ કર્યા પછી સિસ્ટમ પર અમારા પ્રોગ્રામને શોધવા માટે કરીએ છીએ. પ્રોગ્રામ, વચન મુજબ, સિસ્ટમ કૉલનો ઉપયોગ કરીને સિસ્ટમમાં લોડ થાય છે bpf.

પ્રોગ્રામના અંતે આપણે અનંત લૂપમાં આવીએ છીએ જે પેલોડનું અનુકરણ કરે છે. તેના વિના, જ્યારે સિસ્ટમ કૉલ અમને પરત કરે છે તે ફાઇલ વર્ણનકર્તા બંધ હોય ત્યારે કર્નલ દ્વારા પ્રોગ્રામને મારી નાખવામાં આવશે. bpf, અને અમે તેને સિસ્ટમમાં જોઈશું નહીં.

સારું, અમે પરીક્ષણ માટે તૈયાર છીએ. ચાલો એસેમ્બલ કરીએ અને પ્રોગ્રામ હેઠળ ચલાવીએ straceતપાસવા માટે કે બધું જોઈએ તે પ્રમાણે કાર્ય કરી રહ્યું છે:

$ clang -g -O2 simple-prog.c -o simple-prog

$ sudo strace ./simple-prog
execve("./simple-prog", ["./simple-prog"], 0x7ffc7b553480 /* 13 vars */) = 0
...
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=2, insns=0x7ffe03c4ed50, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_V
ERSION(0, 0, 0), prog_flags=0, prog_name="woo", prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = 3
pause(

બધું બરાબર છે, bpf(2) અમને હેન્ડલ 3 પરત કર્યું અને અમે તેની સાથે અનંત લૂપમાં ગયા pause(). ચાલો આપણા પ્રોગ્રામને સિસ્ટમમાં શોધવાનો પ્રયાસ કરીએ. આ કરવા માટે આપણે બીજા ટર્મિનલ પર જઈશું અને ઉપયોગિતાનો ઉપયોગ કરીશું bpftool:

# bpftool prog | grep -A3 woo
390: xdp  name woo  tag 3b185187f1855c4c  gpl
        loaded_at 2020-08-31T24:66:44+0000  uid 0
        xlated 16B  jited 40B  memlock 4096B
        pids simple-prog(10381)

આપણે જોઈએ છીએ કે સિસ્ટમ પર લોડ થયેલ પ્રોગ્રામ છે woo જેની વૈશ્વિક ID 390 છે અને હાલમાં તે ચાલુ છે simple-prog પ્રોગ્રામ (અને જો simple-prog પછી કામ પૂરું કરશે woo અદૃશ્ય થઈ જશે). અપેક્ષા મુજબ, કાર્યક્રમ woo BPF આર્કિટેક્ચરમાં દ્વિસંગી કોડના - બે સૂચનાઓ - 16 બાઇટ્સ લે છે, પરંતુ તેના મૂળ સ્વરૂપમાં (x86_64) તે પહેલેથી જ 40 બાઇટ્સ છે. ચાલો આપણા પ્રોગ્રામને તેના મૂળ સ્વરૂપમાં જોઈએ:

# bpftool prog dump xlated id 390
   0: (b7) r0 = 2
   1: (95) exit

કોઈ આશ્ચર્ય નથી. હવે ચાલો JIT કમ્પાઈલર દ્વારા જનરેટ કરાયેલ કોડ જોઈએ:

# bpftool prog dump jited id 390
bpf_prog_3b185187f1855c4c_woo:
   0:   nopl   0x0(%rax,%rax,1)
   5:   push   %rbp
   6:   mov    %rsp,%rbp
   9:   sub    $0x0,%rsp
  10:   push   %rbx
  11:   push   %r13
  13:   push   %r14
  15:   push   %r15
  17:   pushq  $0x0
  19:   mov    $0x2,%eax
  1e:   pop    %rbx
  1f:   pop    %r15
  21:   pop    %r14
  23:   pop    %r13
  25:   pop    %rbx
  26:   leaveq
  27:   retq

માટે ખૂબ અસરકારક નથી exit(2), પરંતુ વાજબીતામાં, અમારો પ્રોગ્રામ ખૂબ જ સરળ છે, અને બિન-તુચ્છ કાર્યક્રમો માટે JIT કમ્પાઇલર દ્વારા ઉમેરવામાં આવેલ પ્રસ્તાવના અને ઉપસંહારની જરૂર છે.

નકશા

BPF પ્રોગ્રામ્સ સ્ટ્રક્ચર્ડ મેમરી એરિયાનો ઉપયોગ કરી શકે છે જે અન્ય BPF પ્રોગ્રામ્સ અને યુઝર સ્પેસમાં પ્રોગ્રામ્સ બંને માટે સુલભ છે. આ ઑબ્જેક્ટ્સને નકશા કહેવામાં આવે છે અને આ વિભાગમાં અમે બતાવીશું કે સિસ્ટમ કૉલનો ઉપયોગ કરીને તેમને કેવી રીતે ચાલાકી કરવી bpf.

ચાલો તરત જ કહીએ કે નકશાની ક્ષમતાઓ ફક્ત શેર કરેલી મેમરી સુધી જ મર્યાદિત નથી. ત્યાં વિશિષ્ટ હેતુવાળા નકશા છે, ઉદાહરણ તરીકે, BPF પ્રોગ્રામ્સ અથવા નેટવર્ક ઇન્ટરફેસ માટેના નિર્દેશકો, પર્ફ ઇવેન્ટ્સ સાથે કામ કરવા માટેના નકશા વગેરે. અમે અહીં તેમના વિશે વાત કરીશું નહીં, જેથી વાચકને મૂંઝવણમાં ન આવે. આ સિવાય, અમે સિંક્રોનાઇઝેશન મુદ્દાઓને અવગણીએ છીએ, કારણ કે આ અમારા ઉદાહરણો માટે મહત્વપૂર્ણ નથી. ઉપલબ્ધ નકશા પ્રકારોની સંપૂર્ણ સૂચિ આમાં મળી શકે છે <linux/bpf.h>, અને આ વિભાગમાં આપણે ઉદાહરણ તરીકે ઐતિહાસિક રીતે પ્રથમ પ્રકાર, હેશ ટેબલ લઈશું BPF_MAP_TYPE_HASH.

જો તમે હેશ ટેબલ બનાવો છો, તો કહો, C++, તમે કહેશો unordered_map<int,long> woo, જેનો રશિયન અર્થ થાય છે “મને ટેબલની જરૂર છે woo અમર્યાદિત કદ, જેની ચાવીઓ પ્રકારની છે int, અને મૂલ્યો પ્રકાર છે long" BPF હેશ ટેબલ બનાવવા માટે, આપણે ઘણું બધું કરવાની જરૂર છે, સિવાય કે આપણે કોષ્ટકનું મહત્તમ કદ સ્પષ્ટ કરવું પડશે, અને કીના પ્રકારો અને મૂલ્યોનો ઉલ્લેખ કરવાને બદલે, આપણે તેમના કદને બાઈટમાં સ્પષ્ટ કરવાની જરૂર છે. . નકશા બનાવવા માટે આદેશનો ઉપયોગ કરો BPF_MAP_CREATE સિસ્ટમ કૉલ bpf. ચાલો વધુ કે ઓછા ન્યૂનતમ પ્રોગ્રામ જોઈએ જે નકશો બનાવે છે. બીપીએફ પ્રોગ્રામ લોડ કરતા પહેલાના પ્રોગ્રામ પછી, આ તમને સરળ લાગવું જોઈએ:

$ cat simple-map.c
#define _GNU_SOURCE
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/bpf.h>

int main(void)
{
    union bpf_attr attr = {
        .map_type = BPF_MAP_TYPE_HASH,
        .key_size = sizeof(int),
        .value_size = sizeof(int),
        .max_entries = 4,
    };
    strncpy(attr.map_name, "woo", sizeof(attr.map_name));
    syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));

    for ( ;; )
        pause();
}

અહીં આપણે પરિમાણોનો સમૂહ વ્યાખ્યાયિત કરીએ છીએ attr, જેમાં આપણે કહીએ છીએ કે "મને કી અને કદના મૂલ્યો સાથે હેશ ટેબલની જરૂર છે sizeof(int), જેમાં હું વધુમાં વધુ ચાર તત્વો મૂકી શકું છું." BPF નકશા બનાવતી વખતે, તમે અન્ય પરિમાણોનો ઉલ્લેખ કરી શકો છો, ઉદાહરણ તરીકે, પ્રોગ્રામ સાથેના ઉદાહરણની જેમ, અમે ઑબ્જેક્ટનું નામ આ રીતે સ્પષ્ટ કર્યું છે "woo".

ચાલો પ્રોગ્રામ કમ્પાઈલ અને રન કરીએ:

$ clang -g -O2 simple-map.c -o simple-map
$ sudo strace ./simple-map
execve("./simple-map", ["./simple-map"], 0x7ffd40a27070 /* 14 vars */) = 0
...
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4, value_size=4, max_entries=4, map_name="woo", ...}, 72) = 3
pause(

આ રહ્યો સિસ્ટમ કૉલ bpf(2) અમને વર્ણનકર્તા નકશો નંબર પરત કર્યો 3 અને પછી પ્રોગ્રામ, અપેક્ષા મુજબ, સિસ્ટમ કૉલમાં વધુ સૂચનાઓની રાહ જુએ છે pause(2).

હવે ચાલો આપણા પ્રોગ્રામને બેકગ્રાઉન્ડમાં મોકલીએ અથવા બીજું ટર્મિનલ ખોલીએ અને યુટિલિટીનો ઉપયોગ કરીને આપણા ઑબ્જેક્ટને જોઈએ bpftool (અમે અમારા નકશાને તેના નામથી અન્ય લોકોથી અલગ પાડી શકીએ છીએ):

$ sudo bpftool map
...
114: hash  name woo  flags 0x0
        key 4B  value 4B  max_entries 4  memlock 4096B
...

નંબર 114 એ આપણા ઑબ્જેક્ટનું વૈશ્વિક ID છે. સિસ્ટમ પરનો કોઈપણ પ્રોગ્રામ આદેશનો ઉપયોગ કરીને હાલના નકશાને ખોલવા માટે આ ID નો ઉપયોગ કરી શકે છે BPF_MAP_GET_FD_BY_ID સિસ્ટમ કૉલ bpf.

હવે આપણે આપણા હેશ ટેબલ સાથે રમી શકીએ છીએ. ચાલો તેની સામગ્રીઓ જોઈએ:

$ sudo bpftool map dump id 114
Found 0 elements

ખાલી. ચાલો તેમાં એક મૂલ્ય મૂકીએ hash[1] = 1:

$ sudo bpftool map update id 114 key 1 0 0 0 value 1 0 0 0

ચાલો ફરીથી ટેબલ જોઈએ:

$ sudo bpftool map dump id 114
key: 01 00 00 00  value: 01 00 00 00
Found 1 element

હુરે! અમે એક ઘટક ઉમેરવા વ્યવસ્થાપિત. નોંધ કરો કે આ કરવા માટે આપણે બાઈટ સ્તરે કામ કરવું પડશે, ત્યારથી bptftool હેશ ટેબલમાં કયા પ્રકારનાં મૂલ્યો છે તે ખબર નથી. (આ જ્ઞાન તેણીને BTF નો ઉપયોગ કરીને ટ્રાન્સફર કરી શકાય છે, પરંતુ હવે તેના પર વધુ.)

bpftool કેવી રીતે બરાબર વાંચે છે અને તત્વો ઉમેરે છે? ચાલો હૂડ હેઠળ એક નજર કરીએ:

$ sudo strace -e bpf bpftool map dump id 114
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_MAP_GET_NEXT_KEY, {map_fd=3, key=NULL, next_key=0x55856ab65280}, 120) = 0
bpf(BPF_MAP_LOOKUP_ELEM, {map_fd=3, key=0x55856ab65280, value=0x55856ab652a0}, 120) = 0
key: 01 00 00 00  value: 01 00 00 00
bpf(BPF_MAP_GET_NEXT_KEY, {map_fd=3, key=0x55856ab65280, next_key=0x55856ab65280}, 120) = -1 ENOENT

પહેલા આપણે આદેશનો ઉપયોગ કરીને તેના વૈશ્વિક ID દ્વારા નકશો ખોલ્યો BPF_MAP_GET_FD_BY_ID и bpf(2) અમને વર્ણનકર્તા 3 પરત કર્યું. આગળ આદેશનો ઉપયોગ કરીને BPF_MAP_GET_NEXT_KEY અમને પાસ કરીને કોષ્ટકમાં પ્રથમ કી મળી NULL "અગાઉની" કીના નિર્દેશક તરીકે. જો આપણી પાસે ચાવી હોય તો આપણે કરી શકીએ BPF_MAP_LOOKUP_ELEMજે નિર્દેશકને મૂલ્ય પરત કરે છે value. આગળનું પગલું એ છે કે આપણે વર્તમાન કી પર પોઇન્ટર પસાર કરીને આગલું તત્વ શોધવાનો પ્રયાસ કરીએ છીએ, પરંતુ અમારા કોષ્ટકમાં માત્ર એક તત્વ અને આદેશ છે. BPF_MAP_GET_NEXT_KEY પરત કરે છે ENOENT.

ઠીક છે, ચાલો કી 1 દ્વારા મૂલ્ય બદલીએ, ચાલો કહીએ કે અમારા વ્યવસાયના તર્કને નોંધણીની જરૂર છે hash[1] = 2:

$ sudo strace -e bpf bpftool map update id 114 key 1 0 0 0 value 2 0 0 0
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0x55dcd72be260, value=0x55dcd72be280, flags=BPF_ANY}, 120) = 0

અપેક્ષા મુજબ, તે ખૂબ જ સરળ છે: આદેશ BPF_MAP_GET_FD_BY_ID ID અને આદેશ દ્વારા આપણો નકશો ખોલે છે BPF_MAP_UPDATE_ELEM તત્વ પર ફરીથી લખે છે.

તેથી, એક પ્રોગ્રામમાંથી હેશ ટેબલ બનાવ્યા પછી, આપણે બીજા પ્રોગ્રામમાંથી તેના વિષયવસ્તુને વાંચી અને લખી શકીએ છીએ. નોંધ કરો કે જો આપણે કમાન્ડ લાઇનથી આ કરવા સક્ષમ હતા, તો સિસ્ટમ પરનો કોઈપણ અન્ય પ્રોગ્રામ તે કરી શકે છે. ઉપર વર્ણવેલ આદેશો ઉપરાંત, વપરાશકર્તા જગ્યામાંથી નકશા સાથે કામ કરવા માટે, નીચેના:

• BPF_MAP_LOOKUP_ELEM: કી દ્વારા મૂલ્ય શોધો
• BPF_MAP_UPDATE_ELEM: અપડેટ/ક્રિએટ વેલ્યુ
• BPF_MAP_DELETE_ELEM: કી દૂર કરો
• BPF_MAP_GET_NEXT_KEY: આગલી (અથવા પ્રથમ) કી શોધો
• BPF_MAP_GET_NEXT_ID: તમને હાલના તમામ નકશામાંથી પસાર થવાની મંજૂરી આપે છે, તે આ રીતે કાર્ય કરે છે bpftool map
• BPF_MAP_GET_FD_BY_ID: હાલના નકશાને તેના વૈશ્વિક ID દ્વારા ખોલો
• BPF_MAP_LOOKUP_AND_DELETE_ELEM: ઑબ્જેક્ટની કિંમત પરમાણુ રીતે અપડેટ કરો અને જૂનું પરત કરો
• BPF_MAP_FREEZE: યુઝરસ્પેસમાંથી નકશાને અપરિવર્તનશીલ બનાવો (આ કામગીરી પૂર્વવત્ કરી શકાતી નથી)
• BPF_MAP_LOOKUP_BATCH, BPF_MAP_LOOKUP_AND_DELETE_BATCH, BPF_MAP_UPDATE_BATCH, BPF_MAP_DELETE_BATCH: સામૂહિક કામગીરી. દાખ્લા તરીકે, BPF_MAP_LOOKUP_AND_DELETE_BATCH - નકશામાંથી તમામ મૂલ્યો વાંચવા અને રીસેટ કરવાની આ એકમાત્ર વિશ્વસનીય રીત છે

આ તમામ આદેશો તમામ નકશા પ્રકારો માટે કામ કરતા નથી, પરંતુ સામાન્ય રીતે વપરાશકર્તા જગ્યામાંથી અન્ય પ્રકારના નકશા સાથે કામ કરવું એ હેશ કોષ્ટકો સાથે કામ કરવા જેવું જ દેખાય છે.

ઓર્ડર ખાતર, ચાલો અમારા હેશ ટેબલ પ્રયોગો સમાપ્ત કરીએ. યાદ રાખો કે અમે એક ટેબલ બનાવ્યું છે જેમાં ચાર સુધી કી સમાવી શકાય છે? ચાલો થોડા વધુ ઘટકો ઉમેરીએ:

$ sudo bpftool map update id 114 key 2 0 0 0 value 1 0 0 0
$ sudo bpftool map update id 114 key 3 0 0 0 value 1 0 0 0
$ sudo bpftool map update id 114 key 4 0 0 0 value 1 0 0 0

અત્યાર સુધી ખૂબ સારું:

$ sudo bpftool map dump id 114
key: 01 00 00 00  value: 01 00 00 00
key: 02 00 00 00  value: 01 00 00 00
key: 04 00 00 00  value: 01 00 00 00
key: 03 00 00 00  value: 01 00 00 00
Found 4 elements

ચાલો એક વધુ ઉમેરવાનો પ્રયાસ કરીએ:

$ sudo bpftool map update id 114 key 5 0 0 0 value 1 0 0 0
Error: update failed: Argument list too long

અપેક્ષા મુજબ, અમે સફળ થયા નથી. ચાલો ભૂલને વધુ વિગતમાં જોઈએ:

$ sudo strace -e bpf bpftool map update id 114 key 5 0 0 0 value 1 0 0 0
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=3, info_len=80, info=0x7ffe6c626da0}}, 120) = 0
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0x56049ded5260, value=0x56049ded5280, flags=BPF_ANY}, 120) = -1 E2BIG (Argument list too long)
Error: update failed: Argument list too long
+++ exited with 255 +++

બધું સારું છે: અપેક્ષા મુજબ, ટીમ BPF_MAP_UPDATE_ELEM નવી, પાંચમી, કી બનાવવાનો પ્રયાસ કરે છે, પરંતુ ક્રેશ થાય છે E2BIG.

તેથી, અમે BPF પ્રોગ્રામ બનાવી અને લોડ કરી શકીએ છીએ, તેમજ યુઝર સ્પેસમાંથી નકશા બનાવી અને મેનેજ કરી શકીએ છીએ. હવે આપણે BPF પ્રોગ્રામ્સમાંથી નકશાનો ઉપયોગ કેવી રીતે કરી શકીએ તે જોવાનું તાર્કિક છે. અમે મશીન મેક્રો કોડ્સમાં હાર્ડ-ટુ-રીડ પ્રોગ્રામ્સની ભાષામાં આ વિશે વાત કરી શકીએ છીએ, પરંતુ હકીકતમાં BPF પ્રોગ્રામ્સ ખરેખર કેવી રીતે લખવામાં આવે છે અને જાળવવામાં આવે છે તે બતાવવાનો સમય આવી ગયો છે - ઉપયોગ કરીને libbpf.

(નિમ્ન-સ્તરના ઉદાહરણના અભાવથી અસંતુષ્ટ વાચકો માટે: અમે વિગતવાર પ્રોગ્રામ્સનું વિશ્લેષણ કરીશું જે નકશા અને સહાયક કાર્યોનો ઉપયોગ કરીને બનાવેલ છે. libbpf અને સૂચના સ્તરે શું થાય છે તે તમને જણાવશે. અસંતુષ્ટ વાચકો માટે ખૂબ ખૂબ, અમે ઉમેર્યું ઉદાહરણ લેખમાં યોગ્ય જગ્યાએ.)

libbpf નો ઉપયોગ કરીને BPF પ્રોગ્રામ્સ લખવા

મશીન કોડનો ઉપયોગ કરીને BPF પ્રોગ્રામ્સ લખવું એ પ્રથમ વખત જ રસપ્રદ હોઈ શકે છે, અને પછી સંતૃપ્તિ સેટ થઈ જાય છે. આ ક્ષણે તમારે તમારું ધ્યાન તેના પર ફેરવવાની જરૂર છે llvm, જે BPF આર્કિટેક્ચર માટે કોડ જનરેટ કરવા માટે બેકએન્ડ ધરાવે છે, તેમજ પુસ્તકાલય libbpf, જે તમને BPF એપ્લિકેશન્સની વપરાશકર્તા બાજુ લખવા અને BPF પ્રોગ્રામ્સનો ઉપયોગ કરીને જનરેટ કરેલા કોડને લોડ કરવાની મંજૂરી આપે છે. llvm/clang.

હકીકતમાં, જેમ આપણે આ અને પછીના લેખોમાં જોઈશું, libbpf તેના વિના ઘણું કામ કરે છે (અથવા સમાન સાધનો - iproute2, libbcc, libbpf-go, વગેરે) જીવવું અશક્ય છે. પ્રોજેક્ટની ખૂની વિશેષતાઓમાંની એક libbpf BPF CO-RE છે (વન્સ કમ્પાઇલ કરો, દરેક જગ્યાએ ચલાવો) - એક પ્રોજેક્ટ જે તમને BPF પ્રોગ્રામ્સ લખવાની પરવાનગી આપે છે જે એક કર્નલથી બીજા કર્નલ પર પોર્ટેબલ હોય છે, જેમાં વિવિધ API પર ચલાવવાની ક્ષમતા હોય છે (ઉદાહરણ તરીકે, જ્યારે કર્નલનું માળખું સંસ્કરણથી બદલાય છે. સંસ્કરણ સુધી). CO-RE સાથે કામ કરવા માટે સક્ષમ થવા માટે, તમારી કર્નલ BTF સપોર્ટ સાથે સંકલિત હોવી આવશ્યક છે (આ કેવી રીતે કરવું તે અમે વિભાગમાં વર્ણવીએ છીએ. વિકાસ સાધનો. તમે નીચેની ફાઇલની હાજરી દ્વારા - તમારી કર્નલ BTF સાથે બનેલ છે કે નહીં તે ખૂબ જ સરળ રીતે તપાસી શકો છો:

$ ls -lh /sys/kernel/btf/vmlinux
-r--r--r-- 1 root root 2.6M Jul 29 15:30 /sys/kernel/btf/vmlinux

આ ફાઇલ કર્નલમાં ઉપયોગમાં લેવાતા તમામ ડેટા પ્રકારો વિશેની માહિતી સંગ્રહિત કરે છે અને તેનો ઉપયોગ અમારા બધા ઉદાહરણોમાં થાય છે libbpf. અમે આગામી લેખમાં CO-RE વિશે વિગતવાર વાત કરીશું, પરંતુ આમાં - ફક્ત તમારી જાતને એક કર્નલ બનાવો CONFIG_DEBUG_INFO_BTF.

પુસ્તકાલય libbpf ડિરેક્ટરીમાં જ રહે છે tools/lib/bpf કર્નલ અને તેનો વિકાસ મેઇલિંગ સૂચિ દ્વારા કરવામાં આવે છે [email protected]. જો કે, કર્નલની બહાર રહેતા કાર્યક્રમોની જરૂરિયાતો માટે અલગ રીપોઝીટરી જાળવવામાં આવે છે https://github.com/libbpf/libbpf જેમાં કર્નલ લાઇબ્રેરી વધુ કે ઓછા વાંચવા માટે પ્રતિબિંબિત છે.

આ વિભાગમાં અમે જોઈશું કે તમે કેવી રીતે ઉપયોગ કરે છે તે પ્રોજેક્ટ બનાવી શકો છો libbpf, ચાલો કેટલાક (વધુ કે ઓછા અર્થહીન) પરીક્ષણ કાર્યક્રમો લખીએ અને વિગતવાર વિશ્લેષણ કરીએ કે તે બધું કેવી રીતે કાર્ય કરે છે. આ અમને નીચેના વિભાગોમાં વધુ સરળતાથી સમજાવવા દેશે કે BPF પ્રોગ્રામ નકશા, કર્નલ હેલ્પર્સ, BTF વગેરે સાથે કેવી રીતે ક્રિયાપ્રતિક્રિયા કરે છે.

સામાન્ય રીતે પ્રોજેક્ટનો ઉપયોગ કરીને libbpf ગિટ સબમોડ્યુલ તરીકે GitHub રીપોઝીટરી ઉમેરો, અમે તે જ કરીશું:

$ mkdir /tmp/libbpf-example
$ cd /tmp/libbpf-example/
$ git init-db
Initialized empty Git repository in /tmp/libbpf-example/.git/
$ git submodule add https://github.com/libbpf/libbpf.git
Cloning into '/tmp/libbpf-example/libbpf'...
remote: Enumerating objects: 200, done.
remote: Counting objects: 100% (200/200), done.
remote: Compressing objects: 100% (103/103), done.
remote: Total 3354 (delta 101), reused 118 (delta 79), pack-reused 3154
Receiving objects: 100% (3354/3354), 2.05 MiB | 10.22 MiB/s, done.
Resolving deltas: 100% (2176/2176), done.

જઈ રહ્યો છુ libbpf ઘણું સરળ:

$ cd libbpf/src
$ mkdir build
$ OBJDIR=build DESTDIR=root make -s install
$ find root
root
root/usr
root/usr/include
root/usr/include/bpf
root/usr/include/bpf/bpf_tracing.h
root/usr/include/bpf/xsk.h
root/usr/include/bpf/libbpf_common.h
root/usr/include/bpf/bpf_endian.h
root/usr/include/bpf/bpf_helpers.h
root/usr/include/bpf/btf.h
root/usr/include/bpf/bpf_helper_defs.h
root/usr/include/bpf/bpf.h
root/usr/include/bpf/libbpf_util.h
root/usr/include/bpf/libbpf.h
root/usr/include/bpf/bpf_core_read.h
root/usr/lib64
root/usr/lib64/libbpf.so.0.1.0
root/usr/lib64/libbpf.so.0
root/usr/lib64/libbpf.a
root/usr/lib64/libbpf.so
root/usr/lib64/pkgconfig
root/usr/lib64/pkgconfig/libbpf.pc

આ વિભાગમાં અમારી આગામી યોજના નીચે મુજબ છે: અમે BPF પ્રોગ્રામ લખીશું BPF_PROG_TYPE_XDP, અગાઉના ઉદાહરણની જેમ જ, પરંતુ C માં, અમે તેનો ઉપયોગ કરીને કમ્પાઇલ કરીએ છીએ clang, અને સહાયક પ્રોગ્રામ લખો જે તેને કર્નલમાં લોડ કરશે. નીચેના વિભાગોમાં અમે BPF પ્રોગ્રામ અને આસિસ્ટન્ટ પ્રોગ્રામ બંનેની ક્ષમતાઓને વિસ્તૃત કરીશું.

ઉદાહરણ: libbpf નો ઉપયોગ કરીને સંપૂર્ણ એપ્લિકેશન બનાવવી

શરૂ કરવા માટે, અમે ફાઇલનો ઉપયોગ કરીએ છીએ /sys/kernel/btf/vmlinux, જેનો ઉપર ઉલ્લેખ કરવામાં આવ્યો હતો, અને હેડર ફાઇલના રૂપમાં તેની સમકક્ષ બનાવો:

$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

આ ફાઇલ અમારા કર્નલમાં ઉપલબ્ધ તમામ ડેટા સ્ટ્રક્ચર્સને સંગ્રહિત કરશે, ઉદાહરણ તરીકે, કર્નલમાં IPv4 હેડરને આ રીતે વ્યાખ્યાયિત કરવામાં આવે છે:

$ grep -A 12 'struct iphdr {' vmlinux.h
struct iphdr {
    __u8 ihl: 4;
    __u8 version: 4;
    __u8 tos;
    __be16 tot_len;
    __be16 id;
    __be16 frag_off;
    __u8 ttl;
    __u8 protocol;
    __sum16 check;
    __be32 saddr;
    __be32 daddr;
};

હવે આપણે અમારો BPF પ્રોગ્રામ C માં લખીશું:

$ cat xdp-simple.bpf.c
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

SEC("xdp/simple")
int simple(void *ctx)
{
        return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

જો કે અમારો પ્રોગ્રામ ખૂબ જ સરળ હતો, તેમ છતાં અમારે ઘણી વિગતો પર ધ્યાન આપવાની જરૂર છે. પ્રથમ, અમે સમાવિષ્ટ પ્રથમ હેડર ફાઈલ છે vmlinux.h, જેનો ઉપયોગ અમે હમણાં જ જનરેટ કર્યો છે bpftool btf dump - હવે કર્નલ સ્ટ્રક્ચર્સ કેવા દેખાય છે તે શોધવા માટે આપણે કર્નલ-હેડર પેકેજ ઇન્સ્ટોલ કરવાની જરૂર નથી. નીચેની હેડર ફાઇલ લાઇબ્રેરીમાંથી અમારી પાસે આવે છે libbpf. હવે આપણને ફક્ત મેક્રોને વ્યાખ્યાયિત કરવા માટે તેની જરૂર છે SEC, જે પાત્રને ELF ઑબ્જેક્ટ ફાઇલના યોગ્ય વિભાગમાં મોકલે છે. અમારો પ્રોગ્રામ વિભાગમાં સમાયેલ છે xdp/simple, જ્યાં સ્લેશ પહેલાં આપણે પ્રોગ્રામ પ્રકાર BPF ને વ્યાખ્યાયિત કરીએ છીએ - આમાં વપરાયેલ સંમેલન છે libbpf, વિભાગના નામના આધારે તે સ્ટાર્ટઅપ વખતે યોગ્ય પ્રકારને બદલે છે bpf(2). BPF પ્રોગ્રામ પોતે છે C - ખૂબ જ સરળ અને એક લીટી ધરાવે છે return XDP_PASS. અંતે, એક અલગ વિભાગ "license" લાયસન્સનું નામ સમાવે છે.

અમે અમારા પ્રોગ્રામને llvm/clang, વર્ઝન >= 10.0.0, અથવા હજુ વધુ સારા, વધુનો ઉપયોગ કરીને કમ્પાઇલ કરી શકીએ છીએ (વિભાગ જુઓ વિકાસ સાધનો):

$ clang --version
clang version 11.0.0 (https://github.com/llvm/llvm-project.git afc287e0abec710398465ee1f86237513f2b5091)
...

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o

રસપ્રદ લક્ષણો પૈકી: અમે લક્ષ્ય આર્કિટેક્ચર સૂચવે છે -target bpf અને હેડરોનો માર્ગ libbpf, જે અમે તાજેતરમાં ઇન્સ્ટોલ કર્યું છે. ઉપરાંત, વિશે ભૂલશો નહીં -O2, આ વિકલ્પ વિના તમે ભવિષ્યમાં આશ્ચર્યજનક બની શકો છો. ચાલો આપણો કોડ જોઈએ, શું આપણે જોઈતો પ્રોગ્રામ લખવાનું મેનેજ કર્યું?

$ llvm-objdump --section=xdp/simple --no-show-raw-insn -D xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       r0 = 2
       1:       exit

હા, તે કામ કર્યું! હવે, અમારી પાસે પ્રોગ્રામ સાથે બાઈનરી ફાઇલ છે, અને અમે એક એપ્લિકેશન બનાવવા માંગીએ છીએ જે તેને કર્નલમાં લોડ કરશે. આ હેતુ માટે પુસ્તકાલય libbpf અમને બે વિકલ્પો ઓફર કરે છે - નીચલા-સ્તરના API અથવા ઉચ્ચ-સ્તરના APIનો ઉપયોગ કરો. અમે બીજી રીતે જઈશું, કારણ કે અમે BPF પ્રોગ્રામને તેમના અનુગામી અભ્યાસ માટે ન્યૂનતમ પ્રયત્નો સાથે કેવી રીતે લખવા, લોડ કરવા અને કનેક્ટ કરવા તે શીખવા માંગીએ છીએ.

પ્રથમ, આપણે સમાન ઉપયોગિતાનો ઉપયોગ કરીને તેના દ્વિસંગીમાંથી આપણા પ્રોગ્રામનું "હાડપિંજર" જનરેટ કરવાની જરૂર છે. bpftool - BPF વિશ્વની સ્વિસ છરી (જેને શાબ્દિક રીતે લઈ શકાય છે, કારણ કે BPFના સર્જકો અને જાળવણીકારોમાંના એક ડેનિયલ બોર્કમેન સ્વિસ છે):

$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h

ફાઈલમાં xdp-simple.skel.h અમારા પ્રોગ્રામનો બાઈનરી કોડ અને મેનેજ કરવા માટેના કાર્યો સમાવે છે - અમારા ઑબ્જેક્ટને લોડ કરવા, જોડવા, કાઢી નાખવા. અમારા સાદા કિસ્સામાં આ ઓવરકિલ જેવું લાગે છે, પરંતુ તે એવા કિસ્સામાં પણ કામ કરે છે જ્યાં ઑબ્જેક્ટ ફાઇલમાં ઘણા બધા BPF પ્રોગ્રામ્સ અને નકશા હોય છે અને આ વિશાળ ELF લોડ કરવા માટે આપણે ફક્ત હાડપિંજર જનરેટ કરવાની જરૂર છે અને કસ્ટમ એપ્લિકેશનમાંથી એક કે બે ફંક્શનને કૉલ કરવાની જરૂર છે. લખી રહ્યા છીએ ચાલો હવે આગળ વધીએ.

કડક શબ્દોમાં કહીએ તો, અમારો લોડર પ્રોગ્રામ નજીવો છે:

#include <err.h>
#include <unistd.h>
#include "xdp-simple.skel.h"

int main(int argc, char **argv)
{
    struct xdp_simple_bpf *obj;

    obj = xdp_simple_bpf__open_and_load();
    if (!obj)
        err(1, "failed to open and/or load BPF objectn");

    pause();

    xdp_simple_bpf__destroy(obj);
}

તે struct xdp_simple_bpf ફાઈલમાં વ્યાખ્યાયિત કરેલ છે xdp-simple.skel.h અને અમારી ઑબ્જેક્ટ ફાઇલનું વર્ણન કરે છે:

struct xdp_simple_bpf {
    struct bpf_object_skeleton *skeleton;
    struct bpf_object *obj;
    struct {
        struct bpf_program *simple;
    } progs;
    struct {
        struct bpf_link *simple;
    } links;
};

આપણે અહીં નિમ્ન-સ્તરના API ના નિશાન જોઈ શકીએ છીએ: માળખું struct bpf_program *simple и struct bpf_link *simple. પ્રથમ માળખું ખાસ કરીને વિભાગમાં લખેલા અમારા પ્રોગ્રામનું વર્ણન કરે છે xdp/simple, અને બીજું વર્ણન કરે છે કે પ્રોગ્રામ ઇવેન્ટ સ્ત્રોત સાથે કેવી રીતે જોડાય છે.

કાર્ય xdp_simple_bpf__open_and_load, એક ELF ઑબ્જેક્ટ ખોલે છે, તેને પાર્સ કરે છે, તમામ સ્ટ્રક્ચર્સ અને સબસ્ટ્રક્ચર્સ બનાવે છે (પ્રોગ્રામ ઉપરાંત, ELF માં અન્ય વિભાગો પણ હોય છે - ડેટા, ફક્ત વાંચવા માટેનો ડેટા, ડિબગીંગ માહિતી, લાઇસન્સ, વગેરે), અને પછી સિસ્ટમનો ઉપયોગ કરીને તેને કર્નલમાં લોડ કરે છે. કૉલ bpf, જેને આપણે કમ્પાઈલ કરીને અને પ્રોગ્રામ ચલાવીને ચકાસી શકીએ છીએ:

$ clang -O2 -I ./libbpf/src/root/usr/include/ xdp-simple.c -o xdp-simple ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz

$ sudo strace -e bpf ./xdp-simple
...
bpf(BPF_BTF_LOAD, 0x7ffdb8fd9670, 120)  = 3
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=2, insns=0xdfd580, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_VERSION(5, 8, 0), prog_flags=0, prog_name="simple", prog_ifindex=0, expected_attach_type=0x25 /* BPF_??? */, ...}, 120) = 4

ચાલો હવે અમારા પ્રોગ્રામનો ઉપયોગ કરીને જોઈએ bpftool. ચાલો તેણીનું ID શોધીએ:

# bpftool p | grep -A4 simple
463: xdp  name simple  tag 3b185187f1855c4c  gpl
        loaded_at 2020-08-01T01:59:49+0000  uid 0
        xlated 16B  jited 40B  memlock 4096B
        btf_id 185
        pids xdp-simple(16498)

અને ડમ્પ (આપણે આદેશના ટૂંકા સ્વરૂપનો ઉપયોગ કરીએ છીએ bpftool prog dump xlated):

# bpftool p d x id 463
int simple(void *ctx):
; return XDP_PASS;
   0: (b7) r0 = 2
   1: (95) exit

કઈક નવું! પ્રોગ્રામે અમારી સી સોર્સ ફાઈલના હિસ્સાને મુદ્રિત કર્યા છે. આ લાઈબ્રેરી દ્વારા કરવામાં આવ્યું હતું libbpf, જેને બાઈનરીમાં ડીબગ વિભાગ મળ્યો, તેને BTF ઑબ્જેક્ટમાં કમ્પાઈલ કર્યો, તેને કર્નલમાં લોડ કર્યો BPF_BTF_LOAD, અને પછી આદેશ સાથે પ્રોગ્રામ લોડ કરતી વખતે પરિણામી ફાઇલ વર્ણનકર્તાનો ઉલ્લેખ કરો BPG_PROG_LOAD.

કર્નલ હેલ્પર્સ

BPF પ્રોગ્રામ્સ "બાહ્ય" કાર્યો ચલાવી શકે છે - કર્નલ હેલ્પર્સ. આ સહાયક કાર્યો BPF પ્રોગ્રામ્સને કર્નલ સ્ટ્રક્ચર્સ ઍક્સેસ કરવા, નકશાનું સંચાલન કરવા અને "વાસ્તવિક વિશ્વ" સાથે વાતચીત કરવાની મંજૂરી આપે છે - પર્ફ ઇવેન્ટ્સ બનાવો, હાર્ડવેરને નિયંત્રિત કરો (ઉદાહરણ તરીકે, પેકેટો રીડાયરેક્ટ કરો), વગેરે.

ઉદાહરણ: bpf_get_smp_processor_id

"ઉદાહરણ દ્વારા શીખવું" પેરાડાઈમના માળખામાં, ચાલો એક સહાયક કાર્યોને ધ્યાનમાં લઈએ, bpf_get_smp_processor_id(), ચોક્કસ ફાઇલમાં kernel/bpf/helpers.c. તે પ્રોસેસરનો નંબર આપે છે કે જેના પર BPF પ્રોગ્રામ જે તેને કહેવાય છે તે ચાલી રહ્યો છે. પરંતુ અમને તેના સિમેન્ટિક્સમાં એટલો રસ નથી જેટલો એ હકીકતમાં છે કે તેના અમલીકરણમાં એક લીટી લાગે છે:

BPF_CALL_0(bpf_get_smp_processor_id)
{
    return smp_processor_id();
}

BPF હેલ્પર ફંક્શન વ્યાખ્યાઓ Linux સિસ્ટમ કોલ વ્યાખ્યાઓ જેવી જ છે. અહીં, ઉદાહરણ તરીકે, ફંક્શનને વ્યાખ્યાયિત કરવામાં આવ્યું છે જેમાં કોઈ દલીલો નથી. (એક કાર્ય જે લે છે, કહો, ત્રણ દલીલો મેક્રોનો ઉપયોગ કરીને વ્યાખ્યાયિત કરવામાં આવે છે BPF_CALL_3. દલીલોની મહત્તમ સંખ્યા પાંચ છે.) જો કે, આ વ્યાખ્યાનો માત્ર પ્રથમ ભાગ છે. બીજો ભાગ પ્રકારનું માળખું વ્યાખ્યાયિત કરવાનો છે struct bpf_func_proto, જેમાં હેલ્પર ફંક્શનનું વર્ણન છે જે વેરિફાયર સમજે છે:

const struct bpf_func_proto bpf_get_smp_processor_id_proto = {
    .func     = bpf_get_smp_processor_id,
    .gpl_only = false,
    .ret_type = RET_INTEGER,
};

હેલ્પર કાર્યોની નોંધણી

આ ફંક્શનનો ઉપયોગ કરવા માટે ચોક્કસ પ્રકારના BPF પ્રોગ્રામ્સ માટે, તેઓએ તેની નોંધણી કરાવવી આવશ્યક છે, ઉદાહરણ તરીકે પ્રકાર માટે BPF_PROG_TYPE_XDP કર્નલમાં કાર્ય વ્યાખ્યાયિત થયેલ છે xdp_func_proto, જે હેલ્પર ફંક્શન ID પરથી નક્કી કરે છે કે XDP આ ફંક્શનને સપોર્ટ કરે છે કે નહીં. અમારું કાર્ય છે આધાર આપે છે:

static const struct bpf_func_proto *
xdp_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
{
    switch (func_id) {
    ...
    case BPF_FUNC_get_smp_processor_id:
        return &bpf_get_smp_processor_id_proto;
    ...
    }
}

નવા BPF પ્રોગ્રામ પ્રકારો ફાઇલમાં "વ્યાખ્યાયિત" છે include/linux/bpf_types.h મેક્રોનો ઉપયોગ કરીને BPF_PROG_TYPE. અવતરણમાં વ્યાખ્યાયિત કારણ કે તે એક તાર્કિક વ્યાખ્યા છે, અને C ભાષાની શરતોમાં કોંક્રિટ માળખાના સંપૂર્ણ સમૂહની વ્યાખ્યા અન્ય સ્થળોએ થાય છે. ખાસ કરીને, ફાઇલમાં kernel/bpf/verifier.c ફાઇલમાંથી બધી વ્યાખ્યાઓ bpf_types.h સ્ટ્રક્ચર્સની શ્રેણી બનાવવા માટે વપરાય છે bpf_verifier_ops[]:

static const struct bpf_verifier_ops *const bpf_verifier_ops[] = {
#define BPF_PROG_TYPE(_id, _name, prog_ctx_type, kern_ctx_type) 
    [_id] = & _name ## _verifier_ops,
#include <linux/bpf_types.h>
#undef BPF_PROG_TYPE
};

એટલે કે, દરેક પ્રકારના BPF પ્રોગ્રામ માટે, પ્રકારના ડેટા સ્ટ્રક્ચર માટે નિર્દેશક વ્યાખ્યાયિત કરવામાં આવે છે struct bpf_verifier_ops, જે મૂલ્ય સાથે પ્રારંભ થાય છે _name ## _verifier_ops, એટલે કે, xdp_verifier_ops માટે xdp... માળખું xdp_verifier_ops નિર્ધારિત ફાઇલમાં net/core/filter.c નીચે પ્રમાણે છે:

const struct bpf_verifier_ops xdp_verifier_ops = {
    .get_func_proto     = xdp_func_proto,
    .is_valid_access    = xdp_is_valid_access,
    .convert_ctx_access = xdp_convert_ctx_access,
    .gen_prologue       = bpf_noop_prologue,
};

અહીં આપણે આપણું પરિચિત કાર્ય જોઈએ છીએ xdp_func_proto, જે વેરિફાયરને જ્યારે પણ પડકારનો સામનો કરશે ત્યારે તેને ચલાવશે અમુક પ્રકારની BPF પ્રોગ્રામની અંદરના કાર્યો, જુઓ verifier.c.

ચાલો જોઈએ કે કેવી રીતે અનુમાનિત BPF પ્રોગ્રામ ફંક્શનનો ઉપયોગ કરે છે bpf_get_smp_processor_id. આ કરવા માટે, અમે અમારા પાછલા વિભાગમાંથી પ્રોગ્રામને નીચે પ્રમાણે ફરીથી લખીએ છીએ:

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

SEC("xdp/simple")
int simple(void *ctx)
{
    if (bpf_get_smp_processor_id() != 0)
        return XDP_DROP;
    return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

Символ bpf_get_smp_processor_id નિર્ધારિત в <bpf/bpf_helper_defs.h> પુસ્તકાલયો libbpf કેવી રીતે

static u32 (*bpf_get_smp_processor_id)(void) = (void *) 8;

તે જ, bpf_get_smp_processor_id ફંક્શન પોઇન્ટર છે જેની કિંમત 8 છે, જ્યાં 8 એ મૂલ્ય છે BPF_FUNC_get_smp_processor_id પ્રકાર enum bpf_fun_id, જે આપણા માટે ફાઈલમાં વ્યાખ્યાયિત થયેલ છે vmlinux.h (ફાઈલ bpf_helper_defs.h કર્નલમાં સ્ક્રિપ્ટ દ્વારા જનરેટ થાય છે, તેથી "મેજિક" નંબરો બરાબર છે). આ ફંક્શન કોઈ દલીલો લેતું નથી અને પ્રકારનું મૂલ્ય આપે છે __u32. જ્યારે આપણે તેને અમારા પ્રોગ્રામમાં ચલાવીએ છીએ, clang એક સૂચના જનરેટ કરે છે BPF_CALL "સાચો પ્રકાર" ચાલો પ્રોગ્રામનું સંકલન કરીએ અને વિભાગ જોઈએ xdp/simple:

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o
$ llvm-objdump -D --section=xdp/simple xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       bf 01 00 00 00 00 00 00 r1 = r0
       2:       67 01 00 00 20 00 00 00 r1 <<= 32
       3:       77 01 00 00 20 00 00 00 r1 >>= 32
       4:       b7 00 00 00 02 00 00 00 r0 = 2
       5:       15 01 01 00 00 00 00 00 if r1 == 0 goto +1 <LBB0_2>
       6:       b7 00 00 00 01 00 00 00 r0 = 1

0000000000000038 <LBB0_2>:
       7:       95 00 00 00 00 00 00 00 exit

પ્રથમ લીટીમાં આપણે સૂચનાઓ જોઈએ છીએ call, પરિમાણ IMM જે 8 ની બરાબર છે, અને SRC_REG - શૂન્ય. વેરિફાયર દ્વારા ઉપયોગમાં લેવાતા ABI એગ્રીમેન્ટ અનુસાર, આ હેલ્પર ફંક્શન નંબર આઠ પર કોલ છે. એકવાર તે લોન્ચ થઈ જાય, તર્ક સરળ છે. રજિસ્ટરમાંથી વળતર મૂલ્ય r0 પર નકલ કરી r1 અને લીટીઓ 2,3 પર તે પ્રકારમાં રૂપાંતરિત થાય છે u32 - ઉપલા 32 બિટ્સ સાફ થાય છે. લીટીઓ 4,5,6,7 પર આપણે 2 પરત કરીએ છીએ (XDP_PASS) અથવા 1 (XDP_DROP) લાઇન 0 થી હેલ્પર ફંક્શન શૂન્ય અથવા બિન-શૂન્ય મૂલ્ય પરત કરે છે તેના આધારે.

ચાલો આપણી જાતને ચકાસીએ: પ્રોગ્રામ લોડ કરો અને આઉટપુટ જુઓ bpftool prog dump xlated:

$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h
$ clang -O2 -g -I ./libbpf/src/root/usr/include/ -o xdp-simple xdp-simple.c ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz
$ sudo ./xdp-simple &
[2] 10914

$ sudo bpftool p | grep simple
523: xdp  name simple  tag 44c38a10c657e1b0  gpl
        pids xdp-simple(10915)

$ sudo bpftool p d x id 523
int simple(void *ctx):
; if (bpf_get_smp_processor_id() != 0)
   0: (85) call bpf_get_smp_processor_id#114128
   1: (bf) r1 = r0
   2: (67) r1 <<= 32
   3: (77) r1 >>= 32
   4: (b7) r0 = 2
; }
   5: (15) if r1 == 0x0 goto pc+1
   6: (b7) r0 = 1
   7: (95) exit

ઓકે, વેરિફાયરને યોગ્ય કર્નલ-સહાયક મળ્યો.

ઉદાહરણ: દલીલો પસાર કરવી અને અંતે પ્રોગ્રામ ચલાવવો!

બધા રન-લેવલ હેલ્પર ફંક્શનમાં પ્રોટોટાઇપ હોય છે

u64 fn(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)

સહાયક કાર્યોના પરિમાણો રજીસ્ટરમાં પસાર કરવામાં આવે છે r1-r5, અને મૂલ્ય રજીસ્ટરમાં પરત કરવામાં આવે છે r0. ત્યાં કોઈ ફંક્શન નથી કે જે પાંચ કરતાં વધુ દલીલો લે છે, અને ભવિષ્યમાં તેમના માટે સમર્થન ઉમેરવામાં આવે તેવી અપેક્ષા નથી.

ચાલો નવા કર્નલ હેલ્પર પર એક નજર કરીએ અને BPF કેવી રીતે પરિમાણો પસાર કરે છે. ચાલો ફરીથી લખીએ xdp-simple.bpf.c નીચે મુજબ (બાકીની લીટીઓ બદલાઈ નથી):

SEC("xdp/simple")
int simple(void *ctx)
{
    bpf_printk("running on CPU%un", bpf_get_smp_processor_id());
    return XDP_PASS;
}

અમારો પ્રોગ્રામ CPU નો નંબર છાપે છે જેના પર તે ચાલી રહ્યું છે. ચાલો તેને કમ્પાઈલ કરીએ અને કોડ જોઈએ:

$ llvm-objdump -D --section=xdp/simple --no-show-raw-insn xdp-simple.bpf.o

0000000000000000 <simple>:
       0:       r1 = 10
       1:       *(u16 *)(r10 - 8) = r1
       2:       r1 = 8441246879787806319 ll
       4:       *(u64 *)(r10 - 16) = r1
       5:       r1 = 2334956330918245746 ll
       7:       *(u64 *)(r10 - 24) = r1
       8:       call 8
       9:       r1 = r10
      10:       r1 += -24
      11:       r2 = 18
      12:       r3 = r0
      13:       call 6
      14:       r0 = 2
      15:       exit

0-7 લીટીઓમાં આપણે શબ્દમાળા લખીએ છીએ running on CPU%un, અને પછી લીટી 8 પર આપણે પરિચિતને ચલાવીએ છીએ bpf_get_smp_processor_id. લીટીઓ 9-12 પર અમે મદદગાર દલીલો તૈયાર કરીએ છીએ bpf_printk - રજીસ્ટર r1, r2, r3. શા માટે તેમાંથી ત્રણ છે અને બે નથી? કારણ કે bpf_printk - આ એક મેક્રો રેપર છે વાસ્તવિક સહાયકની આસપાસ bpf_trace_printk, જેને ફોર્મેટ સ્ટ્રિંગનું કદ પસાર કરવાની જરૂર છે.

ચાલો હવે તેમાં બે લીટીઓ ઉમેરીએ xdp-simple.cજેથી અમારો પ્રોગ્રામ ઈન્ટરફેસ સાથે જોડાય lo અને ખરેખર શરૂ કર્યું!

$ cat xdp-simple.c
#include <linux/if_link.h>
#include <err.h>
#include <unistd.h>
#include "xdp-simple.skel.h"

int main(int argc, char **argv)
{
    __u32 flags = XDP_FLAGS_SKB_MODE;
    struct xdp_simple_bpf *obj;

    obj = xdp_simple_bpf__open_and_load();
    if (!obj)
        err(1, "failed to open and/or load BPF objectn");

    bpf_set_link_xdp_fd(1, -1, flags);
    bpf_set_link_xdp_fd(1, bpf_program__fd(obj->progs.simple), flags);

cleanup:
    xdp_simple_bpf__destroy(obj);
}

અહીં આપણે ફંક્શનનો ઉપયોગ કરીએ છીએ bpf_set_link_xdp_fd, જે XDP-પ્રકાર BPF પ્રોગ્રામ્સને નેટવર્ક ઇન્ટરફેસ સાથે જોડે છે. અમે ઈન્ટરફેસ નંબર હાર્ડકોડ કર્યો છે lo, જે હંમેશા 1 હોય છે. જો જૂનો પ્રોગ્રામ જોડાયેલ હોય તો તેને અલગ કરવા માટે અમે બે વાર ફંક્શન ચલાવીએ છીએ. નોંધ લો કે હવે આપણને કોઈ પડકારની જરૂર નથી pause અથવા અનંત લૂપ: અમારો લોડર પ્રોગ્રામ બહાર નીકળી જશે, પરંતુ BPF પ્રોગ્રામને મારવામાં આવશે નહીં કારણ કે તે ઇવેન્ટ સ્ત્રોત સાથે જોડાયેલ છે. સફળ ડાઉનલોડ અને કનેક્શન પછી, પ્રોગ્રામને દરેક નેટવર્ક પેકેટ માટે લોન્ચ કરવામાં આવશે lo.

ચાલો પ્રોગ્રામ ડાઉનલોડ કરીએ અને ઈન્ટરફેસ જોઈએ lo:

$ sudo ./xdp-simple
$ sudo bpftool p | grep simple
669: xdp  name simple  tag 4fca62e77ccb43d6  gpl
$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 669

અમે ડાઉનલોડ કરેલ પ્રોગ્રામમાં ID 669 છે અને અમે ઇન્ટરફેસ પર સમાન ID જોઈએ છીએ lo. અમે કેટલાક પેકેજો મોકલીશું 127.0.0.1 (વિનંતી + જવાબ):

$ ping -c1 localhost

અને હવે ચાલો ડીબગ વર્ચ્યુઅલ ફાઈલની સામગ્રી જોઈએ /sys/kernel/debug/tracing/trace_pipe, જેમાં bpf_printk તેના સંદેશાઓ લખે છે:

# cat /sys/kernel/debug/tracing/trace_pipe
ping-13937 [000] d.s1 442015.377014: bpf_trace_printk: running on CPU0
ping-13937 [000] d.s1 442015.377027: bpf_trace_printk: running on CPU0

બે પેકેજ પર જોવામાં આવ્યા હતા lo અને CPU0 પર પ્રક્રિયા કરી - અમારો પ્રથમ સંપૂર્ણ સુવિધાયુક્ત અર્થહીન BPF પ્રોગ્રામ કામ કરે છે!

તે નોંધવું યોગ્ય છે bpf_printk તે કંઈપણ માટે નથી કે તે ડીબગ ફાઇલ પર લખે છે: ઉત્પાદનમાં ઉપયોગ માટે આ સૌથી સફળ સહાયક નથી, પરંતુ અમારું લક્ષ્ય કંઈક સરળ બતાવવાનું હતું.

BPF પ્રોગ્રામ્સમાંથી નકશા ઍક્સેસ કરી રહ્યાં છે

ઉદાહરણ: BPF પ્રોગ્રામમાંથી નકશાનો ઉપયોગ કરવો

અગાઉના વિભાગોમાં આપણે યુઝર સ્પેસમાંથી નકશા કેવી રીતે બનાવવું અને તેનો ઉપયોગ કરવો તે શીખ્યા, અને હવે ચાલો કર્નલ ભાગ જોઈએ. ચાલો, હંમેશની જેમ, ઉદાહરણ સાથે શરૂ કરીએ. ચાલો આપણા પ્રોગ્રામને ફરીથી લખીએ xdp-simple.bpf.c નીચે પ્રમાણે છે:

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __uint(max_entries, 8);
    __type(key, u32);
    __type(value, u64);
} woo SEC(".maps");

SEC("xdp/simple")
int simple(void *ctx)
{
    u32 key = bpf_get_smp_processor_id();
    u32 *val;

    val = bpf_map_lookup_elem(&woo, &key);
    if (!val)
        return XDP_ABORTED;

    *val += 1;

    return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

પ્રોગ્રામની શરૂઆતમાં અમે નકશાની વ્યાખ્યા ઉમેરી woo: આ એક 8-તત્વ એરે છે જે મૂલ્યોને સંગ્રહિત કરે છે u64 (C માં આપણે આવા એરેને વ્યાખ્યાયિત કરીશું u64 woo[8]). એક કાર્યક્રમમાં "xdp/simple" આપણે વર્તમાન પ્રોસેસર નંબરને વેરીએબલમાં મેળવીએ છીએ key અને પછી હેલ્પર ફંક્શનનો ઉપયોગ કરીને bpf_map_lookup_element આપણને એરેમાં અનુરૂપ એન્ટ્રી માટે પોઇન્ટર મળે છે, જેને આપણે એક વડે વધારીએ છીએ. રશિયનમાં અનુવાદિત: અમે આંકડાઓની ગણતરી કરીએ છીએ કે જેના પર CPU ઇનકમિંગ પેકેટ પર પ્રક્રિયા કરે છે. ચાલો પ્રોગ્રામ ચલાવવાનો પ્રયાસ કરીએ:

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o
$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h
$ clang -O2 -g -I ./libbpf/src/root/usr/include/ -o xdp-simple xdp-simple.c ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz
$ sudo ./xdp-simple

ચાલો તપાસીએ કે તેણી સાથે જોડાયેલી છે lo અને કેટલાક પેકેટો મોકલો:

$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 108

$ for s in `seq 234`; do sudo ping -f -c 100 127.0.0.1 >/dev/null 2>&1; done

હવે ચાલો એરેની સામગ્રી જોઈએ:

$ sudo bpftool map dump name woo
[
    { "key": 0, "value": 0 },
    { "key": 1, "value": 400 },
    { "key": 2, "value": 0 },
    { "key": 3, "value": 0 },
    { "key": 4, "value": 0 },
    { "key": 5, "value": 0 },
    { "key": 6, "value": 0 },
    { "key": 7, "value": 46400 }
]

લગભગ તમામ પ્રક્રિયાઓ CPU7 પર પ્રક્રિયા કરવામાં આવી હતી. આ અમારા માટે મહત્વપૂર્ણ નથી, મુખ્ય વસ્તુ એ છે કે પ્રોગ્રામ કાર્ય કરે છે અને અમે સમજીએ છીએ કે BPF પ્રોગ્રામ્સમાંથી નકશા કેવી રીતે ઍક્સેસ કરવા - ઉપયોગ કરીને хелперов bpf_mp_*.

રહસ્યવાદી અનુક્રમણિકા

તેથી, અમે કૉલ્સનો ઉપયોગ કરીને BPF પ્રોગ્રામમાંથી નકશાને ઍક્સેસ કરી શકીએ છીએ

val = bpf_map_lookup_elem(&woo, &key);

જ્યાં હેલ્પર ફંક્શન જેવું દેખાય છે

void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)

પરંતુ અમે એક નિર્દેશક પસાર કરી રહ્યા છીએ &woo એક અનામી રચના માટે struct { ... }...

જો આપણે પ્રોગ્રામ એસેમ્બલરને જોઈએ, તો આપણે જોઈએ છીએ કે મૂલ્ય &woo વાસ્તવમાં વ્યાખ્યાયિત નથી (લાઇન 4):

llvm-objdump -D --section xdp/simple xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0
       2:       bf a2 00 00 00 00 00 00 r2 = r10
       3:       07 02 00 00 fc ff ff ff r2 += -4
       4:       18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
       6:       85 00 00 00 01 00 00 00 call 1
...

અને સ્થાનાંતરણમાં સમાયેલ છે:

$ llvm-readelf -r xdp-simple.bpf.o | head -4

Relocation section '.relxdp/simple' at offset 0xe18 contains 1 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name
0000000000000020  0000002700000001 R_BPF_64_64            0000000000000000 woo

પરંતુ જો આપણે પહેલાથી જ લોડ થયેલ પ્રોગ્રામને જોઈએ, તો આપણને સાચા નકશા (લાઈન 4) માટે એક નિર્દેશક દેખાય છે:

$ sudo bpftool prog dump x name simple
int simple(void *ctx):
   0: (85) call bpf_get_smp_processor_id#114128
   1: (63) *(u32 *)(r10 -4) = r0
   2: (bf) r2 = r10
   3: (07) r2 += -4
   4: (18) r1 = map[id:64]
...

આમ, અમે નિષ્કર્ષ પર આવી શકીએ છીએ કે અમારો લોડર પ્રોગ્રામ લોંચ કરતી વખતે, તેની લિંક &woo પુસ્તકાલય સાથે કંઈક દ્વારા બદલવામાં આવ્યું હતું libbpf. પહેલા આપણે આઉટપુટ જોઈશું strace:

$ sudo strace -e bpf ./xdp-simple
...
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, key_size=4, value_size=8, max_entries=8, map_name="woo", ...}, 120) = 4
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, prog_name="simple", ...}, 120) = 5

તે આપણે જોઈએ છીએ libbpf નકશો બનાવ્યો woo અને પછી અમારો પ્રોગ્રામ ડાઉનલોડ કર્યો simple. ચાલો આપણે પ્રોગ્રામ કેવી રીતે લોડ કરીએ છીએ તેના પર નજીકથી નજર કરીએ:

• કૉલ xdp_simple_bpf__open_and_load ફાઇલમાંથી xdp-simple.skel.h
• જેનું કારણ બને છે xdp_simple_bpf__load ફાઇલમાંથી xdp-simple.skel.h
• જેનું કારણ બને છે bpf_object__load_skeleton ફાઇલમાંથી libbpf/src/libbpf.c
• જેનું કારણ બને છે bpf_object__load_xattr થી libbpf/src/libbpf.c

છેલ્લું કાર્ય, અન્ય વસ્તુઓની વચ્ચે, કૉલ કરશે bpf_object__create_maps, જે હાલના નકશા બનાવે છે અથવા ખોલે છે, તેમને ફાઇલ વર્ણનકર્તાઓમાં ફેરવે છે. (આ તે છે જ્યાં આપણે જોઈએ છીએ BPF_MAP_CREATE આઉટપુટ માં strace.) આગળ ફંક્શન કહેવામાં આવે છે bpf_object__relocate અને તે તે છે જે અમને રસ ધરાવે છે, કારણ કે અમે જે જોયું તે અમને યાદ છે woo સ્થાનાંતરણ કોષ્ટકમાં. તેનું અન્વેષણ કરીને, આપણે આખરે પોતાને કાર્યમાં શોધીએ છીએ bpf_program__relocate, જે નકશા સ્થાનાંતરણ સાથે વ્યવહાર કરે છે:

case RELO_LD64:
    insn[0].src_reg = BPF_PSEUDO_MAP_FD;
    insn[0].imm = obj->maps[relo->map_idx].fd;
    break;

તેથી અમે અમારી સૂચનાઓ લઈએ છીએ

18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll

અને તેમાં સોર્સ રજિસ્ટર બદલો BPF_PSEUDO_MAP_FD, અને અમારા નકશાના ફાઇલ વર્ણનકર્તામાં પ્રથમ IMM અને, જો તે સમાન હોય, ઉદાહરણ તરીકે, 0xdeadbeef, પછી પરિણામે અમને સૂચના પ્રાપ્ત થશે

18 11 00 00 ef eb ad de 00 00 00 00 00 00 00 00 r1 = 0 ll

આ રીતે નકશાની માહિતી ચોક્કસ લોડ કરેલા BPF પ્રોગ્રામમાં ટ્રાન્સફર થાય છે. આ કિસ્સામાં, નકશાનો ઉપયોગ કરીને બનાવી શકાય છે BPF_MAP_CREATE, અને ID નો ઉપયોગ કરીને ખોલવામાં આવે છે BPF_MAP_GET_FD_BY_ID.

કુલ, ઉપયોગ કરતી વખતે libbpf અલ્ગોરિધમ નીચે મુજબ છે:

• સંકલન દરમિયાન, નકશાની લિંક્સ માટે રિલોકેશન ટેબલમાં રેકોર્ડ બનાવવામાં આવે છે
• libbpf ELF ઑબ્જેક્ટ બુક ખોલે છે, બધા વપરાયેલ નકશા શોધે છે અને તેમના માટે ફાઇલ વર્ણનકર્તા બનાવે છે
• સૂચનાના ભાગરૂપે ફાઇલ વર્ણનકર્તા કર્નલમાં લોડ થાય છે LD64

જેમ તમે કલ્પના કરી શકો છો, ત્યાં ઘણું બધું આવવાનું છે અને આપણે મૂળમાં જોવું પડશે. સદનસીબે, અમારી પાસે એક ચાવી છે - અમે અર્થ લખ્યો છે BPF_PSEUDO_MAP_FD સ્ત્રોત રજિસ્ટરમાં અને અમે તેને દફનાવી શકીએ છીએ, જે આપણને બધા સંતોના પવિત્ર તરફ દોરી જશે - kernel/bpf/verifier.c, જ્યાં વિશિષ્ટ નામ સાથેનું ફંક્શન ફાઇલ ડિસ્ક્રીપ્ટરને ટાઈપના સ્ટ્રક્ચરના એડ્રેસ સાથે બદલે છે struct bpf_map:

static int replace_map_fd_with_map_ptr(struct bpf_verifier_env *env) {
    ...

    f = fdget(insn[0].imm);
    map = __bpf_map_get(f);
    if (insn->src_reg == BPF_PSEUDO_MAP_FD) {
        addr = (unsigned long)map;
    }
    insn[0].imm = (u32)addr;
    insn[1].imm = addr >> 32;

(સંપૂર્ણ કોડ મળી શકે છે લિંક). તેથી અમે અમારા અલ્ગોરિધમનો વિસ્તાર કરી શકીએ છીએ:

• પ્રોગ્રામ લોડ કરતી વખતે, વેરિફાયર નકશાનો સાચો ઉપયોગ તપાસે છે અને અનુરૂપ બંધારણનું સરનામું લખે છે struct bpf_map

ઉપયોગ કરીને ELF બાઈનરી ડાઉનલોડ કરતી વખતે libbpf ત્યાં ઘણું બધું ચાલી રહ્યું છે, પરંતુ અમે અન્ય લેખોમાં તેની ચર્ચા કરીશું.

libbpf વિના પ્રોગ્રામ્સ અને નકશા લોડ કરી રહ્યું છે

વચન મુજબ, અહીં એવા વાચકો માટે એક ઉદાહરણ છે કે જેઓ મદદ વગર નકશાનો ઉપયોગ કરતા પ્રોગ્રામ કેવી રીતે બનાવવો અને લોડ કરવા તે જાણવા માગે છે. libbpf. જ્યારે તમે એવા વાતાવરણમાં કામ કરી રહ્યાં હોવ કે જેના માટે તમે નિર્ભરતા ન બનાવી શકો, અથવા દરેક થોડી બચત કરી શકો, અથવા પ્રોગ્રામ લખી શકો ત્યારે આ ઉપયોગી થઈ શકે છે. ply, જે ફ્લાય પર BPF બાઈનરી કોડ જનરેટ કરે છે.

તર્કને અનુસરવાનું સરળ બનાવવા માટે, અમે આ હેતુઓ માટે અમારા ઉદાહરણને ફરીથી લખીશું xdp-simple. આ ઉદાહરણમાં ચર્ચા કરેલ પ્રોગ્રામનો સંપૂર્ણ અને થોડો વિસ્તૃત કોડ આમાં મળી શકે છે ભાવાર્થ.

અમારી અરજીનો તર્ક નીચે મુજબ છે:

• એક પ્રકારનો નકશો બનાવો BPF_MAP_TYPE_ARRAY આદેશનો ઉપયોગ કરીને BPF_MAP_CREATE,
• એક પ્રોગ્રામ બનાવો જે આ નકશાનો ઉપયોગ કરે છે,
• પ્રોગ્રામને ઇન્ટરફેસથી કનેક્ટ કરો lo,

જે માનવમાં ભાષાંતર કરે છે

int main(void)
{
    int map_fd, prog_fd;

    map_fd = map_create();
    if (map_fd < 0)
        err(1, "bpf: BPF_MAP_CREATE");

    prog_fd = prog_load(map_fd);
    if (prog_fd < 0)
        err(1, "bpf: BPF_PROG_LOAD");

    xdp_attach(1, prog_fd);
}

તે map_create સિસ્ટમ કૉલ વિશે આપણે પ્રથમ ઉદાહરણમાં કર્યું તે જ રીતે નકશો બનાવે છે bpf - “કર્નલ, કૃપા કરીને મને 8 તત્વોની એરેના રૂપમાં નવો નકશો બનાવો __u64 અને મને ફાઈલ વર્ણનકર્તા પાછું આપો":

static int map_create()
{
    union bpf_attr attr;

    memset(&attr, 0, sizeof(attr));
    attr.map_type = BPF_MAP_TYPE_ARRAY,
    attr.key_size = sizeof(__u32),
    attr.value_size = sizeof(__u64),
    attr.max_entries = 8,
    strncpy(attr.map_name, "woo", sizeof(attr.map_name));
    return syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));
}

પ્રોગ્રામ લોડ કરવા માટે પણ સરળ છે:

static int prog_load(int map_fd)
{
    union bpf_attr attr;
    struct bpf_insn insns[] = {
        ...
    };

    memset(&attr, 0, sizeof(attr));
    attr.prog_type = BPF_PROG_TYPE_XDP;
    attr.insns     = ptr_to_u64(insns);
    attr.insn_cnt  = sizeof(insns)/sizeof(insns[0]);
    attr.license   = ptr_to_u64("GPL");
    strncpy(attr.prog_name, "woo", sizeof(attr.prog_name));
    return syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));
}

મુશ્કેલ ભાગ prog_load માળખાઓની શ્રેણી તરીકે અમારા BPF પ્રોગ્રામની વ્યાખ્યા છે struct bpf_insn insns[]. પરંતુ અમે C માં છે તે પ્રોગ્રામનો ઉપયોગ કરી રહ્યા હોવાથી, અમે થોડી છેતરપિંડી કરી શકીએ છીએ:

$ llvm-objdump -D --section xdp/simple xdp-simple.bpf.o

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0
       2:       bf a2 00 00 00 00 00 00 r2 = r10
       3:       07 02 00 00 fc ff ff ff r2 += -4
       4:       18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
       6:       85 00 00 00 01 00 00 00 call 1
       7:       b7 01 00 00 00 00 00 00 r1 = 0
       8:       15 00 04 00 00 00 00 00 if r0 == 0 goto +4 <LBB0_2>
       9:       61 01 00 00 00 00 00 00 r1 = *(u32 *)(r0 + 0)
      10:       07 01 00 00 01 00 00 00 r1 += 1
      11:       63 10 00 00 00 00 00 00 *(u32 *)(r0 + 0) = r1
      12:       b7 01 00 00 02 00 00 00 r1 = 2

0000000000000068 <LBB0_2>:
      13:       bf 10 00 00 00 00 00 00 r0 = r1
      14:       95 00 00 00 00 00 00 00 exit

કુલ મળીને, આપણે 14 સૂચનાઓ જેવી રચનાઓના સ્વરૂપમાં લખવાની જરૂર છે struct bpf_insn (સલાહ: ઉપરથી ડમ્પ લો, સૂચના વિભાગને ફરીથી વાંચો, ખોલો linux/bpf.h и linux/bpf_common.h અને નક્કી કરવાનો પ્રયાસ કરો struct bpf_insn insns[] પોતાના પર):

struct bpf_insn insns[] = {
    /* 85 00 00 00 08 00 00 00 call 8 */
    {
        .code = BPF_JMP | BPF_CALL,
        .imm = 8,
    },

    /* 63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0 */
    {
        .code = BPF_MEM | BPF_STX,
        .off = -4,
        .src_reg = BPF_REG_0,
        .dst_reg = BPF_REG_10,
    },

    /* bf a2 00 00 00 00 00 00 r2 = r10 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_X,
        .src_reg = BPF_REG_10,
        .dst_reg = BPF_REG_2,
    },

    /* 07 02 00 00 fc ff ff ff r2 += -4 */
    {
        .code = BPF_ALU64 | BPF_ADD | BPF_K,
        .dst_reg = BPF_REG_2,
        .imm = -4,
    },

    /* 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll */
    {
        .code = BPF_LD | BPF_DW | BPF_IMM,
        .src_reg = BPF_PSEUDO_MAP_FD,
        .dst_reg = BPF_REG_1,
        .imm = map_fd,
    },
    { }, /* placeholder */

    /* 85 00 00 00 01 00 00 00 call 1 */
    {
        .code = BPF_JMP | BPF_CALL,
        .imm = 1,
    },

    /* b7 01 00 00 00 00 00 00 r1 = 0 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 0,
    },

    /* 15 00 04 00 00 00 00 00 if r0 == 0 goto +4 <LBB0_2> */
    {
        .code = BPF_JMP | BPF_JEQ | BPF_K,
        .off = 4,
        .src_reg = BPF_REG_0,
        .imm = 0,
    },

    /* 61 01 00 00 00 00 00 00 r1 = *(u32 *)(r0 + 0) */
    {
        .code = BPF_MEM | BPF_LDX,
        .off = 0,
        .src_reg = BPF_REG_0,
        .dst_reg = BPF_REG_1,
    },

    /* 07 01 00 00 01 00 00 00 r1 += 1 */
    {
        .code = BPF_ALU64 | BPF_ADD | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 1,
    },

    /* 63 10 00 00 00 00 00 00 *(u32 *)(r0 + 0) = r1 */
    {
        .code = BPF_MEM | BPF_STX,
        .src_reg = BPF_REG_1,
        .dst_reg = BPF_REG_0,
    },

    /* b7 01 00 00 02 00 00 00 r1 = 2 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 2,
    },

    /* <LBB0_2>: bf 10 00 00 00 00 00 00 r0 = r1 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_X,
        .src_reg = BPF_REG_1,
        .dst_reg = BPF_REG_0,
    },

    /* 95 00 00 00 00 00 00 00 exit */
    {
        .code = BPF_JMP | BPF_EXIT
    },
};

જેમણે આ જાતે લખ્યું નથી તેમના માટે એક કવાયત - શોધો map_fd.

અમારા પ્રોગ્રામમાં એક વધુ અપ્રગટ ભાગ બાકી છે - xdp_attach. કમનસીબે, XDP જેવા પ્રોગ્રામ્સને સિસ્ટમ કૉલનો ઉપયોગ કરીને કનેક્ટ કરી શકાતા નથી bpf. જે લોકો BPF અને XDP બનાવતા હતા તેઓ ઓનલાઈન Linux સમુદાયમાંથી હતા, જેનો અર્થ છે કે તેઓ તેમના માટે સૌથી વધુ પરિચિત હતા (પરંતુ નહીં સામાન્ય લોકો) કર્નલ સાથે ક્રિયાપ્રતિક્રિયા માટે ઇન્ટરફેસ: નેટલિંક સોકેટ્સ, આ પણ જુઓ આરએફસી 3549. અમલ કરવાની સૌથી સરળ રીત xdp_attach થી કોડ કોપી કરી રહ્યા છે libbpf, એટલે કે, ફાઇલમાંથી netlink.c, જે અમે કર્યું છે, તેને થોડું ટૂંકું કરીને:

નેટલિંક સોકેટ્સની દુનિયામાં આપનું સ્વાગત છે

નેટલિંક સોકેટ પ્રકાર ખોલો NETLINK_ROUTE:

int netlink_open(__u32 *nl_pid)
{
    struct sockaddr_nl sa;
    socklen_t addrlen;
    int one = 1, ret;
    int sock;

    memset(&sa, 0, sizeof(sa));
    sa.nl_family = AF_NETLINK;

    sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
    if (sock < 0)
        err(1, "socket");

    if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK, &one, sizeof(one)) < 0)
        warnx("netlink error reporting not supported");

    if (bind(sock, (struct sockaddr *)&sa, sizeof(sa)) < 0)
        err(1, "bind");

    addrlen = sizeof(sa);
    if (getsockname(sock, (struct sockaddr *)&sa, &addrlen) < 0)
        err(1, "getsockname");

    *nl_pid = sa.nl_pid;
    return sock;
}

અમે આ સોકેટમાંથી વાંચીએ છીએ:

static int bpf_netlink_recv(int sock, __u32 nl_pid, int seq)
{
    bool multipart = true;
    struct nlmsgerr *errm;
    struct nlmsghdr *nh;
    char buf[4096];
    int len, ret;

    while (multipart) {
        multipart = false;
        len = recv(sock, buf, sizeof(buf), 0);
        if (len < 0)
            err(1, "recv");

        if (len == 0)
            break;

        for (nh = (struct nlmsghdr *)buf; NLMSG_OK(nh, len);
                nh = NLMSG_NEXT(nh, len)) {
            if (nh->nlmsg_pid != nl_pid)
                errx(1, "wrong pid");
            if (nh->nlmsg_seq != seq)
                errx(1, "INVSEQ");
            if (nh->nlmsg_flags & NLM_F_MULTI)
                multipart = true;
            switch (nh->nlmsg_type) {
                case NLMSG_ERROR:
                    errm = (struct nlmsgerr *)NLMSG_DATA(nh);
                    if (!errm->error)
                        continue;
                    ret = errm->error;
                    // libbpf_nla_dump_errormsg(nh); too many code to copy...
                    goto done;
                case NLMSG_DONE:
                    return 0;
                default:
                    break;
            }
        }
    }
    ret = 0;
done:
    return ret;
}

છેલ્લે, અહીં અમારું કાર્ય છે જે સોકેટ ખોલે છે અને તેને ફાઇલ વર્ણનકર્તા ધરાવતો વિશિષ્ટ સંદેશ મોકલે છે:

static int xdp_attach(int ifindex, int prog_fd)
{
    int sock, seq = 0, ret;
    struct nlattr *nla, *nla_xdp;
    struct {
        struct nlmsghdr  nh;
        struct ifinfomsg ifinfo;
        char             attrbuf[64];
    } req;
    __u32 nl_pid = 0;

    sock = netlink_open(&nl_pid);
    if (sock < 0)
        return sock;

    memset(&req, 0, sizeof(req));
    req.nh.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
    req.nh.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
    req.nh.nlmsg_type = RTM_SETLINK;
    req.nh.nlmsg_pid = 0;
    req.nh.nlmsg_seq = ++seq;
    req.ifinfo.ifi_family = AF_UNSPEC;
    req.ifinfo.ifi_index = ifindex;

    /* started nested attribute for XDP */
    nla = (struct nlattr *)(((char *)&req)
            + NLMSG_ALIGN(req.nh.nlmsg_len));
    nla->nla_type = NLA_F_NESTED | IFLA_XDP;
    nla->nla_len = NLA_HDRLEN;

    /* add XDP fd */
    nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
    nla_xdp->nla_type = IFLA_XDP_FD;
    nla_xdp->nla_len = NLA_HDRLEN + sizeof(int);
    memcpy((char *)nla_xdp + NLA_HDRLEN, &prog_fd, sizeof(prog_fd));
    nla->nla_len += nla_xdp->nla_len;

    /* if user passed in any flags, add those too */
    __u32 flags = XDP_FLAGS_SKB_MODE;
    nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
    nla_xdp->nla_type = IFLA_XDP_FLAGS;
    nla_xdp->nla_len = NLA_HDRLEN + sizeof(flags);
    memcpy((char *)nla_xdp + NLA_HDRLEN, &flags, sizeof(flags));
    nla->nla_len += nla_xdp->nla_len;

    req.nh.nlmsg_len += NLA_ALIGN(nla->nla_len);

    if (send(sock, &req, req.nh.nlmsg_len, 0) < 0)
        err(1, "send");
    ret = bpf_netlink_recv(sock, nl_pid, seq);

cleanup:
    close(sock);
    return ret;
}

તેથી, બધું પરીક્ષણ માટે તૈયાર છે:

$ cc nolibbpf.c -o nolibbpf
$ sudo strace -e bpf ./nolibbpf
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, map_name="woo", ...}, 72) = 3
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=15, prog_name="woo", ...}, 72) = 4
+++ exited with 0 +++

ચાલો જોઈએ કે અમારો પ્રોગ્રામ કનેક્ટ થયો છે કે નહીં lo:

$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 160

ચાલો પિંગ્સ મોકલીએ અને નકશો જોઈએ:

$ for s in `seq 234`; do sudo ping -f -c 100 127.0.0.1 >/dev/null 2>&1; done
$ sudo bpftool m dump name woo
key: 00 00 00 00  value: 90 01 00 00 00 00 00 00
key: 01 00 00 00  value: 00 00 00 00 00 00 00 00
key: 02 00 00 00  value: 00 00 00 00 00 00 00 00
key: 03 00 00 00  value: 00 00 00 00 00 00 00 00
key: 04 00 00 00  value: 00 00 00 00 00 00 00 00
key: 05 00 00 00  value: 00 00 00 00 00 00 00 00
key: 06 00 00 00  value: 40 b5 00 00 00 00 00 00
key: 07 00 00 00  value: 00 00 00 00 00 00 00 00
Found 8 elements

હુરે, બધું કામ કરે છે. નોંધ કરો, માર્ગ દ્વારા, અમારો નકશો ફરીથી બાઈટના રૂપમાં પ્રદર્શિત થાય છે. આ એ હકીકતને કારણે છે કે, વિપરીત libbpf અમે પ્રકાર માહિતી (BTF) લોડ કરી નથી. પરંતુ અમે આગલી વખતે આ વિશે વધુ વાત કરીશું.

વિકાસ સાધનો

આ વિભાગમાં, અમે ન્યૂનતમ BPF ડેવલપર ટૂલકીટ જોઈશું.

સામાન્ય રીતે કહીએ તો, તમારે BPF પ્રોગ્રામ્સ વિકસાવવા માટે ખાસ કંઈપણની જરૂર નથી - BPF કોઈપણ યોગ્ય વિતરણ કર્નલ પર ચાલે છે, અને પ્રોગ્રામ્સનો ઉપયોગ કરીને બનાવવામાં આવે છે clang, જે પેકેજમાંથી સપ્લાય કરી શકાય છે. જો કે, BPF વિકાસ હેઠળ છે તે હકીકતને કારણે, કર્નલ અને ટૂલ્સ સતત બદલાતા રહે છે, જો તમે 2019 થી જૂના જમાનાની પદ્ધતિઓનો ઉપયોગ કરીને BPF પ્રોગ્રામ્સ લખવા માંગતા નથી, તો તમારે કમ્પાઇલ કરવું પડશે.

• llvm/clang
• pahole
• તેનો મુખ્ય ભાગ
• bpftool

(સંદર્ભ માટે, આ વિભાગ અને લેખના તમામ ઉદાહરણો ડેબિયન 10 પર ચલાવવામાં આવ્યા હતા.)

llvm/clang

BPF LLVM સાથે મૈત્રીપૂર્ણ છે અને, જો કે તાજેતરમાં BPF માટેના કાર્યક્રમો gcc નો ઉપયોગ કરીને સંકલિત કરી શકાય છે, તમામ વર્તમાન વિકાસ એલએલવીએમ માટે કરવામાં આવે છે. તેથી, સૌ પ્રથમ, અમે વર્તમાન સંસ્કરણ બનાવીશું clang ગિટમાંથી:

$ sudo apt install ninja-build
$ git clone --depth 1 https://github.com/llvm/llvm-project.git
$ mkdir -p llvm-project/llvm/build/install
$ cd llvm-project/llvm/build
$ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" 
                      -DLLVM_ENABLE_PROJECTS="clang" 
                      -DBUILD_SHARED_LIBS=OFF 
                      -DCMAKE_BUILD_TYPE=Release 
                      -DLLVM_BUILD_RUNTIME=OFF
$ time ninja
... много времени спустя
$

હવે આપણે ચકાસી શકીએ છીએ કે બધું બરાબર એકસાથે આવ્યું છે કે કેમ:

$ ./bin/llc --version
LLVM (http://llvm.org/):
  LLVM version 11.0.0git
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver1

  Registered Targets:
    bpf    - BPF (host endian)
    bpfeb  - BPF (big endian)
    bpfel  - BPF (little endian)
    x86    - 32-bit X86: Pentium-Pro and above
    x86-64 - 64-bit X86: EM64T and AMD64

(એસેમ્બલી સૂચનાઓ clang મારા દ્વારા લેવામાં આવેલ છે bpf_devel_QA.)

અમે હમણાં જ બનાવેલા પ્રોગ્રામ્સને ઇન્સ્ટોલ કરીશું નહીં, પરંતુ તેના બદલે ફક્ત તેમાં ઉમેરો PATH, ઉદાહરણ તરીકે:

export PATH="`pwd`/bin:$PATH"

(આમાં ઉમેરી શકાય છે .bashrc અથવા અલગ ફાઇલમાં. અંગત રીતે, હું આના જેવી વસ્તુઓ ઉમેરું છું ~/bin/activate-llvm.sh અને જ્યારે જરૂરી હોય ત્યારે હું તે કરું છું . activate-llvm.sh.)

Pahole અને BTF

ઉપયોગિતા pahole BTF ફોર્મેટમાં ડીબગીંગ માહિતી બનાવવા માટે કર્નલ બનાવતી વખતે વપરાય છે. અમે આ લેખમાં BTF તકનીકની વિગતો વિશે વિગતવાર જઈશું નહીં, તે હકીકત સિવાય કે તે અનુકૂળ છે અને અમે તેનો ઉપયોગ કરવા માંગીએ છીએ. તેથી જો તમે તમારી કર્નલ બનાવવા જઈ રહ્યા છો, તો પહેલા બનાવો pahole (વગર pahole તમે વિકલ્પ સાથે કર્નલ બનાવી શકશો નહીં CONFIG_DEBUG_INFO_BTF:

$ git clone https://git.kernel.org/pub/scm/devel/pahole/pahole.git
$ cd pahole/
$ sudo apt install cmake
$ mkdir build
$ cd build/
$ cmake -D__LIB=lib ..
$ make
$ sudo make install
$ which pahole
/usr/local/bin/pahole

BPF સાથે પ્રયોગ કરવા માટે કર્નલ્સ

BPF ની શક્યતાઓ શોધતી વખતે, હું મારા પોતાના કોર એસેમ્બલ કરવા માંગુ છું. સામાન્ય રીતે કહીએ તો, આ જરૂરી નથી, કારણ કે તમે વિતરણ કર્નલ પર BPF પ્રોગ્રામ્સ કમ્પાઇલ અને લોડ કરી શકશો, જો કે, તમારી પોતાની કર્નલ રાખવાથી તમે નવીનતમ BPF સુવિધાઓનો ઉપયોગ કરી શકશો, જે તમારા વિતરણમાં મહિનામાં શ્રેષ્ઠ રીતે દેખાશે. , અથવા, કેટલાક ડિબગીંગ ટૂલ્સના કિસ્સામાં નજીકના ભવિષ્યમાં બિલકુલ પેકેજ કરવામાં આવશે નહીં. ઉપરાંત, તેનો પોતાનો કોર કોડ સાથે પ્રયોગ કરવાનું મહત્વપૂર્ણ લાગે છે.

કર્નલ બનાવવા માટે તમારે પ્રથમ, કર્નલ પોતે, અને બીજું, કર્નલ રૂપરેખાંકન ફાઇલની જરૂર છે. BPF સાથે પ્રયોગ કરવા માટે આપણે સામાન્યનો ઉપયોગ કરી શકીએ છીએ વેનીલા કર્નલ અથવા વિકાસ કર્નલમાંથી એક. ઐતિહાસિક રીતે, BPF ડેવલપમેન્ટ Linux નેટવર્કિંગ સમુદાયમાં થાય છે અને તેથી બધા ફેરફારો વહેલા કે પછી લિનક્સ નેટવર્કિંગ જાળવણીકાર ડેવિડ મિલર દ્વારા થાય છે. તેમના સ્વભાવના આધારે - સંપાદનો અથવા નવી સુવિધાઓ - નેટવર્ક ફેરફારો બેમાંથી એકમાં આવે છે - net અથવા net-next. BPF માટેના ફેરફારો વચ્ચે સમાન રીતે વહેંચવામાં આવે છે bpf и bpf-next, જે પછી અનુક્રમે નેટ અને નેક્સ્ટ-નેક્સ્ટમાં પૂલ કરવામાં આવે છે. વધુ વિગતો માટે, જુઓ bpf_devel_QA и netdev-FAQ. તેથી તમારા સ્વાદ અને તમે જે સિસ્ટમનું પરીક્ષણ કરી રહ્યાં છો તેની સ્થિરતા જરૂરિયાતોને આધારે કર્નલ પસંદ કરો (*-next કર્નલો સૂચિબદ્ધ તેમાંથી સૌથી અસ્થિર છે).

કર્નલ રૂપરેખાંકન ફાઇલોનું સંચાલન કેવી રીતે કરવું તે વિશે વાત કરવી આ લેખના અવકાશની બહાર છે - એવું માનવામાં આવે છે કે તમે આ કેવી રીતે કરવું તે પહેલાથી જ જાણો છો, અથવા શીખવા માટે તૈયાર પોતાના પર. જો કે, નીચેની સૂચનાઓ તમને કાર્યરત BPF-સક્ષમ સિસ્ટમ આપવા માટે પર્યાપ્ત અથવા ઓછી હોવી જોઈએ.

ઉપરોક્ત કર્નલોમાંથી એક ડાઉનલોડ કરો:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
$ cd bpf-next

ન્યૂનતમ કાર્યકારી કર્નલ રૂપરેખા બનાવો:

$ cp /boot/config-`uname -r` .config
$ make localmodconfig

ફાઇલમાં BPF વિકલ્પો સક્ષમ કરો .config તમારી પોતાની પસંદગી (મોટા ભાગે CONFIG_BPF પહેલાથી જ સક્ષમ હશે કારણ કે systemd તેનો ઉપયોગ કરે છે). આ લેખ માટે ઉપયોગમાં લેવાતા કર્નલમાંથી વિકલ્પોની સૂચિ અહીં છે:

CONFIG_CGROUP_BPF=y
CONFIG_BPF=y
CONFIG_BPF_LSM=y
CONFIG_BPF_SYSCALL=y
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_BPF_JIT_DEFAULT_ON=y
CONFIG_IPV6_SEG6_BPF=y
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_BPFILTER is not set
CONFIG_NET_CLS_BPF=y
CONFIG_NET_ACT_BPF=y
CONFIG_BPF_JIT=y
CONFIG_BPF_STREAM_PARSER=y
CONFIG_LWTUNNEL_BPF=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_BPF_EVENTS=y
CONFIG_BPF_KPROBE_OVERRIDE=y
CONFIG_DEBUG_INFO_BTF=y

પછી આપણે મોડ્યુલો અને કર્નલને સરળતાથી એસેમ્બલ અને ઇન્સ્ટોલ કરી શકીએ છીએ (માર્ગ દ્વારા, તમે નવા એસેમ્બલનો ઉપયોગ કરીને કર્નલને એસેમ્બલ કરી શકો છો. clangઉમેરીને CC=clang):

$ make -s -j $(getconf _NPROCESSORS_ONLN)
$ sudo make modules_install
$ sudo make install

અને નવા કર્નલ સાથે રીબૂટ કરો (હું આ માટે ઉપયોગ કરું છું kexec પેકેજમાંથી kexec-tools):

v=5.8.0-rc6+ # если вы пересобираете текущее ядро, то можно делать v=`uname -r`
sudo kexec -l -t bzImage /boot/vmlinuz-$v --initrd=/boot/initrd.img-$v --reuse-cmdline &&
sudo kexec -e

bpftool

લેખમાં સૌથી વધુ ઉપયોગમાં લેવાતી યુટિલિટી હશે bpftool, Linux કર્નલના ભાગ રૂપે પૂરું પાડવામાં આવે છે. તે BPF વિકાસકર્તાઓ માટે BPF વિકાસકર્તાઓ દ્વારા લખવામાં અને જાળવવામાં આવે છે અને તેનો ઉપયોગ તમામ પ્રકારના BPF ઑબ્જેક્ટ્સ - લોડ પ્રોગ્રામ્સ, નકશા બનાવવા અને સંપાદિત કરવા, BPF ઇકોસિસ્ટમના જીવનનું અન્વેષણ કરવા વગેરે માટે કરી શકાય છે. મેન પેજ માટે સ્ત્રોત કોડના રૂપમાં દસ્તાવેજીકરણ મળી શકે છે કોર માં અથવા, પહેલેથી જ સંકલિત, નેટ પર.

આ લેખન સમયે bpftool ફક્ત RHEL, Fedora અને Ubuntu માટે જ તૈયાર આવે છે (જુઓ, ઉદાહરણ તરીકે, આ થ્રેડ, જે પેકેજીંગની અધૂરી વાર્તા કહે છે bpftool ડેબિયનમાં). પરંતુ જો તમે તમારી કર્નલ પહેલેથી જ બનાવી છે, તો પછી બનાવો bpftool પાઇ જેટલું સરળ:

$ cd ${linux}/tools/bpf/bpftool
# ... пропишите пути к последнему clang, как рассказано выше
$ make -s

Auto-detecting system features:
...                        libbfd: [ on  ]
...        disassembler-four-args: [ on  ]
...                          zlib: [ on  ]
...                        libcap: [ on  ]
...               clang-bpf-co-re: [ on  ]

Auto-detecting system features:
...                        libelf: [ on  ]
...                          zlib: [ on  ]
...                           bpf: [ on  ]

$

(અહીં ${linux} - આ તમારી કર્નલ ડિરેક્ટરી છે.) આ આદેશો ચલાવ્યા પછી bpftool ડિરેક્ટરીમાં એકત્રિત કરવામાં આવશે ${linux}/tools/bpf/bpftool અને તેને પાથમાં ઉમેરી શકાય છે (સૌ પ્રથમ વપરાશકર્તા માટે root) અથવા ફક્ત કોપી કરો /usr/local/sbin.

એકત્રિત કરો bpftool પછીનો ઉપયોગ કરવો શ્રેષ્ઠ છે clang, ઉપર વર્ણવ્યા મુજબ એસેમ્બલ, અને તપાસો કે તે યોગ્ય રીતે એસેમ્બલ છે કે કેમ - ઉદાહરણ તરીકે, આદેશનો ઉપયોગ કરીને

$ sudo bpftool feature probe kernel
Scanning system configuration...
bpf() syscall for unprivileged users is enabled
JIT compiler is enabled
JIT compiler hardening is disabled
JIT compiler kallsyms exports are enabled for root
...

જે બતાવશે કે તમારા કર્નલમાં કઈ BPF સુવિધાઓ સક્ષમ છે.

માર્ગ દ્વારા, અગાઉના આદેશ તરીકે ચલાવી શકાય છે

# bpftool f p k

આ પેકેજમાંથી ઉપયોગિતાઓ સાથે સામ્યતા દ્વારા કરવામાં આવે છે iproute2, જ્યાં આપણે, ઉદાહરણ તરીકે, કહી શકીએ ip a s eth0 вместо ip addr show dev eth0.

નિષ્કર્ષ

BPF તમને ચાંચડને અસરકારક રીતે માપવા માટે અને ફ્લાયમાં મુખ્ય કાર્યક્ષમતામાં ફેરફાર કરવા માટે પરવાનગી આપે છે. UNIX ની શ્રેષ્ઠ પરંપરાઓમાં, સિસ્ટમ ખૂબ જ સફળ સાબિત થઈ: એક સરળ પદ્ધતિ જે તમને કર્નલને (ફરીથી) પ્રોગ્રામ કરવાની મંજૂરી આપે છે, જેણે મોટી સંખ્યામાં લોકો અને સંસ્થાઓને પ્રયોગ કરવાની મંજૂરી આપી. અને, તેમ છતાં, પ્રયોગો, તેમજ BPF ઇન્ફ્રાસ્ટ્રક્ચરનો વિકાસ, સમાપ્ત થવાથી દૂર છે, સિસ્ટમમાં પહેલેથી જ એક સ્થિર ABI છે જે તમને વિશ્વસનીય, અને સૌથી અગત્યનું, અસરકારક વ્યવસાયિક તર્ક બનાવવાની મંજૂરી આપે છે.

હું એ નોંધવા માંગુ છું કે, મારા મતે, તકનીક એટલી લોકપ્રિય બની છે કારણ કે, એક તરફ, તે કરી શકે છે રમવા માટે (મશીનનું આર્કિટેક્ચર એક સાંજે વધુ કે ઓછું સમજી શકાય છે), અને બીજી બાજુ, તેના દેખાવ પહેલાં (સુંદર રીતે) હલ ન થઈ શકે તેવી સમસ્યાઓ ઉકેલવા માટે. આ બે ઘટકો એકસાથે લોકોને પ્રયોગ અને સ્વપ્ન જોવા માટે દબાણ કરે છે, જે વધુને વધુ નવીન ઉકેલોના ઉદભવ તરફ દોરી જાય છે.

આ લેખ, ખાસ કરીને ટૂંકો ન હોવા છતાં, માત્ર BPF ની દુનિયાનો પરિચય છે અને "અદ્યતન" સુવિધાઓ અને આર્કિટેક્ચરના મહત્વપૂર્ણ ભાગોનું વર્ણન કરતું નથી. આગળની યોજના કંઈક આના જેવી છે: આગળનો લેખ BPF પ્રોગ્રામ પ્રકારોનું વિહંગાવલોકન હશે (5.8 કર્નલમાં 30 પ્રોગ્રામ પ્રકારો સપોર્ટેડ છે), પછી આપણે આખરે કર્નલ ટ્રેસિંગ પ્રોગ્રામ્સનો ઉપયોગ કરીને વાસ્તવિક BPF એપ્લિકેશન કેવી રીતે લખવી તે જોઈશું. ઉદાહરણ તરીકે, હવે BPF આર્કિટેક્ચર પર વધુ ઊંડાણપૂર્વકના અભ્યાસક્રમ માટેનો સમય છે, ત્યારબાદ BPF નેટવર્કિંગ અને સુરક્ષા એપ્લિકેશનના ઉદાહરણો.

આ શ્રેણીમાં અગાઉના લેખો

1. નાનાઓ માટે BPF, ભાગ શૂન્ય: ક્લાસિક BPF

લિંક્સ

1. BPF અને XDP સંદર્ભ માર્ગદર્શિકા - સીલિયમમાંથી BPF પર દસ્તાવેજીકરણ, અથવા વધુ સ્પષ્ટ રીતે ડેનિયલ બોર્કમેન પાસેથી, જે BPF ના સર્જકો અને જાળવણી કરનારાઓમાંના એક છે. આ પ્રથમ ગંભીર વર્ણનોમાંનું એક છે, જે અન્ય લોકોથી અલગ છે જેમાં ડેનિયલ બરાબર જાણે છે કે તે શું લખી રહ્યો છે અને ત્યાં કોઈ ભૂલો નથી. ખાસ કરીને, આ દસ્તાવેજ જાણીતી ઉપયોગિતાનો ઉપયોગ કરીને XDP અને TC પ્રકારના BPF પ્રોગ્રામ્સ સાથે કેવી રીતે કામ કરવું તેનું વર્ણન કરે છે. ip પેકેજમાંથી iproute2.

2. દસ્તાવેજીકરણ/networking/filter.txt - ક્લાસિક અને પછી વિસ્તૃત BPF માટે દસ્તાવેજીકરણ સાથેની મૂળ ફાઇલ. જો તમે એસેમ્બલી લેંગ્વેજ અને ટેકનિકલ આર્કિટેક્ચરલ વિગતોનો અભ્યાસ કરવા માંગતા હોવ તો સારું વાંચન.

3. ફેસબુક પરથી BPF વિશે બ્લોગ. તે ભાગ્યે જ અપડેટ થાય છે, પરંતુ યોગ્ય રીતે, કારણ કે એલેક્સી સ્ટારોવોઇટોવ (eBPF ના લેખક) અને આન્દ્રી નાક્રિકો - (જાળવણીકાર) ત્યાં લખે છે. libbpf).

4. bpftool ના રહસ્યો. bpftool નો ઉપયોગ કરવાના ઉદાહરણો અને રહસ્યો સાથે ક્વેન્ટિન મોનેટ તરફથી એક મનોરંજક ટ્વિટર થ્રેડ.

5. BPF માં ડાઇવ કરો: વાંચન સામગ્રીની સૂચિ. ક્વેન્ટિન મોનેટ તરફથી BPF દસ્તાવેજીકરણની લિંક્સની વિશાળ (અને હજુ પણ જાળવણી) સૂચિ.

સોર્સ: www.habr.com