| Age | Commit message (Collapse) | Author |
|
Not sure if there's any padding here, but it's a pretty big
structure, fairly likely, so let's be rather safe than sorry.
XXX pullup-8
XXX pullup-9
XXX pullup-10
|
|
|
|
|
|
|
|
|
|
|
|
|
|
it is now defined in each arch same as the other *_SIGNATURE definitions.
- add new LINUX32_GO_RT0_SIGNATURE for compat_linux32, and is defined in amd64 and aarch64.
|
|
|
|
linux32 binaries.
AT_SYSINFO (vsyscall) feature seems to be broken, so leave it commented out.
|
|
`linux32_exec_setup_stack',
and it should be defined in each arch.
declaration of linux32_exec_setup_stack() in linux32/amd64 has been removed because it does not exist.
NFC.
|
|
aarch64 and arm have different values.
- Compile linux32_sys_fadvise64() only if the syscall is required.
|
|
newer standardized name. NFC.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
timer_getoverrun(), and timer_delete()) to COMPAT_LINUX and COMPAT_LINUX32.
|
|
|
|
Just in case of uninitialized padding which would lead to kernel
stack disclosure. If the compiler can prove the memset redundant
then it can optimize it away; otherwise better safe than sorry.
|
|
|
|
Map the COMPAT_LINUX futex calls to the native ones.
|
|
|
|
this is needed so that glibc falls back to emulation and apps behaving
properly, since EOPNOTSUPP is a documented and expected return code, but
ENOSYS is not
right now there are no filesystems in NetBSD tree supporting the fallocate
VOP, so no point trying to map this to a native call
supposed to help with problem reported in
https://mail-index.netbsd.org/tech-kern/2019/11/03/msg025641.html
|
|
fpu_save_area_clear -> fpu_clear
fpu_save_area_reset -> fpu_sigreset
Clearer, and reduces a future diff. No real functional change.
|
|
before cpu_fsgs_reload() finishes, otherwise we write garbage in the GDT.
On NetBSD-current it is harmless, however in NetBSD-8 it might cause
panics, because NetBSD-8 uses the old SegRegs model and under this model
we reload %fs and %gs during switches.
|
|
|
|
|
|
extend the uint64_t's when building it, so we're leaking 48 bits of kernel
stack to userland.
Having said that, it appears that I unintentionally fixed most of this
issue in locore.S::rev1.127 - by building the frame with interrupts
disabled, we are implicitly guaranteeing that the structure doesn't get
overwritten by the kernel. Which means, we are leaking to userland data
that comes from userland anyway.
(still other places with this issue, but I'll fix them differently)
|
|
way segment registers work on amd64 will diverge between 32bit and 64bit
LWPs.
|
|
right now, but will be in the future.
|
|
mitigation against similar bugs.
The operations on segment registers can generate a page fault if there is
an issue when touching the in-memory gdt. Theoretically, it is never
supposed to happen, since the gdt is mapped correctly. However, in the
kernel we allow the gdt to be resized, and to do that, we allocate the
maximum amount of va needed by it, but only kenter a few pages until we
need more. Moreover, to avoid reloading the gdt each time we grow it, the
'size' field of gdtr is set to the maximum value. All of this means that
if a mov or iretq is done with a segment register whose index hits a page
that has not been kentered, a page fault is sent.
Such a page fault, if received in kernel mode, does not trigger a swapgs
on amd64; in other words, the kernel would be re-entered with the userland
tls.
And there just happens to be a place in compat_linux32 where the index of
%cs is controlled by userland, making it easy to trigger the page fault
and get kernel privileges.
The mitigation simply consists in abandoning the gdt_grow mechanism and
allocating/kentering the maximum size right away, in such a way that no
page fault can be triggered because of segment registers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|