Skip to content

Conversation

@sunhaosheng
Copy link
Contributor

The original brk implementation had several issues:

  1. Never actually mapped pages - only updated the heap_top pointer
  2. Limit was USER_HEAP_SIZE (64KB), too small for real programs
  3. Did not track initial heap region, causing double-mapping errors

Implementation

  1. brk Syscall Double-Mapping Issue

File: api/src/syscall/mm/brk.rs

Bug Description:
The original brk implementation did not properly track the initial heap region that was already mapped during ELF loading. When a process called brk to expand the heap, it would attempt to map pages that were already mapped, causing AlreadyExists errors.

Fix:

  • Track initial_heap_end (USER_HEAP_BASE + USER_HEAP_SIZE) as the end of the pre-mapped region
  • Use initial_heap_end.max(current_top_aligned) as the expansion start point
  • Only map new pages when expanding beyond the already mapped region
  • Use saturating_sub to avoid negative sizes
  1. Added USER_HEAP_SIZE_MAX Configuration

Files:

  • core/src/config/aarch64.rs
  • core/src/config/loongarch64.rs
  • core/src/config/riscv64.rs
  • core/src/config/x86_64.rs

Description:
Added USER_HEAP_SIZE_MAX (512MB) constant to limit maximum heap expansion via brk. This prevents unlimited heap growth.

The original brk implementation had several issues:
1. Never actually mapped pages - only updated the heap_top pointer
2. Limit was USER_HEAP_SIZE (64KB), too small for real programs
3. Did not track initial heap region, causing double-mapping errors

Changes:
- Actually call aspace.map() to map new heap pages on expansion
- Increase limit to USER_HEAP_SIZE_MAX (512MB)
- Track initial_heap_end to avoid re-mapping already mapped pages
- Add USER_HEAP_SIZE_MAX config for all architectures

/// The address of signal trampoline.
pub const SIGNAL_TRAMPOLINE: usize = 0x4001_0000;
pub const SIGNAL_TRAMPOLINE: usize = USER_STACK_TOP - USER_STACK_SIZE - 0x1000;
Copy link
Contributor

Choose a reason for hiding this comment

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

--------------- user-space(end) : 0x7fff_ffff_f000

--------------- stack-top: 0x7fff_0000_0000

STACK SPACE (size: 0x8_0000)

-------------- stack-end: 0x7fff_0000_0000 - 0x8_0000
SIGNAL TRAP
--------------- SIGNAL TRAP

If we put SIGNAL_TRAMPOLINE under stack, if stack overaccess happend, it wouldn't directly give us an error(invalid Virtual Address), it can overwrite(read) SIGNAL_TRAMPOLINE mem!

Copy link
Contributor

Choose a reason for hiding this comment

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

we should put SINGAL TRAP on stack limit above

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.

3 participants