Làm thế nào để một phân đoạn lỗi hoạt động dưới mui xe?

Tôi dường như không thể tìm thấy bất kỳ thông tin nào về điều này ngoài "MMU của CPU gửi tín hiệu" và "hạt nhân hướng nó đến chương trình vi phạm, chấm dứt nó".

Tôi giả định rằng nó có thể gửi tín hiệu đến vỏ và vỏ xử lý nó bằng cách chấm dứt quá trình vi phạm và in "Segmentation fault". Vì vậy, tôi đã kiểm tra giả định đó bằng cách viết một shell cực kỳ nhỏ mà tôi gọi là crsh (crap shell). Shell này không làm gì cả ngoại trừ lấy đầu vào của người dùng và đưa nó vào system()phương thức.

#include <stdio.h>
#include <stdlib.h>

int main(){
    char cmdbuf[1000];
    while (1){
        printf("Crap Shell> ");
        fgets(cmdbuf, 1000, stdin);
        system(cmdbuf);
    }
}

Vì vậy, tôi đã chạy lớp vỏ này trong một thiết bị đầu cuối trần (không bashchạy bên dưới). Sau đó, tôi đã tiến hành chạy một chương trình tạo ra một segfault. Nếu các giả định của tôi là chính xác, thì đây sẽ là một) sự cố crsh, đóng xterm, b) không in "Segmentation fault"hoặc c) cả hai.

braden@system ~/code/crsh/ $ xterm -e ./crsh
Crap Shell> ./segfault
Segmentation fault
Crap Shell> [still running]

Quay lại vuông một, tôi đoán. Tôi đã chứng minh rằng nó không phải là cái vỏ làm điều này, mà là hệ thống bên dưới. Làm thế nào để "phân đoạn lỗi" thậm chí được in? "Ai" đang làm điều đó? Hạt nhân? Thứ gì khác? Làm thế nào để tín hiệu và tất cả các tác dụng phụ của nó truyền từ phần cứng đến sự chấm dứt cuối cùng của chương trình?

Tất cả các CPU hiện đại có khả năng làm gián đoạn hướng dẫn máy hiện đang thực thi. Họ lưu đủ trạng thái (thông thường, nhưng không phải luôn luôn, trên ngăn xếp) để có thể tiếp tục thực hiện sau đó, như thể không có gì xảy ra (thông thường lệnh bị gián đoạn sẽ được khởi động lại từ đầu). Sau đó, họ bắt đầu thực hiện một trình xử lý ngắt , chỉ là mã máy nhiều hơn, nhưng được đặt tại một vị trí đặc biệt để CPU biết vị trí của nó trước. Trình xử lý ngắt luôn là một phần của hạt nhân của hệ điều hành: thành phần chạy với đặc quyền lớn nhất và chịu trách nhiệm giám sát việc thực hiện tất cả các thành phần khác. ^1,2

Các ngắt có thể là đồng bộ , có nghĩa là chúng được kích hoạt bởi chính CPU như là một phản ứng trực tiếp với một thứ mà lệnh hiện đang thực hiện, hoặc không đồng bộ , nghĩa là chúng xảy ra vào thời điểm không thể đoán trước do sự kiện bên ngoài, như dữ liệu đến trên mạng Hải cảng. Một số người bảo lưu thuật ngữ "ngắt" cho các ngắt không đồng bộ và gọi các ngắt đồng bộ là "bẫy", "lỗi" hoặc "ngoại lệ", nhưng những từ đó đều có nghĩa khác nên tôi sẽ gắn với "ngắt đồng bộ".

Bây giờ, hầu hết các hệ điều hành hiện đại đều có khái niệm về các quy trình . Về cơ bản nhất, đây là một cơ chế trong đó máy tính có thể chạy nhiều chương trình cùng một lúc, nhưng nó cũng là một khía cạnh quan trọng trong cách các hệ điều hành cấu hình bảo vệ bộ nhớ , là một tính năng của hầu hết (nhưng, than ôi, vẫn chưa phải là tất cả ) CPU hiện đại. Nó đi cùng với bộ nhớ ảo, đó là khả năng thay đổi ánh xạ giữa các địa chỉ bộ nhớ và vị trí thực tế trong RAM. Bảo vệ bộ nhớ cho phép hệ điều hành cung cấp cho mỗi tiến trình một đoạn RAM riêng, chỉ có nó mới có thể truy cập. Nó cũng cho phép hệ điều hành (thay mặt một số tiến trình) chỉ định các vùng RAM là chỉ đọc, thực thi, được chia sẻ giữa một nhóm các quy trình hợp tác, v.v. Cũng sẽ có một đoạn bộ nhớ chỉ có thể truy cập được bởi nhân. ³

Miễn là mỗi tiến trình chỉ truy cập bộ nhớ theo cách mà CPU được cấu hình để cho phép, bảo vệ bộ nhớ là vô hình. Khi một quá trình phá vỡ các quy tắc, CPU sẽ tạo ra một ngắt đồng bộ, yêu cầu kernel sắp xếp mọi thứ. Nó thường xảy ra rằng quá trình không thực sự phá vỡ các quy tắc, chỉ có kernel cần thực hiện một số công việc trước khi quá trình có thể được phép tiếp tục. Chẳng hạn, nếu một trang trong bộ nhớ của một tiến trình cần được "đuổi" sang tệp hoán đổi để giải phóng không gian trong RAM cho một thứ khác, thì kernel sẽ đánh dấu trang đó không thể truy cập được. Lần tiếp theo quá trình cố gắng sử dụng nó, CPU sẽ tạo ra một ngắt bảo vệ bộ nhớ; hạt nhân sẽ lấy lại trang từ trao đổi, đặt nó trở lại vị trí cũ, đánh dấu nó có thể truy cập lại và tiếp tục thực hiện.

Nhưng giả sử rằng quá trình thực sự đã phá vỡ các quy tắc. Nó đã cố gắng truy cập một trang chưa bao giờ có bất kỳ RAM nào được ánh xạ tới nó hoặc nó đã cố thực thi một trang được đánh dấu là không chứa mã máy hoặc bất cứ thứ gì. Họ các hệ điều hành thường được gọi là "Unix" đều sử dụng tín hiệu để xử lý tình huống này. ⁴ Tín hiệu tương tự như các ngắt, nhưng chúng được tạo bởi kernel và được xử lý bởi các tiến trình, thay vì được tạo bởi phần cứng và được tạo bởi kernel. Quá trình có thể xác định xử lý tín hiệutrong mã riêng của họ và cho biết kernel đang ở đâu. Những bộ xử lý tín hiệu sau đó sẽ thực thi, làm gián đoạn dòng điều khiển thông thường, khi cần thiết. Tất cả các tín hiệu đều có một số và hai tên, một trong số đó là từ viết tắt khó hiểu và tên còn lại là một cụm từ ít khó hiểu hơn. Tín hiệu được tạo ra khi một quá trình phá vỡ các quy tắc bảo vệ bộ nhớ là (theo quy ước) số 11, và tên của nó là SIGSEGVvà "Lỗi phân đoạn". ^5,6

Một sự khác biệt quan trọng giữa tín hiệu và ngắt là có một hành vi mặc định cho mọi tín hiệu. Nếu hệ điều hành không xác định trình xử lý cho tất cả các ngắt, đó là lỗi trong HĐH và toàn bộ máy tính sẽ gặp sự cố khi CPU cố gắng gọi trình xử lý bị thiếu. Nhưng các quy trình không có nghĩa vụ xác định các bộ xử lý tín hiệu cho tất cả các tín hiệu. Nếu kernel tạo tín hiệu cho một tiến trình và tín hiệu đó bị bỏ lại ở hành vi mặc định của nó, kernel sẽ tiếp tục và làm bất cứ điều gì mặc định và không làm phiền quá trình. Hầu hết các hành vi mặc định của tín hiệu là "không làm gì" hoặc "chấm dứt quá trình này và cũng có thể tạo ra kết xuất lõi". SIGSEGVlà một trong những cái sau

Vì vậy, để tóm tắt lại, chúng ta có một quy trình phá vỡ các quy tắc bảo vệ bộ nhớ. CPU đã đình chỉ quá trình và tạo ra một ngắt đồng bộ. Hạt nhân đã ngắt trường và tạo SIGSEGVtín hiệu cho quá trình. Giả sử quy trình không thiết lập trình xử lý tín hiệu SIGSEGV, vì vậy kernel thực hiện hành vi mặc định, đó là chấm dứt quá trình. Điều này có tất cả các hiệu ứng giống như _exitcuộc gọi hệ thống: các tệp đang mở bị đóng, bộ nhớ bị giải phóng, v.v.

Cho đến thời điểm này, không có gì có thể in ra bất kỳ thông điệp nào mà con người có thể nhìn thấy, và vỏ (hay nói chung hơn là quá trình cha mẹ của quá trình vừa bị chấm dứt) hoàn toàn không được tham gia. SIGSEGVđi đến quá trình phá vỡ các quy tắc, không phải cha mẹ của nó. Tuy nhiên, bước tiếp theo trong chuỗi là thông báo cho quá trình cha mẹ rằng con của nó đã bị chấm dứt. Điều này có thể xảy ra theo nhiều cách khác nhau, trong đó đơn giản nhất là khi phụ huynh đang đợi thông báo này, bằng một trong những waitcuộc gọi hệ thống ( wait, waitpid, wait4, vv). Trong trường hợp đó, kernel sẽ chỉ khiến cuộc gọi hệ thống đó trả về và cung cấp cho tiến trình cha một số mã được gọi là trạng thái thoát. ⁷ Trạng thái thoát thông báo cho cha mẹ tại sao quá trình con bị chấm dứt; trong trường hợp này, nó sẽ biết rằng đứa trẻ đã bị chấm dứt do hành vi mặc định của SIGSEGVtín hiệu.

Quá trình cha mẹ sau đó có thể báo cáo sự kiện cho con người bằng cách in một tin nhắn; chương trình shell hầu như luôn luôn làm điều này. Mã của bạn crshkhông bao gồm mã để làm điều đó, nhưng dù sao thì nó cũng xảy ra, bởi vì thói quen của thư viện C systemchạy một trình bao đầy đủ tính năng /bin/sh, "dưới mui xe". crshlà ông bà trong kịch bản này; thông báo tiến trình cha mẹ được điền vào /bin/sh, trong đó in thông báo thông thường của nó. Sau đó, /bin/shnó tự thoát, vì nó không còn gì để làm và việc triển khai thư viện C systemnhận được thông báo thoát đó . Bạn có thể thấy thông báo thoát đó trong mã của mình, bằng cách kiểm tra giá trị trả về củasystem; nhưng nó sẽ không cho bạn biết rằng quá trình cháu đã chết trên một segfault, bởi vì nó được tiêu thụ bởi quá trình vỏ trung gian.

Chú thích

1. Một số hệ điều hành không triển khai trình điều khiển thiết bị như một phần của kernel; tuy nhiên, tất cả các trình xử lý ngắt vẫn phải là một phần của kernel và mã cũng cấu hình bảo vệ bộ nhớ, vì phần cứng không cho phép bất cứ thứ gì ngoại trừ kernel làm những việc này.

2. Có thể có một chương trình gọi là "trình ảo hóa" hoặc "trình quản lý máy ảo" thậm chí còn đặc quyền hơn kernel, nhưng với mục đích của câu trả lời này, nó có thể được coi là một phần của phần cứng .

3. Nhân là một chương trình , nhưng nó không phải là một quá trình; nó giống như một thư viện Tất cả các quy trình thực hiện các phần của mã của hạt nhân, theo thời gian, ngoài mã riêng của họ. Có thể có một số "chuỗi nhân" chỉ thực thi mã hạt nhân, nhưng chúng không liên quan đến chúng tôi ở đây.

4. Hệ điều hành một và duy nhất mà bạn có khả năng sẽ phải đối phó nữa mà không thể coi là một triển khai của Unix, tất nhiên, là Windows. Nó không sử dụng tín hiệu trong tình huống này. (Thật vậy, nó không có tín hiệu; trên Windows <signal.h>giao diện hoàn toàn bị giả mạo bởi thư viện C.) Thay vào đó, nó sử dụng một cái gì đó gọi là " xử lý ngoại lệ có cấu trúc ".

5. Một số vi phạm bảo vệ bộ nhớ tạo ra SIGBUS("Lỗi xe buýt") thay vì SIGSEGV. Dòng giữa hai là không xác định và thay đổi từ hệ thống để hệ thống. Nếu bạn đã viết một chương trình xác định trình xử lý cho SIGSEGVthì có lẽ nên xác định trình xử lý tương tự SIGBUS.

6. "Lỗi phân đoạn" là tên của ngắt được tạo ra do vi phạm bảo vệ bộ nhớ bởi một trong những máy tính chạy Unix gốc , có thể là PDP-11 . " Phân đoạn " là một loại bảo vệ bộ nhớ, nhưng ngày nay thuật ngữ " lỗi phân đoạn " nói chung cho bất kỳ loại vi phạm bảo vệ bộ nhớ nào.

7. Tất cả các cách khác mà quá trình cha mẹ có thể được thông báo về một đứa trẻ đã chấm dứt, kết thúc bằng việc cha mẹ gọi waitvà nhận được trạng thái thoát. Chỉ là một cái gì đó khác xảy ra đầu tiên.

Shell thực sự có liên quan đến thông điệp đó và crshgián tiếp gọi shell, có lẽ là vậy bash.

Tôi đã viết một chương trình C nhỏ luôn phân tách lỗi:

#include <stdio.h>

int
main(int ac, char **av)
{
        int *i = NULL;

        *i = 12;

        return 0;
}

Khi tôi chạy nó từ shell mặc định của mình zsh, tôi nhận được điều này:

4 % ./segv
zsh: 13512 segmentation fault  ./segv

Khi tôi chạy nó từ bash, tôi nhận được những gì bạn lưu ý trong câu hỏi của bạn:

bediger@flq123:csrc % ./segv
Segmentation fault

Tôi sẽ viết một trình xử lý tín hiệu trong mã của mình, sau đó tôi nhận ra rằng system()cuộc gọi thư viện được sử dụng bởi crshexec's shell, /bin/shtheo man 3 system. Điều đó /bin/shgần như chắc chắn in ra "Lỗi phân đoạn", vì crshchắc chắn là không.

Nếu bạn viết crshlại để sử dụng lệnh execve()gọi hệ thống để chạy chương trình, bạn sẽ không thấy chuỗi "Lỗi phân đoạn". Nó đến từ vỏ được gọi bởi system().

Tôi dường như không thể tìm thấy bất kỳ thông tin nào về điều này ngoài "MMU của CPU gửi tín hiệu" và "hạt nhân hướng nó đến chương trình vi phạm, chấm dứt nó".

Đây là một chút tóm tắt bị cắt xén. Cơ chế tín hiệu Unix hoàn toàn khác với các sự kiện dành riêng cho CPU bắt đầu quá trình.

Nói chung, khi một địa chỉ xấu được truy cập (hoặc được ghi vào vùng chỉ đọc, cố gắng thực thi một phần không thể thực thi, v.v.), CPU sẽ tạo ra một số sự kiện dành riêng cho CPU (trên các kiến ​​trúc không VM truyền thống, đây là được gọi là vi phạm phân đoạn, vì mỗi "phân đoạn" (theo truyền thống, "văn bản" có thể thực thi chỉ đọc, "dữ liệu" có thể ghi và có độ dài thay đổi và ngăn xếp theo truyền thống ở đầu đối diện của bộ nhớ) có một dải địa chỉ cố định - trên một kiến ​​trúc hiện đại, nhiều khả năng đó là lỗi trang [đối với bộ nhớ chưa được xử lý] hoặc vi phạm quyền truy cập [để đọc, viết và thực thi các vấn đề về quyền], và tôi sẽ tập trung vào vấn đề này cho phần còn lại của câu trả lời).

Bây giờ, tại thời điểm này, kernel có thể làm một số điều. Lỗi trang cũng được tạo cho bộ nhớ hợp lệ nhưng không được tải (ví dụ: bị tráo đổi hoặc trong tệp bị khóa, v.v.) và trong trường hợp này, kernel sẽ ánh xạ bộ nhớ và sau đó khởi động lại chương trình người dùng từ hướng dẫn gây ra lỗi. Nếu không, nó sẽ gửi một tín hiệu. Điều này không chính xác "trực tiếp [sự kiện ban đầu] với chương trình vi phạm", vì quá trình cài đặt trình xử lý tín hiệu là khác nhau và chủ yếu là độc lập với kiến ​​trúc, so với nếu chương trình được dự kiến ​​mô phỏng cài đặt trình xử lý ngắt.

Nếu chương trình người dùng đã cài đặt trình xử lý tín hiệu, điều này có nghĩa là tạo khung ngăn xếp và đặt vị trí thực thi của chương trình người dùng thành trình xử lý tín hiệu. Điều tương tự cũng được thực hiện cho tất cả các tín hiệu, nhưng trong trường hợp vi phạm phân đoạn, mọi thứ thường được sắp xếp sao cho nếu trình xử lý tín hiệu trả về, nó sẽ khởi động lại lệnh gây ra lỗi. Chương trình người dùng có thể đã sửa lỗi, ví dụ: bằng cách ánh xạ bộ nhớ đến địa chỉ vi phạm - nó phụ thuộc vào kiến ​​trúc cho dù điều này là có thể). Trình xử lý tín hiệu cũng có thể nhảy đến một vị trí khác trong chương trình (thường thông qua longjmp hoặc bằng cách ném ngoại lệ), để hủy bỏ mọi thao tác gây ra truy cập bộ nhớ xấu.

Nếu chương trình người dùng không cài đặt bộ xử lý tín hiệu, nó sẽ bị ngắt. Trên một số kiến ​​trúc, nếu tín hiệu bị bỏ qua, nó có thể khởi động lại lệnh lặp đi lặp lại, gây ra một vòng lặp vô hạn.

Lỗi phân đoạn là quyền truy cập vào địa chỉ bộ nhớ không được phép (không phải là một phần của quy trình hoặc cố gắng ghi dữ liệu chỉ đọc hoặc thực thi dữ liệu không thể thực thi, ...). Điều này bị MMU (Bộ quản lý bộ nhớ, ngày nay là một phần của CPU), gây ra sự gián đoạn. Ngắt được xử lý bởi kernel, sẽ gửi SIGSEGFAULTtín hiệu (xem signal(2)ví dụ) đến quá trình vi phạm. Trình xử lý mặc định cho tín hiệu này bỏ lõi (xem core(5)) và chấm dứt quá trình.

Vỏ hoàn toàn không có tay trong này.