VPSలో live kernel patching లేదా reboot: ఏది మంచిది?

VPSలో live kernel patching చేసే పని

Live kernel patching నడుస్తున్న machineకు reboot లేకుండా, connections తెగకుండా kernel security fixes ను వర్తింపజేస్తుంది. సరిచేసిన function copy ను kernel moduleగా load చేస్తారు. Machine network traffic ను అందిస్తూనే, పాత functionకు వెళ్లే ప్రతి call ను కొత్త copyకి redirect చేస్తుంది. Live patching ఏ పనులకు ఉపయోగపడుతుందో, ఏ పనులు చేయలేదో ఈ విధానం స్పష్టం చేస్తుంది.

ఇది మీకు సమయం ఇస్తుంది. కానీ reboot అవసరాన్ని తొలగించదు. ఆరు నెలలుగా live patchedగా ఉన్న serverలో diskపై ఉన్న పాత kernel image నుంచే boot అయి ఉంటుంది. ఆ patches అన్నీ memoryలో మాత్రమే ఉంటాయి.

Live patchingను managed planలోని featureగా తరచుగా అందిస్తారు. unmanaged boxలో రెండు commandsతో దీన్ని మీరే enable చేయవచ్చు. అందువల్ల managed మరియు unmanaged VPS మధ్య తేడా కోసం అదనంగా చెల్లించే ముందు ఈ విషయం తెలుసుకోవడం ఉపయోగకరం.

లైవ్ kernel patching ఎలా పనిచేస్తుంది?

Kernel లో built-in live patching core ఉంటుంది. ఇది CONFIG_LIVEPATCH తో compile చేయబడుతుంది. ప్రస్తుతం నడుస్తున్న kernel లో దీనిని తనిఖీ చేయండి:

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

CONFIG_LIVEPATCH=y ఉన్న line కనిపిస్తే, మీరు నడుపుతున్న kernel ఈ core తో build అయిందని అర్థం. ఇది లేకపోతే, ఆ machine పై ఏ live patching service కూడా పనిచేయదు.

ఈ redirection కోసం kernel యొక్క function tracer అయిన ftrace ఉపయోగించబడుతుంది. చాలా kernel functions ను function ప్రారంభంలోనే, arguments లేదా stack మార్పు చెందకముందు, call instruction తో compile చేస్తారు. Ftrace ఆ call site ను hook గా ఉపయోగిస్తుంది. Patch apply చేసినప్పుడు, live patching core target function పై ftrace handler ను register చేస్తుంది. ఆ handler execution ను replacement function కు పంపుతుంది. Kernel documentation దీన్ని స్పష్టంగా వివరిస్తుంది: "Livepatching typically needs to redirect the code at the very beginning of the function entry before the function parameters or the stack are in any way modified."

ఈ వాక్యం నుంచి రెండు ముఖ్యమైన విషయాలు తెలుస్తాయి. తరువాతి దశల్లో రెండూ అవసరం అవుతాయి. Function ftrace ద్వారా hook చేయగలిగినప్పుడే అది patch చేయదగినది. ఆ entry call లేకుండా compile చేసిన function ను అసలు patch చేయలేరు. అలాగే patching unit అనేది మొత్తం function మాత్రమే. Function లోని ఒక line ను మాత్రమే patch చేయలేరు.

నడుస్తున్న system ను సురక్షితంగా మార్చడం మరింత క్లిష్టమైన భాగం. Function ను మార్చే సమయంలో పాత code ఏదైనా CPU stack పై ఇంకా నడుస్తుంటే, పాత మరియు కొత్త behaviour కలిసిపోతాయి. Upstream Linux దీన్ని per-task consistency model తో నిర్వహిస్తుంది. Kernel documentation దీన్ని hybrid విధానంగా వివరిస్తుంది: "it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching." Kernel ఒక task ప్రస్తుతం patched function లో లేదని నిర్ధారించగలిగినప్పుడు మాత్రమే, tasks ఒక్కొక్కటిగా కొత్త code కు మారతాయి. ప్రతి task మారే వరకు patch transition లో ఉంటుంది.

ఫలితాన్ని మీరు స్వయంగా చూడవచ్చు. Applied patches /sys/kernel/livepatch కింద కనిపిస్తాయి. ప్రతి patch కు ఒక directory ఉంటుంది. ఆ directory లో patched functions జాబితా ఉంటుంది.

ls /sys/kernel/livepatch/

Empty listing అంటే memory లో live patch ఏదీ load కాలేదని అర్థం. Fresh server లో ఇది సాధారణ ప్రారంభ స్థితి.

లైవ్ kernel patching ఏ సమస్యలను పరిష్కరించలదు

Function bodies కు మాత్రమే patch వర్తిస్తుంది. మిగతా దేనికీ వర్తించదు.

• మారిన data structures. Upstream fix ఒక struct కు field జోడిస్తే లేదా ఇప్పటికే ఉన్న field అర్థాన్ని మార్చితే, ఇప్పటికే allocate చేసి ఉపయోగిస్తున్న objects ను సురక్షితంగా తిరిగి రాయడానికి మార్గం ఉండదు. kpatch project ఇదే పరిస్థితిని నేరుగా పేర్కొంటుంది: "Patches which modify statically allocated data are not directly supported." Shadow variables మరియు callbacks workaround గా ఉన్నాయి. కానీ అవి ప్రతి patch కోసం చేతితో రాయాలి; స్వయంచాలకంగా ఏర్పడవు.
• ఒకేసారి అనేక functions లో విస్తరించే fixes. Functions సమూహం మధ్య lock ordering ను మార్చే fix కు అవన్నీ కలిసి మారాలి. Consistency model మొత్తం machine ను ఒకే సమయంలో freeze చేయదు; tasks ను మారుస్తుంది.
• Initialisation code. __init తో గుర్తించిన functions ఇప్పటికే అమలై, మీ server ప్రారంభమయ్యే సమయానికి freed అయి ఉంటాయి. అందువల్ల redirect చేయడానికి ఏదీ మిగలదు.
• కొత్త kernel versions మరియు కొత్త features. Live patching ఒకే kernel series లోని patch level ల మధ్య మాత్రమే ముందుకు తీసుకెళ్తుంది. ఇది ఒక series నుంచి తదుపరి series కు ఎప్పుడూ మార్చదు. ఏ feature ను కూడా జోడించదు. కొత్త series లోని ఏదైనా కావాలంటే, ఉదాహరణకు Linux 7.1 లో వచ్చిన మార్పులు, ఆ kernel ను install చేసి boot చేయాలి.
• Userspace. Canonical ఈ పరిమితిని స్పష్టంగా పేర్కొంటుంది: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." పాత OpenSSL పక్కన live patched kernel ఉన్నంత మాత్రాన అది patched server కాదు. అందువల్ల అదే machine లో userspace packages ను unattended upgrades నిర్వహించేలా ఉంచాలి.

Ubuntu service కు severity పరిమితి కూడా ఉంది. ఇది "critical మరియు high Common Vulnerability Scoring System (CVSS) మరియు Ubuntu Priority ratings కలిగిన kernel vulnerabilities ను patch చేస్తుంది" అని Canonical చెబుతుంది. CVE (common vulnerabilities and exposures) identifier ఒక flaw ను సూచిస్తుంది. CVSS దానికి అనుసంధానమైన score. Medium-rated kernel CVE ను disk పై ఉన్న package లో fix చేస్తారు; దానికి live patch వర్తించదు. అందువల్ల అది తర్వాతి reboot సమయంలోనే running kernel కు చేరుతుంది, అంతకు ముందు కాదు.

లైవ్ కెర్నల్ ప్యాచింగ్‌కు ఉన్న ఎంపికలు ఏమిటి?

సాధారణంగా మూడు పరిష్కార పరంపరలు ఉపయోగంలో ఉన్నాయి. ఇవన్నీ ఒకే kernel యంత్రాంగాన్ని ఉపయోగిస్తాయి.

Canonical Livepatch Ubuntu Pro ద్వారా అందించబడుతుంది. వ్యక్తిగత వినియోగానికి Ubuntu Pro ఉచితం. Canonical ప్రకారం, ఇది “వ్యక్తిగత వినియోగానికి గరిష్ఠంగా 5 physical machines వరకు ఎప్పటికీ ఉచితంగా ఉంటుంది”. అధికారిక Ubuntu Community సభ్యులకు ఈ పరిమితి 50 machines వరకు ఉంటుంది. August 2026 నాటికి ఇదే పత్రబద్ధమైన పరిమితి. వాణిజ్య వినియోగానికి paid subscription అవసరం. మద్దతు ఉన్న long term support (LTS) releases లోని general availability (GA) kernels, వాటి hardware enablement (HWE) kernels తో సహా, ప్రతి kernel series మరియు flavour ఆధారంగా coverage అందించబడుతుంది. ఇందులో generic, aws, azure, gcp, oracle, ibm మరియు lowlatency వంటి flavours ఉన్నాయి. దీనిపై ఆధారపడే ముందు మీ kernel ను Canonical ప్రచురించిన kernel list తో సరిపోల్చండి.

KernelCare, TuxCare నుంచి అందించబడే commercial agent. first-party service లేని distributions తో సహా అనేక distributions కు ఇది మద్దతు ఇస్తుంది. దీని పత్రబద్ధమైన installation కోసం vendor script curl -s -L https://kernelcare.com/installer | bash ను అమలు చేయాలి. key-based licence కోసం తరువాత /usr/bin/kcarectl --register KEY ను అమలు చేయాలి. ఆ తర్వాత agent తన షెడ్యూల్ ప్రకారం కొత్త patches కోసం తనంతట తానే తనిఖీ చేస్తుంది. తనిఖీని బలవంతంగా ప్రారంభించడానికి /usr/bin/kcarectl --update ఉపయోగించాలి. మీకు ముఖ్యమైన server లో installer ను shell కు pipe చేసే ముందు దాన్ని చదవండి.

kpatch మరియు kGraft పూర్వీకులైన పరిష్కారాలు. kGraft SUSE నుంచి, kpatch Red Hat నుంచి వచ్చాయి. ప్రస్తుతం upstream Linux లోని live patching core ఈ రెండు ఆలోచనల సమ్మేళనం. kpatch స్వయంగా క్రమంగా నిలిపివేయబడుతోంది. Linux 6.19 నుంచి “kpatch project deprecated అయి maintenance mode లో ఉంటుంది” అని దాని README పేర్కొంటుంది. upstream kernel లో kpatch-build స్థానంలో klp-build ఉపయోగించబడుతుంది. RHEL మరియు దాని rebuilds లో patches ను చేతితో నిర్మించకుండా distribution అందించే స్వంత service ను ఉపయోగించాలి.

మీ distribution ఏది support చేస్తుందో, మీ licence ఏది అనుమతిస్తుందో ఆధారంగా ఎంపిక చేసుకోండి. ప్రతి సందర్భంలో kernel స్థాయిలో వచ్చే ఫలితం ఒకటే.

Ubuntuలో Canonical Livepatch ను ఎలా ప్రారంభించాలి

ముందుగా మీ Ubuntu Pro ఖాతా పేజీ నుంచి token పొందండి. దిగువ రెండు commands పనిచేయడానికి outbound network access అందుబాటులో ఉండాలి. Client Canonical servers కు కనెక్ట్ అయి attachment చేయడంతోపాటు patches ను పొందుతుంది.

sudo pro attach TOKEN
sudo pro status

Token లేకుండా sudo pro attach ను అమలు చేస్తే browser ఆధారిత flow ప్రారంభమవుతుంది. Canonical site లో నమోదు చేయడానికి ఒక code కూడా చూపిస్తుంది. Attaching చేసినప్పుడు సిఫారసు చేసిన services స్వయంచాలకంగా enable అవుతాయి. ప్రస్తుత LTS release లో Livepatch కూడా వీటిలో ఉంటుంది. Services ను మీరే ఎంచుకోవాలనుకుంటే sudo pro attach --no-auto-enable ఉపయోగించండి.

Livepatch ఇప్పటికే enable అయి లేకపోతే:

sudo pro enable livepatch
sudo canonical-livepatch status

ఈ service canonical-livepatch snap నుంచి నడుస్తుంది. అందువల్ల enable దశ పూర్తవ్వడానికి snapd సరిగా పనిచేయాలి. pro status services యొక్క entitlement మరియు status తో కూడిన పట్టికను చూపిస్తుంది. canonical-livepatch status ప్రతి kernel కు సంబంధించిన వివరాలను చూపిస్తుంది. Canonical documentation లో output ఈ ఆకృతిలో ఉంటుంది:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

సమాధానాన్ని రెండు lines అందిస్తాయి. మీరు నడుపుతున్న series కు ఈ service మద్దతు ఇస్తుందో లేదో kernel state చూపిస్తుంది. Livepatch మద్దతు లేని kernel తో boot చేసినప్పుడు ఈ line లో సమస్య కనిపిస్తుంది. ఆ kernel కు వర్తించే patches నిజంగా load అయ్యాయో లేదో patch state చూపిస్తుంది. మద్దతు ఉన్న kernel కు patches apply కాకపోతే అది client సమస్య. మద్దతు లేని kernel అయితే అది kernel సమస్య. Client setting మార్చడం ద్వారా దాన్ని పరిష్కరించలేరు.

రీబూట్ అవసరం ఉందో లేదో ఎలా తెలుసుకోవాలి?

Live patching అత్యవసర పరిస్థితిని తొలగిస్తుంది. అందువల్ల pending reboot వెంటనే కనిపించదు. దాన్ని ప్రత్యేకంగా పరిశీలించాలి.

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

ఇన్‌స్టాల్ చేసిన package అమలులోకి రావడానికి restart అవసరమైనప్పుడు package manager /var/run/reboot-required ను సృష్టిస్తుంది. కొత్త linux-image package ఎల్లప్పుడూ దీన్ని సృష్టిస్తుంది. ఏ packages దీనిని కోరాయో .pkgs file జాబితా చేస్తుంది. మొదటి command సమాధానంగా No such file or directory ఇస్తే, machine చివరిసారి boot అయిన తర్వాత reboot ను కోరిన package ఏదీ లేదు. ప్రస్తుత Ubuntu లో /var/run, /run కు symbolic link గా ఉంటుంది. అందువల్ల ఏ path ఉపయోగించినా అదే file ను తెస్తుంది.

ఈ flag tmpfs లో ఉంటుంది. ప్రతి boot సమయంలో ఇది reset అవుతుంది. కాబట్టి దాన్ని kernel తో కూడా నిర్ధారించాలి:

uname -r
dpkg -l 'linux-image-*' | grep ^ii

మీరు ప్రస్తుతం నడుపుతున్న kernel ను uname -r చూపిస్తుంది. రెండవ command disk లో ఇన్‌స్టాల్ అయిన kernel packages ను చూపిస్తుంది. ఆ జాబితాలో linux-image, uname -r చూపించే version కంటే కొత్తగా ఉంటే, Livepatch status ఏదైనా machine పాత kernel ను నడుపుతోంది. ఇదే ముఖ్యమైన తనిఖీ. Live patching నడుస్తున్న kernel ను సురక్షితంగా ఉంచడానికి రూపొందించబడింది. దాన్ని తాజా version గా మార్చడానికి కాదు.

అదే ప్రశ్నలో userspace భాగం కోసం, Ubuntu Server లో default గా ఇన్‌స్టాల్ అయ్యే needrestart, తొలగించిన library files ను ఇంకా open గా ఉంచిన running services ను జాబితా చేస్తుంది.

sudo needrestart -r l

-r l flag pair అంటే "list only". కాబట్టి ఇది కేవలం వివరాలను చూపిస్తుంది; ఏ మార్పూ చేయదు.

రీబూట్ అవసరం ఎందుకు ఎప్పటికీ తొలగిపోదు

డిస్క్‌లో ఉన్న kernel మారదు. Live patches నడుస్తున్న kernel‌లోకి లోడ్ అవుతాయి, boot image‌లో ఎప్పటికీ వ్రాయబడవు. అందువల్ల reboot చేసినప్పుడు bootloader ఎంచుకున్న linux-image తో సిస్టమ్ ప్రారంభమవుతుంది. తరువాత Livepatch client వర్తించే patches‌ను మళ్లీ అమలు చేస్తుంది. ఈ రెండు దశల మధ్య మీరు patches లేని code‌ను నడుపుతారు. పాత kernel బదులుగా ప్రస్తుత kernel‌తో boot చేయడానికి ఇదొక అదనపు కారణం.

Coverage ప్రతి kernel series‌కు విడిగా ఉంటుంది. Series‌ల support కూడా ముగుస్తుంది. మీరు నడుపుతున్న series supported list నుంచి తొలగిపోయినప్పుడు, kernel state line coverage‌ను నివేదించడం ఆపేస్తుంది. దీనికి ఏకైక పరిష్కారం కొత్త kernel. అదే reboot. LTS release‌లో కొత్త series సాధారణంగా hardware enablement kernel‌గా మీకు అందుతుంది. అది 26.04.1 వంటి point releaseలో చేర్చబడి ఉంటుంది. కాబట్టి replacement ఇప్పటికే archive‌లో ఉంటుంది. మీరు నిర్ణయించిన సమయంలో ఒక boot చేయడం మాత్రమే మిగిలి ఉంటుంది.

Medium మరియు low severity kernel fixes‌కు live patching ఎప్పుడూ జరగదు. అవి డిస్క్‌లోని package‌లో ఉంటాయి. మీరు boot చేసినప్పుడు మాత్రమే అవి వర్తిస్తాయి.

ఎక్కువసేపు నడిచే kernels‌లో patching శుభ్రం చేయని state కూడా పేరుకుపోతుంది. Canonical అభిప్రాయాన్ని ఇక్కడ ఉటంకించడం సముచితం, ఎందుకంటే అది వాస్తవాన్ని స్పష్టంగా చెబుతుంది: Livepatch “rebooting‌కు ప్రత్యామ్నాయం కాదు. షెడ్యూల్ చేయని reboots‌ను నిరోధించడం ద్వారా మీకు మరింత నియంత్రణ ఇచ్చే సాధనం.” ఇందులో అర్థాన్ని మోసే పదం షెడ్యూల్ చేయని. మీరు ఇంకా reboot చేయాలి. ఎప్పుడు చేయాలో మీరు నిర్ణయిస్తారు.

ఎలా reboot ను schedule చేసి, సిస్టమ్ మళ్లీ ప్రారంభమయ్యేలా చూడాలి

మీకు console ను చేరుకునే మార్గం లేకపోతే VPS reboot ఏకపక్ష చర్యగా మారుతుంది. reboot టైప్ చేయడానికి ముందు, machine తిరిగి రాకపోయినా మీరు మళ్లీ login చేయగలరని నిర్ధారించుకోండి.

• మీ provider control panel లో serial console లేదా VNC (virtual network computing) view అందిస్తున్నారో నిర్ధారించుకోండి. outage సమయంలో కాకుండా ఇప్పుడే దాన్ని తెరిచి ఉంచండి.
• df -h /boot తో ఖాళీ స్థలాన్ని పరిశీలించండి. /boot పూర్తిగా నిండితే initramfs (initial RAM filesystem) రాస్తున్న సమయంలో kernel package విఫలమవుతుంది. దాంతో పూర్తికాని image ను చూపించే bootloader entry మిగిలిపోవచ్చు.
• కనీసం ఒక సరిగ్గా పనిచేస్తున్న పాత kernel ను ఇన్‌స్టాల్ చేసి ఉంచండి. GRUB దాన్ని "Advanced options for Ubuntu" కింద చూపిస్తుంది. కొత్త kernel విఫలమైనప్పుడు దానితో boot చేయడం వేగవంతమైన recovery పద్ధతి.
• అవసరం రాకముందే మీ provider యొక్క rescue mode ను కనుగొనండి. reboot తర్వాత console లో initramfs prompt కనిపిస్తే, repair అక్కడే చేయాలి.

తర్వాత మీరు మేల్కొని ఉండే సమయంలో reboot ను schedule చేయండి:

sudo shutdown -r +5 "Kernel update, back in a moment"

ఇది reboot ను ఐదు నిమిషాల తర్వాత జరిగేలా schedule చేస్తుంది. అలాగే logged-in users కు message పంపుతుంది. sudo shutdown -c దాన్ని cancel చేస్తుంది. machine తిరిగి వచ్చిన తర్వాత రెండు అంశాలను నిర్ధారించండి:

uname -r
sudo canonical-livepatch status

uname -r ఇప్పుడు కొత్త kernel ను report చేయాలి. status output కూడా కొత్త series covered గా ఉందని report చేయాలి. machine అసలు తిరిగి రాకపోతే, సమస్య దాదాపు ఎల్లప్పుడూ network లో కాకుండా boot path లో ఉంటుంది. అప్పుడు recovery కోసం kernel update తర్వాత boot కాని VPS పై guide లోని విధానాన్ని ఉపయోగించాలి.

పాత kernels ను ఇంకా ఎందుకు శుభ్రం చేయాలి

Live patching ఈ సమస్యను తగ్గించకుండా మరింత పెంచుతుంది. ఎందుకంటే linux-image packages install అవుతూనే ఉన్నప్పుడు reboot చేయాల్సిన అవసరం తగ్గుతుంది. ప్రతి kernel ఒక boot image, ఒక initramfs, ఒక modules tree మరియు సాధారణంగా ఒక headers package ను install చేస్తుంది. కొన్ని వందల megabytes పరిమాణం ఉన్న ప్రత్యేక /boot partition కలిగిన చిన్న VPS లో మూడు లేదా నాలుగు kernels ఆ partition ను నింపేస్తాయి.

/boot పూర్తిగా నిండిపోతే తదుపరి kernel install విఫలమవుతుంది. దీనివల్ల యంత్రానికి అవసరమైన update ను కూడా install చేయలేని పరిస్థితి ఏర్పడుతుంది. apt autoremove విధానం పాత kernels ను తొలగించడానికి అర్హత వచ్చినప్పుడు వాటిని తొలగిస్తుంది. అయితే ఎప్పుడూ reboot చేయని యంత్రంలో అవి ఇంకా అర్హత పొందకపోవచ్చు. ఎందుకంటే మీరు ప్రస్తుతం ఉపయోగిస్తున్న kernel ను package manager తొలగించదు.

అందువల్ల install చేసిన kernels ను పరిశీలించండి. ప్రస్తుతం నడుస్తున్న kernel ను మరియు సరిగ్గా పనిచేస్తున్నదని నిర్ధారించిన ఒక fallback kernel ను ఉంచండి. మిగిలిన వాటిని Ubuntuలో పాత kernels ను సురక్షితంగా తొలగించే విధానం ఉపయోగించి తొలగించండి. uname -r ప్రస్తుతం చూపిస్తున్న kernel ను ఎప్పుడూ తొలగించవద్దు.

FAQ

Live kernel patching చేస్తే నా VPS ను ఎప్పటికీ reboot చేయాల్సిన అవసరం ఉండదా?

లేదు. Live patches నడుస్తున్న kernel లోకి load అవుతాయి. అవి boot image లో వ్రాయబడవు. అందువల్ల disk పై ఉన్న linux-image, మీరు boot చేసిన version వద్దనే ఉంటుంది. Canonical దీన్ని స్పష్టంగా చెబుతుంది: Livepatch "rebooting కు ప్రత్యామ్నాయం కాదు. అనియోజిత reboots ను నిరోధించడం ద్వారా మరింత నియంత్రణను అందించే సాధనం." మీ kernel series retired అయినప్పుడు coverage కూడా ముగుస్తుంది. Medium severity kernel fixes కు live patch ఎప్పుడూ అందించబడదు. ఒక reboot మీపై బలవంతంగా అమలయ్యే వరకు వేచి ఉండకుండా, మీరు ఎంచుకున్న వ్యవధి ప్రకారం maintenance reboot ను schedule చేయండి.

Live kernel patching నిజంగా patches ను apply చేస్తుందో ఎలా తనిఖీ చేయాలి?

sudo canonical-livepatch status ను run చేసి రెండు lines చదవండి. మీ running kernel series ను service cover చేస్తుందో లేదో kernel state చూపిస్తుంది. ఆ kernel కు సంబంధించిన patches load అయ్యాయో లేదో patch state చూపిస్తుంది. Loaded patch ఒక్కదానికి ఒక directory చొప్పున చూపించే ls /sys/kernel/livepatch/ తో kernel side ను కూడా నేరుగా తనిఖీ చేయవచ్చు. Listing ఖాళీగా ఉంటే, client ఏం చెబుతున్నా ప్రస్తుతం memory లో ఏదీ patch కాలేదు.

Personal VPS పై Ubuntu Pro ఉచితమా?

అవును, document చేసిన పరిమితిలో ఉచితం. Canonical ప్రకారం Ubuntu Pro "5 physical machines వరకు personal use కోసం ఉచితం, ఎల్లప్పుడూ ఉచితంగానే ఉంటుంది". August 2026 నాటికి official Ubuntu Community members కోసం ఈ పరిమితి 50 machines వరకు ఉంటుంది. Commercial use కు paid subscription అవసరం. మీ Ubuntu Pro account page నుంచి పొందిన token ను ఉపయోగించి sudo pro attach TOKEN తో machine ను attach చేయండి. తరువాత sudo pro enable livepatch తో service ను enable చేయండి.

Livepatch అమలైన తర్వాత కూడా kernel CVE unfixed గా ఎందుకు చూపిస్తుంది?

సాధారణంగా దీనికి రెండు కారణాల్లో ఒకటి ఉంటుంది. Fix severity threshold కంటే తక్కువ స్థాయిలో ఉండవచ్చు. ఎందుకంటే Canonical "critical మరియు high Common Vulnerability Scoring System (CVSS), Ubuntu Priority ratings కలిగిన kernel vulnerabilities కు" live patches అందిస్తుంది. మిగిలిన వాటిని disk పై ఉన్న package కు వదిలేస్తుంది. లేదా fix ను function body కు చేసిన మార్పుగా వ్యక్తీకరించడం సాధ్యం కాకపోవచ్చు. ఉదాహరణకు upstream data structure ను మార్చినప్పుడు ఇది జరుగుతుంది. ఇప్పటికే allocate అయిన objects పై ఆ మార్పును live patching సురక్షితంగా చేయలదు. రెండు సందర్భాల్లోనూ పరిష్కారం ఒకటే: updated kernel package ను install చేసి, దానిలోకి boot చేయండి.

Live kernel patching అసలు ఏవాటిని cover చేయదు?

Userspace ను cover చేయదు. Canonical స్పష్టంగా చెబుతుంది: Livepatch "OpenSSL లేదా glibc వంటి userspace libraries కు patch చేయదు, ఎందుకంటే అది unattended-upgrades లేదా systems management tool బాధ్యత." ఇది కొత్త kernel version లేదా కొత్త feature ను కూడా అందించలదు. ఎందుకంటే మీరు ఇప్పటికే నడుపుతున్న series లోని function bodies ను మాత్రమే ఇది replace చేస్తుంది. అలాగే __init functions కు patch చేయలదు. Server up అయ్యే సమయానికి అవి ఇప్పటికే run అయి memory నుంచి free అయి ఉంటాయి.