Create Linux_Memory_Management_Essentials.md #38
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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]>
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
paolonig
reviewed
Jul 18, 2024
| 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.
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.
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.
There was a problem hiding this comment.
I agree that the structure of this document would need some further thought before publishing it, but I would prefer to merge it as a Contribution in its current form, and then consider how best to restructure it for publication (to https://osep.elisa.tech/) in a separate MR.
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]>
reiterative
reviewed
Sep 20, 2024
reiterative
reviewed
Sep 20, 2024
reiterative
reviewed
Sep 20, 2024
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]>
reiterative
reviewed
Jan 26, 2025
reiterative
reviewed
Jan 26, 2025
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]>
reiterative
reviewed
Mar 5, 2025
| 1. Because of the way pages, fractions and multiples of them are allocated, freed, cached, recovered, there is a complex interaction between system components at various layers. | ||
| 2. Even using cgroups, it is not possible to eliminate indirect interaction at the low level between components with different levels of safety integrity (e.g. the recirculation of pages related to critical processes in one group might be affected by less critical processes in another group) | ||
| 3. Because of the nature of memory management, we cannot rule out the possibility that memory management mechanisms will interfere with safe processes, either due to a bug or due to the interference toward the metadata they rely on. For example, the memory management might hand over to a requesting entity a memory page that is currently already in use either by a device driver or by a userspace process playing a role in a safety use case. | ||
| 4. These complex interaction between processes, kernel drivers and other kernel code mean that it is not feasible to qualify the kernel through positive, requirement-based testing alone. |
There was a problem hiding this comment.
Suggested change
| 4. These complex interaction between processes, kernel drivers and other kernel code mean that it is not feasible to qualify the kernel through positive, requirement-based testing alone. | |
| 4. These complex interactions between processes, kernel drivers and other kernel code mean that it is not feasible to qualify the kernel through positive, requirement-based testing alone. |
reiterative
reviewed
Mar 5, 2025
| 2. The optimisations made by the kernel in providing physical backing to process memory make it very | ||
| questionable if it can be assessed when a (part of) a process memory content is actually present in the | ||
| system physical memory. | ||
| 3. we cannot rule out the possibility that a process will be exposed to various types of interference from the kernel: |
There was a problem hiding this comment.
Suggested change
| 3. we cannot rule out the possibility that a process will be exposed to various types of interference from the kernel: | |
| 3. We cannot rule out the possibility that a process will be exposed to various types of interference from the kernel: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of internal memory management in Linux, from safety perspective.