> Date: Mon, 21 Mar 2022 19:56:14 +0000
> From: Miod Vallat <[email protected]>
> 
> A long, long time ago (I think it was late 2003), OpenBSD/i386 was
> vulnerable to a trusted-yet-NULL pointer dereference in the agp code.
> The attack involved using mmap(2) with MAP_FIXED and a hint of zero.
> 
> Shortly afterwards, in addition to fixing the overtrusting code, it was
> decided never to allow mmap(2) to allow address zero to get mapped, by
> never making VM_MIN_ADDRESS equal to zero (I actually argued for this
> change to only be applied to platforms with shared kernel/userland
> address spaces, but the party's line prevailed), which is why
> VM_MIN_ADDRESS is nowadays PAGE_SIZE instead of zero.
> 
> Except on riscv64.
> 
> The following diff adjusts VM_MIN_ADDRESS to follow the party's line.
> 
> Completely untested due to lack of hardware.

Bleah, I thought we fixed that already.

kernel boots; ok kettenis@

> Index: vmparam.h
> ===================================================================
> RCS file: /OpenBSD/src/sys/arch/riscv64/include/vmparam.h,v
> retrieving revision 1.5
> diff -u -p -r1.5 vmparam.h
> --- vmparam.h 2 Jul 2021 10:42:22 -0000       1.5
> +++ vmparam.h 21 Mar 2022 19:49:00 -0000
> @@ -111,8 +111,7 @@
>   * VM_MIN_USER_ADDRESS and VM_MAX_USER_ADDRESS define the start and end of 
> the
>   * user address space.
>   */
> -// XXX OpenBSD/arm64 starts VM_MIN_ADDRESS from PAGE_SIZE. Why?
> -#define      VM_MIN_ADDRESS          (0x0000000000000000UL)
> +#define      VM_MIN_ADDRESS          ((vaddr_t)PAGE_SIZE)
>  #define      VM_MAX_ADDRESS          (0xffffffffffffffffUL)
>  
>  #define      VM_MIN_KERNEL_ADDRESS   (0xffffffc000000000UL)
> 
> 

Reply via email to