സ്‌പെക്‌റ്റർ ആക്രമണങ്ങൾക്കെതിരായ സംരക്ഷണത്തെ മറികടക്കാൻ അനുവദിക്കുന്ന eBPF സബ്‌സിസ്റ്റത്തിലെ കേടുപാടുകൾ

ലിനക്സ് കേർണലിൽ (CVE-2021-33624) ഒരു അപകടസാധ്യത തിരിച്ചറിഞ്ഞിട്ടുണ്ട്, അത് സ്‌പെക്‌റ്റർ ക്ലാസ് കേടുപാടുകൾക്കെതിരെയുള്ള പരിരക്ഷയെ മറികടക്കാൻ eBPF സബ്‌സിസ്റ്റം ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു, ഇത് മെമ്മറിയുടെ ഉള്ളടക്കം നിർണ്ണയിക്കുന്നത് സാധ്യമാക്കുന്നു. ചില പ്രവർത്തനങ്ങളുടെ ഊഹക്കച്ചവടം. സ്‌പെക്‌റ്റർ ആക്രമണത്തിന് പ്രിവിലേജ്ഡ് കോഡിലെ ഒരു നിശ്ചിത ശ്രേണി കമാൻഡുകളുടെ സാന്നിധ്യം ആവശ്യമാണ്, അത് നിർദ്ദേശങ്ങളുടെ ഊഹക്കച്ചവട നിർവ്വഹണത്തിലേക്ക് നയിക്കുന്നു. നിർവ്വഹണത്തിനായി കൈമാറുന്ന BPF പ്രോഗ്രാമുകൾ കൈകാര്യം ചെയ്യുന്നതിലൂടെ, eBPF-ൽ സമാനമായ നിർദ്ദേശങ്ങൾ സൃഷ്ടിക്കാനും കേർണൽ മെമ്മറിയിലെ ഉള്ളടക്കങ്ങളും സൈഡ് ചാനലുകൾ വഴി ഫിസിക്കൽ മെമ്മറിയുടെ അനിയന്ത്രിതമായ മേഖലകളും ചോർത്താനും സാധിക്കും.

BPF പ്രോഗ്രാമുകളിലെ പിശകുകളും അസ്വീകാര്യമായ പ്രവർത്തനങ്ങളും കണ്ടെത്തുന്നതിന് ഉപയോഗിക്കുന്ന വെരിഫയറിലെ പിഴവുകളാണ് ഈ അപകടത്തിന് കാരണം. വെരിഫയർ സാധ്യമായ കോഡ് എക്‌സിക്യൂഷൻ പാതകൾ കണക്കാക്കുന്നു, എന്നാൽ ഇൻസ്ട്രക്ഷൻ സെറ്റ് ആർക്കിടെക്ചറിൻ്റെ സെമാൻ്റിക്‌സിൻ്റെ വീക്ഷണകോണിൽ നിന്ന് അസ്വീകാര്യമായ ബ്രാഞ്ചിംഗ് ഓപ്ഷനുകൾ ഒഴിവാക്കുന്നു. ഒരു ബിപിഎഫ് പ്രോഗ്രാം എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ, വെരിഫയർ കണക്കിലെടുക്കാത്ത അത്തരം ബ്രാഞ്ചിംഗ് ഓപ്ഷനുകൾ പ്രോസസർ വഴി തെറ്റായി പ്രവചിക്കുകയും ഊഹക്കച്ചവട മോഡിൽ നടപ്പിലാക്കുകയും ചെയ്യും. ഉദാഹരണത്തിന്, "ലോഡ്" പ്രവർത്തനം വിശകലനം ചെയ്യുമ്പോൾ, നിർദ്ദേശം നിർദ്ദിഷ്ട പരിധിക്കുള്ളിൽ മൂല്യമുള്ള ഒരു വിലാസമുള്ള ഒരു രജിസ്റ്റർ ഉപയോഗിക്കുമെന്ന് വെരിഫയർ പ്രതീക്ഷിക്കുന്നു, എന്നാൽ ഒരു ആക്രമണകാരിക്ക് പ്രോസസർ ഊഹക്കച്ചവടത്തോടെ ഒരു പ്രവർത്തനം നടത്താൻ ശ്രമിക്കുന്നതിന് സാഹചര്യങ്ങൾ സൃഷ്ടിക്കാൻ കഴിയും. സ്ഥിരീകരണ വ്യവസ്ഥകൾ പാലിക്കാത്ത ഒരു വിലാസം.

കേർണൽ 4.15 പുറത്തിറങ്ങിയതുമുതൽ പ്രശ്നം പ്രത്യക്ഷപ്പെടുന്നു, പാച്ചുകളുടെ രൂപത്തിൽ (1, 2, 3, 4) പരിഹരിച്ചു. വിതരണങ്ങളിൽ (Debian, RHEL, Ubuntu, Fedora, SUSE, Arch) അപകടസാധ്യത പരിഹരിക്കപ്പെട്ടിട്ടില്ല.

കൂടാതെ, സ്‌പെക്‌റ്റർ കേടുപാടുകളിൽ നിന്ന് പരിരക്ഷിക്കുന്നതിനുള്ള ഉപകരണങ്ങളുടെ പ്രകടന സ്വാധീനത്തെക്കുറിച്ചുള്ള കുറിപ്പ് നിങ്ങൾക്ക് ശ്രദ്ധിക്കാവുന്നതാണ്. ഫയർഫോക്സിൽ ആവർത്തിക്കാൻ ബുദ്ധിമുട്ടുള്ള പിശകുകൾ ഡീബഗ് ചെയ്യുന്നതിനായി മോസില്ലയിൽ ഒരിക്കൽ സൃഷ്ടിച്ച rr (റെക്കോർഡ് ആൻഡ് റീപ്ലേ) ഡീബഗ്ഗറിൻ്റെ ഒപ്റ്റിമൈസേഷൻ്റെ ഫലങ്ങൾ കുറിപ്പ് സംഗ്രഹിക്കുന്നു. ഡയറക്‌ടറികളുടെ അസ്തിത്വം പരിശോധിക്കാൻ ഉപയോഗിക്കുന്ന സിസ്റ്റം കോളുകൾ കാഷെ ചെയ്യുന്നത്, ടെസ്റ്റ് പ്രോജക്റ്റിനായുള്ള "rr സോഴ്‌സ്" പ്രവർത്തനം 3 മിനിറ്റ് 19 സെക്കൻഡിൽ നിന്ന് 36 സെക്കൻഡായി കുറച്ചു.

സ്‌പെക്ടർ പരിരക്ഷ പ്രവർത്തനരഹിതമാക്കിയതിന് ശേഷം പ്രകടനം എങ്ങനെ മാറുമെന്ന് പരിശോധിക്കാൻ ഒപ്റ്റിമൈസേഷൻ രചയിതാവ് തീരുമാനിച്ചു. “mitigations=off” എന്ന പാരാമീറ്റർ ഉപയോഗിച്ച് സിസ്റ്റം ലോഡുചെയ്‌തതിനുശേഷം, ഒപ്റ്റിമൈസേഷൻ ഇല്ലാതെ “rr ഉറവിടങ്ങൾ” എക്‌സിക്യൂഷൻ സമയം 2 മിനിറ്റ് 5 സെക്കൻഡ് (1.6 മടങ്ങ് വേഗത്തിൽ), ഒപ്റ്റിമൈസേഷനിൽ ഇത് 33 സെക്കൻഡ് (9% വേഗത്തിൽ) ആയിരുന്നു. രസകരമെന്നു പറയട്ടെ, സ്‌പെക്ടർ സംരക്ഷണം പ്രവർത്തനരഹിതമാക്കുന്നത് കേർണൽ തലത്തിൽ കോഡ് എക്‌സിക്യൂഷൻ സമയം 1.4 മടങ്ങ് കുറയ്ക്കുക മാത്രമല്ല (2m9s മുതൽ 1m32s വരെ), മാത്രമല്ല ഉപയോക്തൃ സ്ഥലത്ത് എക്‌സിക്യൂഷൻ സമയം പകുതിയായി കുറയ്ക്കുകയും ചെയ്തു (1m9s മുതൽ 0m33s വരെ), ഒരുപക്ഷേ കാര്യക്ഷമത കുറഞ്ഞ CPU കാഷെ പ്രവർത്തനവും TLB കാഷെ പ്രവർത്തനവും. സ്‌പെക്‌റ്റർ സംരക്ഷണം പ്രവർത്തനക്ഷമമാക്കുമ്പോൾ പുനഃസജ്ജമാക്കുന്നു.

അവലംബം: opennet.ru