Cách hệ điều hành phát hiện vi phạm truy cập bộ nhớ


12

Làm thế nào để một hệ điều hành (tốt nhất là Linux) biết rằng bạn đã truy cập một vị trí bộ nhớ mà bạn không được phép?

Câu hỏi này được lấy cảm hứng từ những con trỏ chết tiệt! Theo cách tôi thấy: mọi thứ trong máy tính là về sự thỏa hiệp giữa tốc độ, bảo mật, tính toàn vẹn và những thứ như vậy.

Tôi biết rõ về bản đồ bộ nhớ trong Linux, nhưng nghe có vẻ hơi vô lý với tôi rằng hạt nhân sẽ kiểm tra xem vị trí bạn đang cố truy cập có nằm trong phạm vi hợp lệ MERYI LẦN bạn thực hiện quyền truy cập hay không. Có vẻ như nó sẽ lãng phí rất nhiều thời gian, có thể được dành để làm một cái gì đó hiệu quả hơn (nhưng có thể ít an toàn hơn mà không cần kiểm tra!). Hoặc có thể nó nhớ tất cả các truy cập gần đây và kiểm tra chúng trên mỗi dấu thời gian phần cứng? (Nhưng điều đó nghe có vẻ không an toàn, và một lần nữa, chậm.)

Tôi đã ngạc nhiên khi câu hỏi này dường như chưa được trả lời ở bất cứ đâu. Đó là điều mà tôi luôn tự hỏi. Nó làm tôi nghĩ rằng có một phần của phần cứng sẽ thực hiện việc này thay mặt cho HĐH, ở mức độ trừu tượng tốt, thuận tiện. Tuy nhiên, nó vẫn có thể yêu cầu tải các bản đồ bộ nhớ quy trình tiếp theo trên mỗi chuyển đổi ngữ cảnh, một lần nữa nghe có vẻ chậm.

Vì vậy, có, dù sao, tôi đang đi một chút: làm thế nào để một hệ điều hành phát hiện vi phạm bộ nhớ?

Cảm ơn

Câu trả lời:


11

(Câu trả lời sau đây giả định một máy tính để bàn, máy chủ hoặc nền tảng nhúng cao cấp hiện đại (như điện thoại thông minh và nhiều hệ thống nhỏ hơn). Đối với các hệ thống x86, hiện đại có nghĩa là 386 trở lên. Câu trả lời sau đây cũng giả sử Hệ điều hành hiện đại của hệ thống, như hầu hết mọi unix hoặc Windows kể từ năm 95.)

Điều này không xảy ra trong HĐH, nó xảy ra trong bộ xử lý, cụ thể là trong MMU ( đơn vị quản lý bộ nhớ ) . MMU hỗ trợ địa chỉ ảo, theo đó các bit tạo nên một con trỏ không trực tiếp chỉ ra vị trí vật lý của các bit trong bộ nhớ.

Trong một MMU điển hình, khi một con trỏ bị hủy đăng ký, MMU chia các bit thành hai nhóm: các bit thứ tự cao tạo nên số trang và các bit thứ tự thấp tạo nên địa chỉ bên trong trang. Hầu hết các máy tính để bàn và máy chủ sử dụng các trang 4kB. MMU tra cứu số trang ảo trong một bảng có tên là TLB (đó là cái mà bạn gọi là bản đồ bộ nhớ quá trình bản đồ). TLB cho biết số lượng trang vật lý tương ứng với trang ảo này. MMU sau đó lấy dữ liệu từ trang vật lý trong bộ nhớ.

Nếu TLB không chứa mục nhập cho số trang ảo cụ thể này, MMU sẽ thông báo cho bộ xử lý rằng đã xảy ra truy cập không hợp lệ; điều này thường được gọi là một ngoại lệ.

Lưu ý rằng tôi đã không đề cập đến hệ điều hành cho đến nay. Đó là bởi vì tất cả các hoạt động này là độc lập với hệ điều hành. Hệ điều hành hoạt động vì nó cấu hình mọi thứ theo hai cách:

  • HĐH có trách nhiệm chuyển đổi nhiệm vụ. Khi làm như vậy, như bạn nghi ngờ, nó sẽ lưu TLB hiện tại và thay thế nó bằng TLB đã lưu cho tác vụ theo lịch trình tiếp theo. Theo cách đó, mỗi quy trình có một TLB, vì vậy địa chỉ 0x123456trong quy trình X có thể không trỏ đến cùng một vị trí thực tế trong RAM giống như địa chỉ đó trong quy trình Y hoặc đơn giản là không hợp lệ. Nếu một quá trình cố gắng hủy đăng ký một con trỏ bên ngoài không gian địa chỉ của nó, thì nó không tiếp cận được với không gian của quá trình khác, thay vào đó nó không đi đến đâu .

  • HĐH quyết định điều gì xảy ra khi một ngoại lệ được nêu ra. Nó có thể chấm dứt quá trình thực hiện truy cập bộ nhớ không hợp lệ (lỗi phân đoạn, lỗi bảo vệ chung, ...). Đây cũng là cách thức thực hiện trao đổi: trình xử lý ngoại lệ có thể quyết định lấy một số dữ liệu từ không gian hoán đổi, cập nhật TLB phù hợp và thực hiện lại quyền truy cập.

Lưu ý rằng MMU cung cấp bảo mật vì quy trình không thể thay đổi TLB của chính nó. Chỉ nhân hệ điều hành có thể thay đổi TLB. Làm thế nào quyền thay đổi TLB hoạt động nằm ngoài phạm vi của câu trả lời này.


6

1) Segfaults được phát hiện bởi đơn vị quản lý bộ nhớ. Khi bạn yêu cầu bộ nhớ, HĐH sẽ yêu cầu Bộ quản lý bộ nhớ lấy một số từ phần cứng. Phải có một cái gì đó theo dõi tất cả các khối bộ nhớ lớn mà HĐH mang lại cho bạn. Các loại hệ điều hành đã chuyển sang MMU. Vì nó biết tất cả bộ nhớ mà nó cung cấp cho bạn, nó cũng có thể cho bạn biết khi bạn cố truy cập vào một vị trí bộ nhớ mà bạn không nhận được từ việc phân bổ, HĐH đặc biệt có một sự kiện cho việc này, bộ nhớ bạn không sở hữu. Cuối cùng, HĐH sẽ giết chết ứng dụng của bạn, kích hoạt một segfault hoặc tương đương trên các HĐH khác.

Không phải tất cả các hệ điều hành đều có sự bảo vệ này. MacOS lên đến 9 không có bất kỳ thứ gì trong số này, mặc dù MMU đã hỗ trợ điều này. Cả Win 3.1 cũng không. Win95 có một số bảo vệ, vì nó đã chuyển đổi giữa việc không có bảo vệ và sau đó thêm một số.

2) HĐH không biết bất kỳ chi tiết nào khác ngoài điều này. Nếu bạn có một con trỏ đi lạc truy cập vào bộ nhớ mà bạn không bao giờ phân bổ, nó sẽ biết. Nếu bạn có một phần đi vào một phần khác của ứng dụng của bạn, thì dĩ nhiên nó không biết. Nó cho phép bạn làm hỏng điều này. Đây là nơi bạn nhận được các ngăn xếp bị hỏng, với các con trỏ đi lạc từ ứng dụng của bạn ghi đè lên các phần khác của ứng dụng.

Vì vậy, có, bạn có thể vít dữ liệu của riêng bạn. Nếu bạn có một con trỏ đi lạc ghi đè lên ứng dụng của riêng bạn, bạn HỎI bạn đã đánh vào ngăn xếp của mình, vì điều đó có thể sẽ xảy ra vi phạm khác khi bạn cố gắng quay trở lại ngăn xếp, nhưng nếu bạn nhấn dữ liệu của riêng mình, bạn sẽ không bao giờ biết.

Bạn có thể cố gắng nghiêm khắc hơn 'không bảo vệ', có một công cụ có tên là Hàng rào điện ( http://perens.com/FreeSoftware/ElectricFence/ ) sẽ lừa MMU của bạn hoạt động nhiều hơn một chút và khiến nó phát hiện thêm lỗi.


Được rồi, bạn có thể cụ thể hơn về cách nó hoạt động? Giống như, làm thế nào để biết một quy trình cụ thể không thể truy cập vào một vị trí cụ thể? Điều gì cho nó biết quá trình có thể truy cập ở đâu? Làm thế nào để nó phân biệt? Cảm ơn
Doddy

1
@panic - tra cứu Memory_man Quản lý_unit trong wikipedia và các liên kết từ trang đó. Lưu ý rằng trạng thái quá trình bao gồm trạng thái MMU. Bạn có thể dành các học kỳ cho thiết kế, tính năng và tích hợp MMU.
mpez0
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.