Create Linux_Memory_Management_Essentials.md#38
Open
igor-stoppa wants to merge 27 commits into
Open
Conversation
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Co-authored-by: Daniel Weingaertner <danielwgt@redhat.com> Signed-off-by: Igor Stoppa <istoppa@nvidia.com>
Signed-off-by: Igor Stoppa <istoppa@nvidia.com>
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
dweingaertner
left a comment
dweingaertner
left a comment
Collaborator
There was a problem hiding this comment.
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** |
Collaborator
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.
Collaborator
Author
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.
Collaborator
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 <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
added PXA, PXN examples Signed-off-by: Igor Stoppa <istoppa@nvidia.com>
monolithic -> boot image Signed-off-by: Igor Stoppa <istoppa@nvidia.com>
Signed-off-by: Igor Stoppa <istoppa@nvidia.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Signed-off-by: Igor Stoppa <istoppa@nvidia.com>
Co-authored-by: Daniel Weingaertner <danielwgt@redhat.com> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Signed-off-by: Igor Stoppa <istoppa@nvidia.com>
Signed-off-by: Igor Stoppa <istoppa@nvidia.com>
reiterative
reviewed
Sep 20, 2024
reiterative
reviewed
Sep 20, 2024
reiterative
reviewed
Sep 20, 2024
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Daniel Weingaertner <danielwgt@redhat.com> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Daniel Weingaertner <danielwgt@redhat.com> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Daniel Weingaertner <danielwgt@redhat.com> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
reiterative
reviewed
Jan 26, 2025
reiterative
reviewed
Jan 26, 2025
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
Co-authored-by: Paul Albertella <paul.albertella@codethink.co.uk> Signed-off-by: Igor Stoppa <igor.stoppa@gmail.com>
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. |
Collaborator
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: |
Collaborator
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: |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.