🥇macOS හි ක්‍රියාවලි සහ කර්නල් දිගු ආරක්ෂා කරන්නේ කෙසේද

හෙලෝ, හබ්ර්! macOS හි ප්‍රහාරකයින්ගේ ප්‍රහාර වලින් ඔබට ක්‍රියාවලි ආරක්ෂා කරන්නේ කෙසේද යන්න ගැන අද මම කතා කිරීමට කැමැත්තෙමි. උදාහරණයක් ලෙස, මෙය ප්‍රති-වයිරස හෝ උපස්ථ පද්ධතියක් සඳහා ප්‍රයෝජනවත් වේ, විශේෂයෙන් macOS යටතේ ක්‍රියාවලියක් "මරන්න" ක්‍රම කිහිපයක් ඇති බැවින්. කප්පාදුව යටතේ මේ ගැන සහ ආරක්ෂණ ක්රම ගැන කියවන්න.

ක්රියාවලියක් "මරන්න" සම්භාව්ය ක්රමය

ක්රියාවලියක් "මරා දැමීම" සඳහා සුප්රසිද්ධ ක්රමයක් වන්නේ ක්රියාවලිය වෙත SIGKILL සංඥාවක් යැවීමයි. bash හරහා ඔබට ඝාතනය කිරීමට සම්මත "kill -SIGKILL PID" හෝ "pkill -9 NAME" ඇමතීමට හැකිය. "kill" විධානය UNIX හි දින සිට දන්නා අතර එය macOS මත පමණක් නොව අනෙකුත් UNIX වැනි පද්ධතිවලද ඇත.

UNIX වැනි පද්ධතිවල මෙන්, macOS මඟින් ඔබට SIGKILL සහ SIGSTOP දෙකක් හැර ක්‍රියාවලියකට ඕනෑම සංඥාවක් බාධා කිරීමට ඉඩ සලසයි. මෙම ලිපිය මූලික වශයෙන් අවධානය යොමු කරන්නේ SIGKILL සංඥාව ක්‍රියාවලියක් මරා දැමීමට හේතු වන සංඥාවක් ලෙසයි.

macOS විශේෂතා

macOS මත, XNU කර්නලයේ ඇති කිල් සිස්ටම් ඇමතුම psignal(SIGKILL,...) ශ්‍රිතය අමතයි. පරිශීලක අවකාශයේ වෙනත් පරිශීලක ක්‍රියා psignal ශ්‍රිතය මගින් හැඳින්විය හැක්කේ කුමක් දැයි බැලීමට උත්සාහ කරමු. කර්නලයේ අභ්‍යන්තර යාන්ත්‍රණවල ඇති psignal ශ්‍රිතයට ලැබෙන ඇමතුම් ඉවත් කරමු (ඒවා සුළු නොවන නමුත්, අපි ඒවා වෙනත් ලිපියක් සඳහා තබමු 🙂 - අත්සන සත්‍යාපනය, මතක දෝෂ, පිටවීම/අවසන් කිරීම, හැසිරවීම අවසන් කිරීම, ගොනු ආරක්ෂණ උල්ලංඝනය කිරීම් ආදිය. .

කාර්යය සහ අනුරූප පද්ධති ඇමතුම සමඟ සමාලෝචනය ආරම්භ කරමු අවසන්_ගෙවීම්_සමඟ. සම්භාව්‍ය ඝාතන ඇමතුමට අමතරව, macOS මෙහෙයුම් පද්ධතියට විශේෂිත වූ සහ BSD හි දක්නට නොලැබෙන විකල්ප ප්‍රවේශයක් ඇති බව දැකිය හැකිය. පද්ධති ඇමතුම් දෙකෙහිම මෙහෙයුම් මූලධර්ම ද සමාන වේ. ඒවා kernel function psignal වෙත සෘජු ඇමතුම් වේ. ක්‍රියාවලියක් විනාශ කිරීමට පෙර, “කැන්සිග්නල්” පරීක්‍ෂණයක් සිදු කරන බව සලකන්න - ක්‍රියාවලියට වෙනත් ක්‍රියාවලියකට සංඥාවක් යැවිය හැකිද; උදාහරණයක් ලෙස පද්ධති ක්‍රියාවලීන් විනාශ කිරීමට පද්ධතිය කිසිදු යෙදුමකට ඉඩ නොදේ.

static int
terminate_with_payload_internal(struct proc *cur_proc, int target_pid, uint32_t reason_namespace,
				uint64_t reason_code, user_addr_t payload, uint32_t payload_size,
				user_addr_t reason_string, uint64_t reason_flags)
{
...
	target_proc = proc_find(target_pid);
...
	if (!cansignal(cur_proc, cur_cred, target_proc, SIGKILL)) {
		proc_rele(target_proc);
		return EPERM;
	}
...
	if (target_pid == cur_proc->p_pid) {
		/*
		 * psignal_thread_with_reason() will pend a SIGKILL on the specified thread or
		 * return if the thread and/or task are already terminating. Either way, the
		 * current thread won't return to userspace.
		 */
		psignal_thread_with_reason(target_proc, current_thread(), SIGKILL, signal_reason);
	} else {
		psignal_with_reason(target_proc, SIGKILL, signal_reason);
	}
...
}

දියත් කළා

පද්ධති ආරම්භයේදී ඩීමන් නිර්මාණය කිරීමට සහ ඔවුන්ගේ ජීවිත කාලය පාලනය කිරීමට සම්මත ක්‍රමය දියත් කෙරේ. මූලාශ්‍ර MacOS 10.10 දක්වා launchctl හි පැරණි අනුවාදය සඳහා වන බව කරුණාවෙන් සලකන්න, කේත උදාහරණ නිදර්ශන අරමුණු සඳහා සපයනු ලැබේ. නවීන launchctl XPC හරහා දියත් කළ සංඥා යවයි, launchctl තර්කනය එයට ගෙන ගොස් ඇත.

යෙදුම් හරියටම නතර කරන්නේ කෙසේදැයි බලමු. SIGTERM සංඥා යැවීමට පෙර, "proc_terminate" පද්ධති ඇමතුම භාවිතයෙන් යෙදුම නැවැත්වීමට උත්සාහ කරයි.

<launchctl src/core.c>
...
	error = proc_terminate(j->p, &sig);
	if (error) {
		job_log(j, LOG_ERR | LOG_CONSOLE, "Could not terminate job: %d: %s", error, strerror(error));
		job_log(j, LOG_NOTICE | LOG_CONSOLE, "Using fallback option to terminate job...");
		error = kill2(j->p, SIGTERM);
		if (error) {
			job_log(j, LOG_ERR, "Could not signal job: %d: %s", error, strerror(error));
		} 
...
<>

හුඩ් යටතේ, proc_terminate, එහි නම තිබියදීත්, SIGTERM සමඟ psignal පමණක් නොව, SIGKILL ද යැවිය හැක.

වක්‍ර ඝාතනය - සම්පත් සීමාව

තවත් පද්ධති ඇමතුමක වඩාත් රසවත් අවස්ථාවක් දැකිය හැකිය ක්‍රියාවලි_ප්‍රතිපත්ති. ගොනු හැඹිලි ක්‍රියාකාරකම් මගින් පද්ධතිය සැලකිය යුතු ලෙස මන්දගාමී නොවන පරිදි CPU කාලය සහ මතක කෝටාවන් සීමා කිරීම සඳහා සුචිකය සඳහා වැනි යෙදුම් සම්පත් සීමා කිරීම මෙම පද්ධති ඇමතුමේ පොදු භාවිතයකි. යෙදුමක් එහි සම්පත් සීමාවට ළඟා වී ඇත්නම්, proc_apply_resource_actions ශ්‍රිතයෙන් දැකිය හැකි පරිදි, ක්‍රියාවලියට SIGKILL සංඥාවක් යවනු ලැබේ.

මෙම පද්ධති ඇමතුම ක්‍රියාවලියක් විනාශ කළ හැකි වුවද, පද්ධතිය විසින් පද්ධති ඇමතුම ඇමතීමේ ක්‍රියාවලියේ අයිතිවාසිකම් ප්‍රමාණවත් ලෙස පරීක්ෂා කර නැත. ඇත්තටම පරීක්ෂා කරනවා පැවතිණි, නමුත් මෙම කොන්දේසිය මග හැරීමට විකල්ප ධජය PROC_POLICY_ACTION_SET භාවිතා කිරීම ප්‍රමාණවත් වේ.

එබැවින්, ඔබ යෙදුමේ CPU භාවිත කෝටාව "සීමා" කරන්නේ නම් (උදාහරණයක් ලෙස, 1 ns පමණක් ධාවනය කිරීමට ඉඩ දීම), එවිට ඔබට පද්ධතියේ ඕනෑම ක්‍රියාවලියක් විනාශ කළ හැක. මේ අනුව, අනිෂ්ට මෘදුකාංගයට ප්‍රති-වයිරස ක්‍රියාවලිය ඇතුළුව පද්ධතියේ ඕනෑම ක්‍රියාවලියක් විනාශ කළ හැකිය. Pid 1 (launchctl) සමඟ ක්‍රියාවලියක් විනාශ කිරීමේදී ඇතිවන බලපෑම ද සිත්ගන්නා කරුණකි - SIGKILL සංඥාව සැකසීමට උත්සාහ කරන විට කර්නල් භීතිය :)

ගැටලුව විසඳන්නේ කෙසේද?

ක්‍රියාවලියක් මරා දැමීම වැලැක්වීමට වඩාත්ම සරල ක්‍රමය නම් පද්ධති ඇමතුම් වගුවේ ඇති ක්‍රියාකාරී දර්ශකය ප්‍රතිස්ථාපනය කිරීමයි. අවාසනාවකට මෙන්, බොහෝ හේතු නිසා මෙම ක්රමය සුළුපටු නොවේ.

පළමුව, sysent ගේ මතක ස්ථානය පාලනය කරන සංකේතය XNU කර්නල් සංකේතයට පමණක් පුද්ගලික නොවේ, නමුත් කර්නල් සංකේතවල සොයාගත නොහැක. ඔබට ශ්‍රිතය ගතිකව විසුරුවා හැරීම සහ එහි දර්ශකයක් සෙවීම වැනි හූරිස්ටික් සෙවුම් ක්‍රම භාවිතා කිරීමට සිදුවනු ඇත.

දෙවනුව, වගුවේ ඇතුළත් කිරීම් වල ව්‍යුහය රඳා පවතින්නේ කර්නලය සම්පාදනය කරන ලද ධජ මත ය. CONFIG_REQUIRES_U32_MUNGING ධජය ප්‍රකාශ කළහොත්, ව්‍යුහයේ ප්‍රමාණය වෙනස් වනු ඇත - අමතර ක්ෂේත්‍රයක් එකතු වේ sy_arg_munge32. කර්නලය සම්පාදනය කර ඇත්තේ කුමන ධජයකින්ද යන්න තීරණය කිරීම සඳහා අතිරේක පරීක්‍ෂණයක් සිදු කිරීම අවශ්‍ය වේ, නැතහොත් දන්නා ඒවාට එරෙහිව ක්‍රියාකාරී දර්ශක පරීක්ෂා කරන්න.

struct sysent {         /* system call table */
        sy_call_t       *sy_call;       /* implementing function */
#if CONFIG_REQUIRES_U32_MUNGING || (__arm__ && (__BIGGEST_ALIGNMENT__ > 4))
        sy_munge_t      *sy_arg_munge32; /* system call arguments munger for 32-bit process */
#endif
        int32_t         sy_return_type; /* system call return types */
        int16_t         sy_narg;        /* number of args */
        uint16_t        sy_arg_bytes;   /* Total size of arguments in bytes for
                                         * 32-bit system calls
                                         */
};

වාසනාවකට මෙන්, macOS හි නවීන අනුවාද වල, Apple විසින් ක්‍රියාවලි සමඟ වැඩ කිරීම සඳහා නව API එකක් සපයයි. Endpoint Security API මඟින් සේවාදායකයින්ට වෙනත් ක්‍රියාවලීන් සඳහා බොහෝ ඉල්ලීම් අනුමත කිරීමට ඉඩ සලසයි. මේ අනුව, ඉහත සඳහන් කළ API භාවිතා කර SIGKILL සංඥාව ඇතුළුව ක්‍රියාවලි වෙත ඕනෑම සංඥාවක් අවහිර කළ හැක.

#include <bsm/libbsm.h>
#include <EndpointSecurity/EndpointSecurity.h>
#include <unistd.h>

int main(int argc, const char * argv[]) {
    es_client_t* cli = nullptr;
    {
        auto res = es_new_client(&cli, ^(es_client_t * client, const es_message_t * message) {
            switch (message->event_type) {
                case ES_EVENT_TYPE_AUTH_SIGNAL:
                {
                    auto& msg = message->event.signal;
                    auto target = msg.target;
                    auto& token = target->audit_token;
                    auto pid = audit_token_to_pid(token);
                    printf("signal '%d' sent to pid '%d'n", msg.sig, pid);
                    es_respond_auth_result(client, message, pid == getpid() ? ES_AUTH_RESULT_DENY : ES_AUTH_RESULT_ALLOW, false);
                }
                    break;
                default:
                    break;
            }
        });
    }

    {
        es_event_type_t evs[] = { ES_EVENT_TYPE_AUTH_SIGNAL };
        es_subscribe(cli, evs, sizeof(evs) / sizeof(*evs));
    }

    printf("%dn", getpid());
    sleep(60); // could be replaced with other waiting primitive

    es_unsubscribe_all(cli);
    es_delete_client(cli);

    return 0;
}

ඒ හා සමානව, MAC ප්‍රතිපත්තියක් කර්නලය තුළ ලියාපදිංචි කළ හැකි අතර, එය සංඥා ආරක්ෂණ ක්‍රමයක් (policy proc_check_signal) සපයන නමුත්, API නිල වශයෙන් සහාය නොදක්වයි.

කර්නල් දිගු ආරක්ෂාව

පද්ධතියේ ක්‍රියාවලි ආරක්ෂා කිරීමට අමතරව, කර්නල් දිගුව (kext) ආරක්ෂා කිරීම ද අවශ්‍ය වේ. MacOS සංවර්ධකයින්ට IOKit උපාංග ධාවක පහසුවෙන් සංවර්ධනය කිරීමට රාමුවක් සපයයි. උපාංග සමඟ වැඩ කිරීම සඳහා මෙවලම් සැපයීමට අමතරව, IOKit C++ පන්තිවල අවස්ථා භාවිතා කරමින් ධාවක ගොඩගැසීම සඳහා ක්‍රම සපයයි. පරිශීලක අවකාශයේ ඇති යෙදුමකට කර්නල්-පරිශීලක අවකාශය සම්බන්ධතාවයක් ඇති කර ගැනීම සඳහා පන්තියේ ලියාපදිංචි අවස්ථාවක් "සොයා ගැනීමට" හැකි වේ.

පද්ධතියේ පන්ති අවස්ථා ගණන හඳුනා ගැනීම සඳහා, ioclasscount උපයෝගීතාව ඇත.

my_kext_ioservice = 1
my_kext_iouserclient = 1

ධාවක තොගය සමඟ ලියාපදිංචි වීමට කැමති ඕනෑම කර්නල් දිගුවක් IOService වෙතින් උරුම වන පන්තියක් ප්‍රකාශ කළ යුතුය, උදාහරණයක් ලෙස my_kext_ioservice මෙම අවස්ථාවෙහිදී. පරිශීලක යෙදුම් සම්බන්ධ කිරීම IOUserClient වෙතින් උරුම වන පන්තියේ නව අවස්ථාවක් නිර්මාණය කිරීමට හේතු වේ, උදාහරණයක් ලෙස my_kext_iouserclient.

පද්ධතියෙන් ධාවකයක් බාගැනීමට උත්සාහ කරන විට (kextunload විධානය), අථත්ය ශ්රිතය "bool terminate (IOOptionBits විකල්ප)" ලෙස හැඳින්වේ. kextunload අක්‍රිය කිරීමට බාගැනීමට උත්සාහ කරන විට අවසන් කිරීමට ඇමතුම මත අසත්‍ය ලෙස ලබා දීම ප්‍රමාණවත් වේ.

bool Kext::terminate(IOOptionBits options)
{

  if (!IsUnloadAllowed)
  {
    // Unload is not allowed, returning false
    return false;
  }

  return super::terminate(options);
}

IsUnloadAllowed ධජය පූරණය වන විට IOUserClient විසින් සැකසිය හැක. බාගත කිරීමේ සීමාවක් ඇති විට, kextunload විධානය පහත ප්‍රතිදානය ලබා දෙනු ඇත:

admin@admins-Mac drivermanager % sudo kextunload ./test.kext
Password:
(kernel) Can't remove kext my.kext.test; services failed to terminate - 0xe00002c7.
Failed to unload my.kext.test - (iokit/common) unsupported function.

IOUserClient සඳහා සමාන ආරක්ෂාවක් කළ යුතුය. "IOCatalogueTerminate(mach_port_t, uint32_t ධජය, io_name_t description)" IOKitLib පරිශීලක අවකාශයේ ශ්‍රිතය භාවිතයෙන් පන්තිවල අවස්ථා බා ගත හැක. පරිශීලක අවකාශයේ යෙදුම “මියෙන” තෙක් “අවසන්” විධානය ඇමතීමෙන් ඔබට අසත්‍ය ආපසු ලබා දිය හැකිය, එනම් “ClientDied” ශ්‍රිතය කැඳවනු නොලැබේ.

ගොනු ආරක්ෂාව

ගොනු ආරක්ෂා කිරීම සඳහා, Kauth API භාවිතා කිරීම ප්රමාණවත් වේ, එය ඔබට ගොනු වෙත ප්රවේශය සීමා කිරීමට ඉඩ සලසයි. Apple විසින් විෂය පථයේ විවිධ සිදුවීම් පිළිබඳ දැනුම්දීම් සමඟ සංවර්ධකයන්ට සපයයි; අපට, KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA සහ KAUTH_VNODE_DELETE_CHILD මෙහෙයුම් වැදගත් වේ. ගොනු වෙත ප්‍රවේශය සීමා කිරීමට ඇති පහසුම ක්‍රමය වන්නේ මාර්ගයයි - අපි ගොනුවට මාර්ගය ලබා ගැනීමට සහ මාර්ග උපසර්ගය සංසන්දනය කිරීමට “vn_getpath” API භාවිතා කරමු. ගොනු ෆෝල්ඩර මාර්ග නැවත නම් කිරීම ප්‍රශස්ත කිරීම සඳහා, පද්ධතිය එක් එක් ගොනුවට ප්‍රවේශ වීමට අවසර නොදේ, නමුත් නැවත නම් කර ඇති ෆෝල්ඩරයට පමණක් බව සලකන්න. මාපිය මාර්ගය සංසන්දනය කිරීම සහ ඒ සඳහා KAUTH_VNODE_DELETE සීමා කිරීම අවශ්‍ය වේ.

මෙම ප්රවේශයේ අවාසිය උපසර්ග සංඛ්යාව වැඩි වන විට අඩු කාර්ය සාධනයක් විය හැකිය. සංසන්දනය O (උපසර්ගය* දිග) ට සමාන නොවන බව සහතික කිරීම සඳහා, උපසර්ගය යනු උපසර්ග ගණන, දිග යනු තන්තුවේ දිග, ඔබට උපසර්ග මගින් ගොඩනගා ඇති නිර්ණායක පරිමිත ස්වයංක්‍රීයකරණය (DFA) භාවිතා කළ හැකිය.

දී ඇති උපසර්ග කට්ටලයක් සඳහා DFA එකක් සෑදීමේ ක්‍රමයක් සලකා බලමු. අපි එක් එක් උපසර්ගය ආරම්භයේදී කර්සරය ආරම්භ කරමු. සියලුම කර්සරය එකම අක්ෂරයකට යොමු කරන්නේ නම්, එක් එක් කර්සරය එක් අක්ෂරයකින් වැඩි කර එකම පේළියේ දිග එකකින් වැඩි බව මතක තබා ගන්න. විවිධ සංකේත සහිත කර්සර දෙකක් තිබේ නම්, ඔවුන් පෙන්වා දෙන සංකේතය අනුව කර්සරය කණ්ඩායම් වලට බෙදා එක් එක් කණ්ඩායම සඳහා ඇල්ගොරිතම නැවත කරන්න.

පළමු අවස්ථාවේ දී (කර්සරය යටතේ ඇති සියලුම අක්ෂර සමාන වේ), අපි එකම රේඛාව ඔස්සේ එක් සංක්රමණයක් පමණක් ඇති DFA තත්වයක් ලබා ගනිමු. දෙවන අවස්ථාවෙහිදී, ශ්‍රිතය පුනරාවර්තන ලෙස ඇමතීමෙන් ලබාගත් පසුකාලීන අවස්ථා වෙත 256 ප්‍රමාණයේ (අක්ෂර ගණන සහ උපරිම කණ්ඩායම් සංඛ්‍යාව) සංක්‍රාන්ති වගුවක් අපට ලැබේ.

අපි උදාහරණයක් බලමු. උපසර්ග කට්ටලයක් සඳහා (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) ඔබට පහත දේ ලබා ගත හැක. ඩීඑෆ්ඒ. රූපයේ දැක්වෙන්නේ වෙනත් ප්‍රාන්තවලට යන සංක්‍රාන්ති පමණි; අනෙකුත් සංක්‍රාන්ති අවසාන නොවේ.

DKA ප්‍රාන්ත හරහා යන විට, අවස්ථා 3 ක් තිබිය හැකිය.

අවසාන තත්ත්වයට ළඟා වී ඇත - මාර්ගය ආරක්ෂිතයි, අපි KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA සහ KAUTH_VNODE_DELETE_CHILD මෙහෙයුම් සීමා කරමු
අවසාන තත්ත්වයට ළඟා වී නැත, නමුත් මාර්ගය “අවසන්” (ශුන්‍ය ටර්මිනේටරය ළඟා විය) - මාර්ගය මාපියෙකි, එය KAUTH_VNODE_DELETE සීමා කිරීමට අවශ්‍ය වේ. vnode ෆෝල්ඩරයක් නම්, ඔබ අවසානයේ '/' එකක් එකතු කළ යුතු බව සලකන්න, එසේ නොමැතිනම් එය වැරදිය වන “/for/bar/t” ගොනුවට සීමා විය හැක.
අවසාන තත්ත්වයට ළඟා වූයේ නැත, මාර්ගය අවසන් වූයේ නැත. උපසර්ග කිසිවක් මෙයට නොගැලපේ, අපි සීමා කිරීම් හඳුන්වා නොදෙමු.

නිගමනය

සංවර්ධනය වෙමින් පවතින ආරක්ෂක විසඳුම්වල පරමාර්ථය වන්නේ පරිශීලකයාගේ සහ ඔහුගේ දත්තවල ආරක්ෂණ මට්ටම ඉහළ නැංවීමයි. එක් අතකින්, මෙම ඉලක්කය අත්පත් කරගනු ලබන්නේ Acronis මෘදුකාංග නිෂ්පාදනයේ සංවර්ධනය මගින් වන අතර, මෙහෙයුම් පද්ධතියම "දුර්වල" ඇති එම දුර්වලතා වසා දමයි. අනෙක් අතට, OS පැත්තෙන් වැඩිදියුණු කළ හැකි ආරක්ෂක අංශ ශක්තිමත් කිරීම අප නොසලකා හැරිය යුතු නැත, විශේෂයෙන් එවැනි දුර්වලතා වසා දැමීම නිෂ්පාදනයක් ලෙස අපගේම ස්ථාවරත්වය වැඩි කරන බැවිනි. අවදානම Apple නිෂ්පාදන ආරක්ෂක කණ්ඩායමට වාර්තා කර ඇති අතර එය macOS 10.14.5 (https://support.apple.com/en-gb/HT210119) හි සවි කර ඇත.

මේ සියල්ල කළ හැක්කේ ඔබගේ උපයෝගීතාව කර්නලයට නිල වශයෙන් ස්ථාපනය කර ඇත්නම් පමණි. එනම්, බාහිර හා අනවශ්ය මෘදුකාංග සඳහා එවැනි අඩුපාඩු නොමැත. කෙසේ වෙතත්, ඔබට පෙනෙන පරිදි, ප්රතිවයිරස සහ උපස්ථ පද්ධති වැනි නීත්යානුකූල වැඩසටහන් ආරක්ෂා කිරීම පවා අවශ්ය වේ. නමුත් දැන් macOS සඳහා වන නව Acronis නිෂ්පාදන පද්ධතියෙන් බෑමට එරෙහිව අමතර ආරක්ෂාවක් ඇත.

මූලාශ්රය: www.habr.com

macOS මත ක්‍රියාවලි සහ කර්නල් දිගු ආරක්ෂා කරන්නේ කෙසේද

ක්රියාවලියක් "මරන්න" සම්භාව්ය ක්රමය

macOS විශේෂතා

දියත් කළා

වක්‍ර ඝාතනය - සම්පත් සීමාව

ගැටලුව විසඳන්නේ කෙසේද?

කර්නල් දිගු ආරක්ෂාව

ගොනු ආරක්ෂාව

නිගමනය

අදහස් එක් කරන්න

macOS මත ක්‍රියාවලි සහ කර්නල් දිගු ආරක්ෂා කරන්නේ කෙසේද

ක්රියාවලියක් "මරන්න" සම්භාව්ය ක්රමය

macOS විශේෂතා

දියත් කළා

වක්‍ර ඝාතනය - සම්පත් සීමාව

ගැටලුව විසඳන්නේ කෙසේද?

කර්නල් දිගු ආරක්ෂාව

ගොනු ආරක්ෂාව

නිගමනය

අදහස් එක් කරන්න ඊ-මේල් මගින් පිලිතුරු දෙන්න අවලංගු

අදහස් එක් කරන්න