ಕೀಸ್ ಕುಕ್ ನಾನು ಇದರಲ್ಲಿ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ಮಾಡುತ್ತೇನೆ ಬಗ್ ಫಿಕ್ಸಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯ ಬಗ್ಗೆ ಕಳವಳ ಮೂಡಿಸಿದೆ ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ನ ಸ್ಥಿರವಾದ ಶಾಖೆಗಳಲ್ಲಿ ಮುಂದುವರಿದಿದೆ ಮತ್ತು ಅದು ವಾರದಿಂದ ವಾರಕ್ಕೆ ಸುಮಾರು ನೂರು ತಿದ್ದುಪಡಿಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ ಎಂದು ಉಲ್ಲೇಖಿಸಿ ಸ್ಥಿರ ಶಾಖೆಗಳ ಮೇಲೆ, ಇದು ತುಂಬಾ ಹೆಚ್ಚು ಮತ್ತು ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಆಧಾರಿತ ಉತ್ಪನ್ನಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಕಷ್ಟು ಪ್ರಯತ್ನದ ಅಗತ್ಯವಿದೆ.
ಕೀಸ್ ಪ್ರಕಾರ, ಕರ್ನಲ್ ದೋಷ ನಿರ್ವಹಣೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಕರ್ನಲ್ ಕನಿಷ್ಠ 100 ಹೆಚ್ಚುವರಿ ಡೆವಲಪರ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ ಈ ಪ್ರದೇಶದಲ್ಲಿ ಸಂಘಟಿತ ರೀತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು. ಪ್ರಮುಖ ಕರ್ನಲ್ ಡೆವಲಪರ್‌ಗಳು ನಿಯಮಿತವಾಗಿ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತಾರೆ ಎಂದು ನಮೂದಿಸುವುದರ ಜೊತೆಗೆ, ಈ ಪರಿಹಾರಗಳು ಮೂರನೇ ಪಕ್ಷದ ಕರ್ನಲ್ ರೂಪಾಂತರಗಳಿಗೆ ಸಾಗುತ್ತವೆ ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ಗ್ಯಾರಂಟಿ ಇಲ್ಲ.
ಹಾಗೆ ಮಾಡುವಾಗ, ವಿವಿಧ ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಆಧಾರಿತ ಉತ್ಪನ್ನಗಳ ಬಳಕೆದಾರರು ತಮ್ಮ ದೋಷಗಳಲ್ಲಿ ಯಾವ ದೋಷಗಳನ್ನು ನಿವಾರಿಸಲಾಗಿದೆ ಮತ್ತು ಯಾವ ಕರ್ನಲ್ ಅನ್ನು ಬಳಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ ಎಂದು ಅವರು ಉಲ್ಲೇಖಿಸಿದ್ದಾರೆ. ಅಂತಿಮವಾಗಿ, ಮಾರಾಟಗಾರರು ತಮ್ಮ ಉತ್ಪನ್ನಗಳ ಭದ್ರತೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ, ಆದರೆ ಸ್ಥಿರವಾದ ಕರ್ನಲ್ ಶಾಖೆಗಳಲ್ಲಿ ಅತಿ ಹೆಚ್ಚಿನ ದರಗಳನ್ನು ಎದುರಿಸುತ್ತಿದ್ದರು, ಅವರು ಎಲ್ಲಾ ಪ್ಯಾಚ್‌ಗಳನ್ನು ವಲಸೆ ಮಾಡುವ ಆಯ್ಕೆಯನ್ನು ಎದುರಿಸಿದರು, ಆಯ್ದ ಪ್ರಮುಖವಾದವುಗಳನ್ನು ವಲಸೆ ಮಾಡಿದರು ಅಥವಾ ಎಲ್ಲಾ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಕಡೆಗಣಿಸಿದರು. .
ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಕರ್ನಲ್ ಡೆವಲಪರ್‌ಗಳು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಬಹುದು, ಆದರೆ ಡೌನ್‍ಸ್ಟ್ರೀಮ್ ಮಾರಾಟಗಾರರು ತಮ್ಮ ಉತ್ಪನ್ನಗಳಲ್ಲಿ ಅಳವಡಿಸಲು ಯಾವ ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ ಎಂಬುದರ ಮೇಲೆ ಅವರಿಗೆ ನಿಯಂತ್ರಣವಿಲ್ಲ. ಅಂತಿಮ ಬಳಕೆದಾರರು ತಮ್ಮ ಉತ್ಪನ್ನಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು, ಆದರೆ ಯಾವ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆ ಅಥವಾ ಯಾವ ಕರ್ನಲ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಅವರಿಗೆ ಯಾವುದೇ ನಿಯಂತ್ರಣವಿರುವುದಿಲ್ಲ (ಸ್ವತಃ ಮತ್ತು ಒಂದು ಸಮಸ್ಯೆ). ಅಂತಿಮವಾಗಿ, ಮಾರಾಟಗಾರರು ತಮ್ಮ ಉತ್ಪನ್ನ ಕೋರ್‌ಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿರಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿರುತ್ತಾರೆ.
ಕೀಸ್ ಕುಕ್ ಸೂಕ್ತ ಪರಿಹಾರವೆಂದರೆ ಪ್ರಮುಖ ಪರಿಹಾರಗಳು ಮತ್ತು ದೋಷಗಳನ್ನು ಮಾತ್ರ ವರ್ಗಾಯಿಸುವುದು ಎಂದು ಸೂಚಿಸುತ್ತದೆ, ಆದರೆ ಮುಖ್ಯ ಸಮಸ್ಯೆ ಎಂದರೆ ಈ ದೋಷಗಳನ್ನು ಸಾಮಾನ್ಯ ಹರಿವಿನಿಂದ ಬೇರ್ಪಡಿಸುವುದು, ಏಕೆಂದರೆ ಹೆಚ್ಚಿನ ಉದಯೋನ್ಮುಖ ಸಮಸ್ಯೆಗಳು ಸಿ ಭಾಷೆಯ ಬಳಕೆಯ ಪರಿಣಾಮವಾಗಿದೆ, ಇದು ಮೆಮೊರಿ ಮತ್ತು ಪಾಯಿಂಟರ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಹೆಚ್ಚಿನ ಕಾಳಜಿಯ ಅಗತ್ಯವಿರುತ್ತದೆ.
ವಿಷಯಗಳನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸಲು, ಅನೇಕ ಸಂಭಾವ್ಯ ದುರ್ಬಲತೆ ಪರಿಹಾರಗಳನ್ನು CVE ಗುರುತಿಸುವಿಕೆಗಳೊಂದಿಗೆ ಟ್ಯಾಗ್ ಮಾಡಲಾಗಿಲ್ಲ ಅಥವಾ ಪ್ಯಾಚ್ ಬಿಡುಗಡೆಯಾದ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ CVE ಗುರುತಿಸುವಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ.
ಅಂತಹ ವಾತಾವರಣದಲ್ಲಿ, ತಯಾರಕರು ಸಣ್ಣ ಭದ್ರತೆಗಳನ್ನು ಪ್ರಮುಖ ಭದ್ರತಾ ಸಮಸ್ಯೆಗಳಿಂದ ಬೇರ್ಪಡಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ. ಅಂಕಿಅಂಶಗಳ ಪ್ರಕಾರ, CVE ನಿಯೋಜನೆಯ ಮೊದಲು 40% ಕ್ಕಿಂತ ಹೆಚ್ಚು ದೋಷಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ, ಮತ್ತು ಸರಾಸರಿ ಫಿಕ್ಸ್ ಬಿಡುಗಡೆ ಮತ್ತು CVE ನಿಯೋಜನೆಯ ನಡುವಿನ ವಿಳಂಬವು ಮೂರು ತಿಂಗಳುಗಳು (ಅಂದರೆ, ಆರಂಭದಲ್ಲಿ, ಸಾಮಾನ್ಯ ತಪ್ಪು ಎಂದು ಪರಿಹಾರವನ್ನು ಗ್ರಹಿಸುತ್ತದೆ,
ಪರಿಣಾಮವಾಗಿ, ದೋಷಗಳಿಗೆ ಪರಿಹಾರಗಳೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಶಾಖೆಯನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು ಈ ಅಥವಾ ಆ ಸಮಸ್ಯೆಯ ಭದ್ರತೆಯೊಂದಿಗೆ ಸಂಪರ್ಕದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿಲ್ಲ, ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಆಧಾರಿತ ಉತ್ಪನ್ನಗಳ ತಯಾರಕರು ನಿರಂತರವಾಗಿ ಎಲ್ಲಾ ಪರಿಹಾರಗಳನ್ನು ವರ್ಗಾಯಿಸಬೇಕಾಗುತ್ತದೆ ಹೊಸ ಸ್ಥಿರ ಶಾಖೆಗಳ ಆದರೆ ಈ ಕೆಲಸವು ಕಾರ್ಮಿಕ-ತೀವ್ರವಾಗಿದೆ ಮತ್ತು ಉತ್ಪನ್ನದ ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಅಡ್ಡಿಪಡಿಸುವ ಹಿಂಜರಿತದ ಬದಲಾವಣೆಗಳ ಭಯದಿಂದಾಗಿ ಕಂಪನಿಗಳಿಂದ ಪ್ರತಿರೋಧವನ್ನು ಎದುರಿಸುತ್ತಿದೆ.
ಕೀಸ್ ಕುಕ್ ದೀರ್ಘಾವಧಿಯಲ್ಲಿ ಕರ್ನಲ್ ಅನ್ನು ಸಮಂಜಸವಾದ ವೆಚ್ಚದಲ್ಲಿ ಸುರಕ್ಷಿತವಾಗಿರಿಸಲು ಇರುವ ಏಕೈಕ ಪರಿಹಾರವೆಂದರೆ ಪ್ಯಾಚ್ ಎಂಜಿನಿಯರ್‌ಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸುವುದು ಕ್ರೇಜಿ ಕರ್ನಲ್ ನಿರ್ಮಾಣಕ್ಕೆನಾನು ಸಂಘಟಿತ ರೀತಿಯಲ್ಲಿ ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಕರ್ನಲ್‌ನಲ್ಲಿ ತೇಪೆಗಳು ಮತ್ತು ದೋಷಗಳನ್ನು ನಿರ್ವಹಿಸಲು. ಅದರಂತೆ, ಅನೇಕ ಮಾರಾಟಗಾರರು ತಮ್ಮ ಉತ್ಪನ್ನಗಳಲ್ಲಿ ಇತ್ತೀಚಿನ ಕರ್ನಲ್ ಆವೃತ್ತಿಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ ಮತ್ತು ತಮ್ಮದೇ ಆದ ಬ್ಯಾಕ್‌ಪೋರ್ಟ್ ಫಿಕ್ಸ್‌ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ, ಅಂದರೆ, ಬೇರೆ ಬೇರೆ ಕಂಪನಿಗಳ ಎಂಜಿನಿಯರ್‌ಗಳು ಪರಸ್ಪರರ ಕೆಲಸವನ್ನು ನಕಲು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತಾರೆ.
ಉದಾಹರಣೆಗೆ, 10 ಕಂಪನಿಗಳು, ಪ್ರತಿಯೊಂದೂ ಇಂಜಿನಿಯರ್ ಒಂದೇ ಪರಿಹಾರಗಳನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ಈ ಎಂಜಿನಿಯರ್‌ಗಳನ್ನು ದೋಷಗಳನ್ನು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ, ಒಂದು ಫಿಕ್ಸ್ ಅನ್ನು ವಲಸೆ ಮಾಡುವ ಬದಲು, ಅವರು ಒಟ್ಟಾರೆ ಲಾಭಕ್ಕಾಗಿ 10 ವಿಭಿನ್ನ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಬಹುದು ಅಥವಾ ದೋಷಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಒಟ್ಟಾಗಿ ಬರಬಹುದು. . ಮತ್ತು ದೋಷಯುಕ್ತ ಕೋಡ್ ಅನ್ನು ಕರ್ನಲ್‌ನಲ್ಲಿ ಸೇರಿಸುವುದನ್ನು ತಪ್ಪಿಸಿ. ಹೊಸ ಕೋಡ್ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಪರೀಕ್ಷಾ ಸಾಧನಗಳನ್ನು ರಚಿಸಲು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸಬಹುದು, ಇದು ಆರಂಭಿಕ ಹಂತದಲ್ಲಿ ಪದೇ ಪದೇ ಬೆಳೆಯುವ ವಿಶಿಷ್ಟ ದೋಷ ತರಗತಿಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪತ್ತೆ ಮಾಡುತ್ತದೆ.
ಕೀಸ್ ಕುಕ್ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ ಮತ್ತು ಅಸ್ಪಷ್ಟತೆಯನ್ನು ಹೆಚ್ಚು ಸಕ್ರಿಯವಾಗಿ ಬಳಸಲು ಸಹ ಪ್ರಸ್ತಾಪಿಸುತ್ತದೆ ನೇರವಾಗಿ ಕರ್ನಲ್ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ನಿರಂತರ ಏಕೀಕರಣ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಬಳಸಿ ಮತ್ತು ಇ-ಮೇಲ್ ಮೂಲಕ ಅಭಿವೃದ್ಧಿಯ ಪುರಾತನ ನಿರ್ವಹಣೆಯನ್ನು ತ್ಯಜಿಸಿ.
ಮೂಲ: https://security.googleblog.com