Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create Linux_Memory_Management_Essentials.md #38

Open
wants to merge 27 commits into
base: main
Choose a base branch
from

Conversation

igor-stoppa
Copy link
Collaborator

Description of internal memory management in Linux, from safety perspective.

igor-stoppa and others added 2 commits July 12, 2024 21:31
Co-authored-by: Paul Albertella <[email protected]>
Co-authored-by: Daniel Weingaertner <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
2. some limited in extent, but hard or even practicaly impossible to detect, like a rogue write to process physical memory
3. some of systemic nature, like some form of use-after free, where a process page is accidentally in use also by another component
4. some of indirect nature, like for example when the page table of the process address space is somehow corrupted
4. again, because of the extremely complex nature of the system, positive testing is not sufficient, but it needs to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Above I would say "if a non-interference claim cannot be made, due to the extremely complex ...."

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intentionally made a stronger statement.
Also to make it easier to prove me wrong :-)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

time flies ... but positive testing is still insufficient, at least witout evidence of the exhaustiveness of its coverage

Copy link
Collaborator

@dweingaertner dweingaertner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My general comment is that we should separate what is knowledge about the kernel memory management system, provide it with reference anchors, and separately discuss the safety implications, as these are not of the same nature.

Contributions/Linux_Memory_Management_Essentials.md Outdated Show resolved Hide resolved
Contributions/Linux_Memory_Management_Essentials.md Outdated Show resolved Hide resolved
Contributions/Linux_Memory_Management_Essentials.md Outdated Show resolved Hide resolved
Contributions/Linux_Memory_Management_Essentials.md Outdated Show resolved Hide resolved
Contributions/Linux_Memory_Management_Essentials.md Outdated Show resolved Hide resolved
reading more pages than requested, under the assumption that more requests might be coming soon


#### **Safety-Oriented consideration**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above. We should to separate the premises from these considerations, and explicitly state the premises each conclusion builds on. Take for example the 1 argument below. Uncertainty in the timing might be a problem, but might not, depending on the requirements or on the size of the uncertainty.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed to reconsider later the overall posture of the document.
My motivation is to try to keep together statements which are kind of obvious with others that might be less obvious, but derivable.
We could consider - in general - to introduce also the notion of which aspects are likely to be unavoidable, and which ones might be relevant only for some use case scenarios.

igor-stoppa and others added 8 commits September 19, 2024 15:16
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
added PXA, PXN examples

Signed-off-by: Igor Stoppa <[email protected]>
monolithic -> boot image

Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
igor-stoppa and others added 11 commits September 20, 2024 15:34
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Daniel Weingaertner <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Daniel Weingaertner <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Daniel Weingaertner <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
igor-stoppa and others added 2 commits January 26, 2025 17:49
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Paul Albertella <[email protected]>
Signed-off-by: Igor Stoppa <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants