-
Notifications
You must be signed in to change notification settings - Fork 8
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
base: main
Are you sure you want to change the base?
Create Linux_Memory_Management_Essentials.md #38
Conversation
Co-authored-by: Paul Albertella <[email protected]> Co-authored-by: Daniel Weingaertner <[email protected]> Signed-off-by: Igor Stoppa <[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 |
There was a problem hiding this comment.
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 ...."
There was a problem hiding this comment.
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 :-)
There was a problem hiding this comment.
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
There was a problem hiding this 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.
reading more pages than requested, under the assumption that more requests might be coming soon | ||
|
||
|
||
#### **Safety-Oriented consideration** |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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]>
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]>
Signed-off-by: Igor Stoppa <[email protected]>
Co-authored-by: Daniel Weingaertner <[email protected]> Signed-off-by: Igor Stoppa <[email protected]>
Signed-off-by: Igor Stoppa <[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: 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]>
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]>
Description of internal memory management in Linux, from safety perspective.