ਗੂਗਲ ਦੇ ਕੀਜ਼ ਕੁੱਕ ਨੇ ਲੀਨਕਸ ਕਰਨਲ ਵਿੱਚ ਬੱਗਾਂ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਆਧੁਨਿਕ ਬਣਾਉਣ ਲਈ ਕਿਹਾ

Kees Cook, kernel.org ਦੇ ਸਾਬਕਾ ਮੁੱਖ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਅਤੇ Ubuntu ਸੁਰੱਖਿਆ ਟੀਮ ਦੇ ਆਗੂ ਜੋ ਹੁਣ Android ਅਤੇ ChromeOS ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ Google 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਨੇ ਕਰਨਲ ਦੀਆਂ ਸਥਿਰ ਸ਼ਾਖਾਵਾਂ ਵਿੱਚ ਬੱਗ ਫਿਕਸ ਕਰਨ ਦੀ ਮੌਜੂਦਾ ਪ੍ਰਕਿਰਿਆ ਬਾਰੇ ਚਿੰਤਾ ਜ਼ਾਹਰ ਕੀਤੀ। ਹਰ ਹਫ਼ਤੇ, ਸਥਾਈ ਸ਼ਾਖਾਵਾਂ ਵਿੱਚ ਲਗਭਗ ਸੌ ਫਿਕਸ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਅਗਲੀ ਰੀਲੀਜ਼ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਵਿੰਡੋ ਦੇ ਬੰਦ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇਹ ਇੱਕ ਹਜ਼ਾਰ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ (ਸੰਚਾਲਕ ਵਿੰਡੋ ਦੇ ਬੰਦ ਹੋਣ ਤੱਕ ਫਿਕਸ ਨੂੰ ਰੱਖਦੇ ਹਨ, ਅਤੇ "ਦੇ ਬਣਨ ਤੋਂ ਬਾਅਦ. -rc1” ਉਹ ਇਕੱਠੇ ਕੀਤੇ ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਨ), ਜੋ ਕਿ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ ਅਤੇ ਲੀਨਕਸ ਕਰਨਲ ਦੇ ਆਧਾਰ 'ਤੇ ਰੱਖ-ਰਖਾਅ ਉਤਪਾਦਾਂ ਲਈ ਬਹੁਤ ਮਿਹਨਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਕੀਜ਼ ਦੇ ਅਨੁਸਾਰ, ਕਰਨਲ ਵਿੱਚ ਤਰੁੱਟੀਆਂ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਚਿਤ ਧਿਆਨ ਨਹੀਂ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਰਨਲ ਵਿੱਚ ਇਸ ਖੇਤਰ ਵਿੱਚ ਤਾਲਮੇਲ ਵਾਲੇ ਕੰਮ ਲਈ ਘੱਟੋ ਘੱਟ 100 ਵਾਧੂ ਡਿਵੈਲਪਰਾਂ ਦੀ ਘਾਟ ਹੈ। ਮੁੱਖ ਕਰਨਲ ਡਿਵੈਲਪਰ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਬੱਗਾਂ ਨੂੰ ਠੀਕ ਕਰਦੇ ਹਨ, ਪਰ ਇਸ ਗੱਲ ਦੀ ਕੋਈ ਗਾਰੰਟੀ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਫਿਕਸ ਤੀਜੀ ਧਿਰਾਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਕਰਨਲ ਰੂਪਾਂ ਤੱਕ ਪਹੁੰਚਾਏ ਜਾਣਗੇ। ਲੀਨਕਸ ਕਰਨਲ 'ਤੇ ਅਧਾਰਤ ਵੱਖ-ਵੱਖ ਉਤਪਾਦਾਂ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਕੋਲ ਇਹ ਨਿਯੰਤਰਣ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ ਕਿ ਕਿਹੜੇ ਬੱਗ ਫਿਕਸ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਡਿਵਾਈਸਾਂ ਵਿੱਚ ਕਿਹੜਾ ਕਰਨਲ ਵਰਤਿਆ ਗਿਆ ਹੈ। ਆਖਰਕਾਰ, ਨਿਰਮਾਤਾ ਆਪਣੇ ਉਤਪਾਦਾਂ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਜਿੰਮੇਵਾਰ ਹਨ, ਪਰ ਸਥਿਰ ਕਰਨਲ ਸ਼ਾਖਾਵਾਂ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਫਿਕਸਾਂ ਦੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਤੀਬਰਤਾ ਦੇ ਨਾਲ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵਿਕਲਪ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ - ਸਾਰੇ ਫਿਕਸ ਨੂੰ ਪੋਰਟ ਕਰੋ, ਚੁਣੇ ਹੋਏ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਨੂੰ ਪੋਰਟ ਕਰੋ, ਜਾਂ ਸਾਰੇ ਫਿਕਸ ਨੂੰ ਅਣਡਿੱਠ ਕਰੋ। .

ਸਰਵੋਤਮ ਹੱਲ ਸਿਰਫ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਫਿਕਸਾਂ ਅਤੇ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨਾ ਹੋਵੇਗਾ, ਪਰ ਅਜਿਹੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਆਮ ਪ੍ਰਵਾਹ ਤੋਂ ਵੱਖ ਕਰਨਾ ਮੁੱਖ ਸਮੱਸਿਆ ਹੈ। ਸਭ ਤੋਂ ਵੱਧ ਸਮੱਸਿਆਵਾਂ ਜਿਹੜੀਆਂ ਪੌਪ-ਅੱਪ ਹੁੰਦੀਆਂ ਹਨ ਉਹ C ਭਾਸ਼ਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਨਤੀਜਾ ਹਨ, ਜਿਸ ਲਈ ਮੈਮੋਰੀ ਅਤੇ ਪੁਆਇੰਟਰਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਬਹੁਤ ਧਿਆਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਮਾਮਲੇ ਨੂੰ ਹੋਰ ਬਦਤਰ ਬਣਾਉਣ ਲਈ, ਬਹੁਤ ਸਾਰੇ ਸੰਭਾਵੀ ਕਮਜ਼ੋਰ ਪੈਚ CVE ਪਛਾਣਕਰਤਾ ਦੇ ਨਾਲ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜਾਂ ਪੈਚ ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਣ ਤੋਂ ਕੁਝ ਸਮੇਂ ਬਾਅਦ ਇੱਕ CVE ਪਛਾਣਕਰਤਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਜਿਹੇ ਮਾਹੌਲ ਵਿੱਚ, ਨਿਰਮਾਤਾਵਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੁਰੱਖਿਆ ਮੁੱਦਿਆਂ ਤੋਂ ਮਾਮੂਲੀ ਫਿਕਸ ਨੂੰ ਵੱਖ ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ। ਅੰਕੜਿਆਂ ਦੇ ਅਨੁਸਾਰ, ਇੱਕ CVE ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ 40% ਤੋਂ ਵੱਧ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਨਿਸ਼ਚਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਫਿਕਸ ਦੇ ਜਾਰੀ ਹੋਣ ਅਤੇ ਇੱਕ CVE ਦੇ ਅਸਾਈਨਮੈਂਟ ਵਿੱਚ ਔਸਤਨ ਦੇਰੀ ਤਿੰਨ ਮਹੀਨੇ ਹੁੰਦੀ ਹੈ (ਅਰਥਾਤ, ਪਹਿਲਾਂ ਫਿਕਸ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ ਇੱਕ ਨਿਯਮਤ ਬੱਗ, ਪਰ ਕਈ ਮਹੀਨਿਆਂ ਬਾਅਦ ਹੀ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਕਮਜ਼ੋਰੀ ਠੀਕ ਹੋ ਗਈ ਹੈ)।

ਨਤੀਜੇ ਵਜੋਂ, ਕਮਜ਼ੋਰੀਆਂ ਲਈ ਫਿਕਸ ਦੇ ਨਾਲ ਵੱਖਰੀ ਸ਼ਾਖਾ ਦੇ ਬਿਨਾਂ ਅਤੇ ਕਿਸੇ ਖਾਸ ਸਮੱਸਿਆ ਦੇ ਸੁਰੱਖਿਆ ਕੁਨੈਕਸ਼ਨ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕੀਤੇ ਬਿਨਾਂ, ਲੀਨਕਸ ਕਰਨਲ 'ਤੇ ਅਧਾਰਤ ਉਤਪਾਦਾਂ ਦੇ ਨਿਰਮਾਤਾ ਨਵੀਨਤਮ ਸਥਿਰ ਸ਼ਾਖਾਵਾਂ ਤੋਂ ਲਗਾਤਾਰ ਸਾਰੇ ਫਿਕਸਾਂ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਲਈ ਛੱਡ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਪਰ ਇਸ ਕੰਮ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਮਜ਼ਦੂਰੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਪ੍ਰਤੀਕਿਰਿਆਸ਼ੀਲ ਤਬਦੀਲੀਆਂ ਦੇ ਉਭਰਨ ਦੇ ਡਰ ਕਾਰਨ ਕੰਪਨੀਆਂ ਵਿੱਚ ਵਿਰੋਧ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜੋ ਉਤਪਾਦ ਦੇ ਆਮ ਸੰਚਾਲਨ ਵਿੱਚ ਵਿਘਨ ਪਾ ਸਕਦੀਆਂ ਹਨ।

ਆਓ ਯਾਦ ਕਰੀਏ ਕਿ ਲਿਨਸ ਟੋਰਵਾਲਡਜ਼ ਦੇ ਅਨੁਸਾਰ, ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਹੋਰ ਕਿਸਮ ਦੀਆਂ ਤਰੁੱਟੀਆਂ ਤੋਂ ਵੱਖ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇੱਕ ਵੱਖਰੀ ਉੱਚ ਤਰਜੀਹ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਵੰਡਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਰਾਏ ਇਸ ਤੱਥ ਦੁਆਰਾ ਵਿਆਖਿਆ ਕੀਤੀ ਗਈ ਹੈ ਕਿ ਇੱਕ ਆਮ ਡਿਵੈਲਪਰ ਲਈ ਜੋ ਸੁਰੱਖਿਆ ਮੁੱਦਿਆਂ ਵਿੱਚ ਮੁਹਾਰਤ ਨਹੀਂ ਰੱਖਦਾ, ਇੱਕ ਫਿਕਸ ਅਤੇ ਇੱਕ ਸੰਭਾਵੀ ਕਮਜ਼ੋਰੀ ਵਿਚਕਾਰ ਸਬੰਧ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ (ਬਹੁਤ ਸਾਰੇ ਫਿਕਸਾਂ ਲਈ, ਸਿਰਫ ਇੱਕ ਵੱਖਰਾ ਆਡਿਟ ਇਹ ਸਮਝਣਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਸੁਰੱਖਿਆ ਨਾਲ ਸਬੰਧਤ ਹਨ। ). ਲਿਨਸ ਦੇ ਅਨੁਸਾਰ, ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਕਰਨਲ ਪੈਕੇਜਾਂ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਟੀਮਾਂ ਦੇ ਸੁਰੱਖਿਆ ਮਾਹਿਰਾਂ ਨੂੰ ਪੈਚਾਂ ਦੀ ਆਮ ਧਾਰਾ ਤੋਂ ਸੰਭਾਵੀ ਕਮਜ਼ੋਰੀਆਂ ਦੀ ਪਛਾਣ ਕਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਕੀਜ਼ ਕੁੱਕ ਦਾ ਮੰਨਣਾ ਹੈ ਕਿ ਵਾਜਬ ਲੰਬੇ ਸਮੇਂ ਦੀ ਲਾਗਤ 'ਤੇ ਕਰਨਲ ਸੁਰੱਖਿਆ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਦਾ ਇੱਕੋ ਇੱਕ ਹੱਲ ਹੈ ਕੰਪਨੀਆਂ ਲਈ ਫਿਕਸ ਨੂੰ ਪੋਰਟ ਕਰਨ ਵਿੱਚ ਸ਼ਾਮਲ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਸਥਾਨਕ ਕਰਨਲ ਬਿਲਡਜ਼ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਲਈ ਮੁੱਖ ਕਰਨਲ (ਅੱਪਸਟ੍ਰੀਮ) ਵਿੱਚ ਫਿਕਸਾਂ ਅਤੇ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਸੰਯੁਕਤ, ਤਾਲਮੇਲ ਵਾਲੇ ਯਤਨਾਂ ਵਿੱਚ ). ਇਸ ਦੇ ਮੌਜੂਦਾ ਰੂਪ ਵਿੱਚ, ਬਹੁਤ ਸਾਰੇ ਨਿਰਮਾਤਾ ਆਪਣੇ ਉਤਪਾਦਾਂ ਵਿੱਚ ਨਵੀਨਤਮ ਕਰਨਲ ਸੰਸਕਰਣਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹਨ ਅਤੇ ਘਰ ਵਿੱਚ ਫਿਕਸ ਨੂੰ ਬੈਕਪੋਰਟ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ. ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਵੱਖ-ਵੱਖ ਕੰਪਨੀਆਂ ਵਿੱਚ ਇੰਜੀਨੀਅਰ ਇੱਕੋ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹੋਏ, ਇੱਕ ਦੂਜੇ ਦੇ ਕੰਮ ਦੀ ਨਕਲ ਕਰਦੇ ਹਨ.

ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ 10 ਕੰਪਨੀਆਂ, ਹਰੇਕ ਇੱਕ ਇੰਜਨੀਅਰ ਦੇ ਨਾਲ ਇੱਕੋ ਫਿਕਸ ਨੂੰ ਬੈਕਪੋਰਟ ਕਰ ਰਿਹਾ ਹੈ, ਉਹਨਾਂ ਇੰਜਨੀਅਰਾਂ ਨੂੰ ਅੱਪਸਟ੍ਰੀਮ ਵਿੱਚ ਬੱਗ ਫਿਕਸ ਕਰਨ ਲਈ ਦੁਬਾਰਾ ਨਿਯੁਕਤ ਕੀਤਾ ਹੈ, ਤਾਂ ਇੱਕ ਫਿਕਸ ਨੂੰ ਬੈਕਪੋਰਟ ਕਰਨ ਦੀ ਬਜਾਏ, ਉਹ ਸਾਂਝੇ ਲਾਭ ਲਈ 10 ਵੱਖ-ਵੱਖ ਬੱਗ ਠੀਕ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜਾਂ ਪ੍ਰਸਤਾਵਿਤ ਦੀ ਸਮੀਖਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਬਦਲਦਾ ਹੈ ਅਤੇ ਬੱਗੀ ਕੋਡ ਨੂੰ ਕਰਨਲ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਸੰਸਾਧਨਾਂ ਨੂੰ ਕੋਡ ਦੀ ਜਾਂਚ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਨਵੇਂ ਟੂਲ ਬਣਾਉਣ ਲਈ ਵੀ ਸਮਰਪਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਵਾਰ-ਵਾਰ ਆਉਣ ਵਾਲੀਆਂ ਆਮ ਸ਼੍ਰੇਣੀਆਂ ਦੀਆਂ ਗਲਤੀਆਂ ਦਾ ਛੇਤੀ ਪਤਾ ਲਗਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ।

ਕੀਜ਼ ਕੁੱਕ ਵੀ ਕਰਨਲ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸਵੈਚਲਿਤ ਅਤੇ ਫਜ਼ਿੰਗ ਟੈਸਟਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨ, ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਅਤੇ ਈਮੇਲ ਦੁਆਰਾ ਪੁਰਾਤਨ ਵਿਕਾਸ ਪ੍ਰਬੰਧਨ ਨੂੰ ਛੱਡਣ ਦਾ ਸੁਝਾਅ ਵੀ ਦਿੰਦਾ ਹੈ। ਵਰਤਮਾਨ ਵਿੱਚ, ਪ੍ਰਭਾਵੀ ਟੈਸਟਿੰਗ ਇਸ ਤੱਥ ਦੁਆਰਾ ਅੜਿੱਕਾ ਹੈ ਕਿ ਮੁੱਖ ਜਾਂਚ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਵਿਕਾਸ ਤੋਂ ਵੱਖ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਰੀਲੀਜ਼ ਬਣਨ ਤੋਂ ਬਾਅਦ ਹੁੰਦਾ ਹੈ। ਕੀਜ਼ ਨੇ ਅਜਿਹੀਆਂ ਭਾਸ਼ਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਵੀ ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ ਜੋ ਉੱਚ ਪੱਧਰੀ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਜੰਗਾਲ, ਜਦੋਂ ਤਰੁੱਟੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਘਟਾਉਣ ਲਈ ਵਿਕਸਿਤ ਹੁੰਦਾ ਹੈ।

ਸਰੋਤ: opennet.ru