flat assembler
Message board for the users of flat assembler.
Index
> Linux > Is my Linux system broken? |
Author |
|
Furs 26 Sep 2023, 13:34
Interesting, did you file bug reports about them yet?
|
|||
26 Sep 2023, 13:34 |
|
revolution 26 Sep 2023, 14:27
Furs wrote: did you file bug reports about them yet? I just made a macro to use int 0x80 for functions that need six arguments, so it is easy to mitigate. |
|||
26 Sep 2023, 14:27 |
|
weyowe 27 Sep 2023, 06:13
revolution wrote: Plus my kernel is five years old so it might already be fixed, or changed how it works or something. This sounds like an interesting issue, so I decided to check the source. It seems, the modern kernel always overwrites ebp for both sysenter and syscall: Code: ; On Intel push ebp mov ebp,esp sysenter ; On AMD push ebp mov ebp,ecx syscall Then kernel entry code takes the sixth argument from the saved ebp value in the stack. However, the vDSO-kernel interface can change between different kernel versions - comments in the source files mention that in 2015 it caused problems to android developers who carelessly hardcoded sysenters in their libc - so it is hard to tell what exactly is happening on an older system. But I find it hard to believe such a serious bug can bypass final tests. Usually, libc opts for vDSO wherever it can, and mmap is a basis for memory allocation and library loading. So, assuming the libc is not very old, this issue would render the entire 32-bit subsystem unusable. Are you sure you are not missing something? |
|||
27 Sep 2023, 06:13 |
|
revolution 27 Sep 2023, 06:23
mmap is fine, It affects mmap2.
|
|||
27 Sep 2023, 06:23 |
|
weyowe 27 Sep 2023, 07:10
As far as I know, the regular "mmap" (in kernel code it is referred as old_mmap) was introduced in early kernel versions at the time when it was impossible to pass 6 parameters to the kernel. Nowadays, it only exists for compatibility reasons and is not really used anywhere. So, mmap2 is the real mmap which is used by libc. Or, at least, I've always thought so.
|
|||
27 Sep 2023, 07:10 |
|
revolution 27 Sep 2023, 07:17
I made PoC code.
Code: ; for SYS in syscall32 int0x80 syscall32 int0x80 ; do fasm -d SYS=$SYS vsyscall32.asm >/dev/null && ./vsyscall32 ; echo ; done format elf executable SYS32_write = 4 SYS32_open = 5 SYS32_mmap2 = 192 SYS32_exit_group = 252 STDOUT_FILENO = 1 O_RDONLY = 00o MIN_ERROR = -4095 MMAP_PROT_READ = 0x1 MMAP_MAP_PRIVATE = 0x2 arg_address = 0 arg_length = 4 arg_access = MMAP_PROT_READ arg_flags = MMAP_MAP_PRIVATE arg_offset = 0 entry $ mov eax,SYS32_open mov ebx,fname mov ecx,O_RDONLY xor edx,edx ; mode call SYS cmp eax,MIN_ERROR jae .done ; mov edi,eax mov eax,SYS32_mmap2 mov ebx,arg_address mov ecx,arg_length mov edx,arg_access mov esi,arg_flags mov ebp,arg_offset call SYS cmp eax,MIN_ERROR jae .done ; mov ecx,eax mov eax,SYS32_write mov ebx,STDOUT_FILENO mov edx,arg_length call SYS cmp eax,MIN_ERROR jb .done ; mov eax,SYS32_write mov ebx,STDOUT_FILENO mov ecx,failed_text mov edx,failed_length call SYS .done: mov eax,SYS32_exit_group xor ebx,ebx call SYS syscall32: push ecx edx ebp mov ebp,ecx syscall int0x80: int 0x80 ret fname db '/proc/self/exe',0 failed_text db 'Failed' failed_length = $ - failed_text Code: ~ for SYS in syscall32 int0x80 syscall32 int0x80 ; do fasm -d SYS=$SYS vsyscall32.asm >/dev/null && ./vsyscall32 ; echo ; done Failed ELF Failed ELF |
|||
27 Sep 2023, 07:17 |
|
weyowe 27 Sep 2023, 07:43
Well, it is strange. I don't see anything wrong here, and both variants run without troubles on my system. It still makes me wonder what is going on inside libc. Maybe it is just too old and is not aware of vDSO, or this problem was a known issue, and it has some workarounds.
|
|||
27 Sep 2023, 07:43 |
|
revolution 30 Sep 2023, 10:17
So if others have no problem with 32-bit syscall then my system is broken?
Maybe my kernel is borked. I also see a problem with the MSR interface. Code: ~ for OFF in {0..59} ; do for REG in 130 ; do ADDR=$(( (1 << OFF) | REG )) ; VAL=$(sudo dd bs=8 if=/dev/cpu/0/msr count=1 status=none skip=$ADDR 2>/dev/null | xxd -p ; test ${PIPESTATUS[0]} -eq 0) && printf "%16x = $VAL\n" $ADDR ; done ; done 82 = 203b030200000000 82 = 203b030200000000 20000082 = 203b030200000000 40000082 = 203b030200000000 ... <snip duplicates> .... 400000000000082 = 203b030200000000 800000000000082 = 203b030200000000 |
|||
30 Sep 2023, 10:17 |
|
Furs 30 Sep 2023, 17:07
There might be a kernel config you're using. Are you using vanilla upstream kernel, a distro kernel, a custom config kernel…?
|
|||
30 Sep 2023, 17:07 |
|
revolution 30 Sep 2023, 19:32
Furs wrote: There might be a kernel config you're using. Are you using vanilla upstream kernel, a distro kernel, a custom config kernel…? A lot of the system-related MSRs are above 2^29. Now I wonder if there is some "bonus" code in my kernel image. So anyway, now I have learned something valuable. My system is broken, and it might be deliberate. |
|||
30 Sep 2023, 19:32 |
|
Furs 01 Oct 2023, 14:19
You can usually find the config where the kernel image is installed, e.g. /boot/config-<version>, maybe try compare with vanilla kernel's config?
I'm actually interested myself. |
|||
01 Oct 2023, 14:19 |
|
revolution 02 Oct 2023, 11:01
I'm not sure sure what I am looking for.
Code: /boot grep -i syscall config-$(uname -r) CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_SGETMASK_SYSCALL=y CONFIG_SYSFS_SYSCALL=y CONFIG_SYSCTL_SYSCALL=y CONFIG_BPF_SYSCALL=y CONFIG_ADVISE_SYSCALLS=y CONFIG_X86_VSYSCALL_EMULATION=y # CONFIG_LEGACY_VSYSCALL_NATIVE is not set CONFIG_LEGACY_VSYSCALL_EMULATE=y # CONFIG_LEGACY_VSYSCALL_NONE is not set CONFIG_MODIFY_LDT_SYSCALL=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_FTRACE_SYSCALLS=y /boot grep -i msr config-$(uname -r) CONFIG_X86_DEBUGCTLMSR=y CONFIG_X86_MSR=m CONFIG_SCSI_ARCMSR=m /boot |
|||
02 Oct 2023, 11:01 |
|
Furs 02 Oct 2023, 14:05
The config simply says what config it was compiled with, there's no guarantee it's how it works since you can change the source code to anything you want before building, but what's the point of them lying about it? Unless you got the kernel from a fishy place, obviously. But in that case you got bigger problems to worry about.
I'm not sure if the config necessarily has "syscall" in it. I know it's huge, but try to get the same upstream kernel (not distro, same version I mean), test it in a VM and see if it has the same problem. If it doesn't, try compare their configs and rule them out with bisection. Building the kernel is pretty easy since there's no crazy dependencies, despite its large size, just do it in tmpfs to not pollute your hard drive. Obviously only if you have the time for it. Actually before trying configs, you could try to get the source of your distro's kernel (exact ver, they should supply it in their packages), and compile it with the upstream vanilla kernel's config. See if it also has the problem. If it does, it's a custom patch in your distro's kernel that is causing this. They usually have many patches above the upstream one, that is provided in the sources. Once you found the culprit you can start bisecting the patches with git bisect. (BTW, I have the same configs with that grep, that's why I'm saying it) |
|||
02 Oct 2023, 14:05 |
|
revolution 02 Oct 2023, 14:25
The closest I had to a VM on this Linux box was DOSBox which I got permission to install for the 512 byte contest. It got removed as soon as that was finished. Getting permission to install a "real" VM for the reason of detecting IT meddling? Hmmm, methinks the chances are slim.
If the kernels are reproducible builds, or simply copied from an install medium (ISO file?), perhaps I can do a simple diff? I'd need to find the ISO image and mount it though. I have to include IT for that also. Mounting unknown stuff requires an admin sign-off. What else is there? md5sum? Only a matching result means anything, a mismatch wouldn't give any clues of value. |
|||
02 Oct 2023, 14:25 |
|
Furs 03 Oct 2023, 13:44
I'm not saying it's malicious, it's probably just someone messing a config up. Hashes won't tell you much except that it's "different", which it very likely is, most distros ship patched kernels (usually for security backports). So there's nothing to be alarmed about if hash doesn't match. It's expected.
|
|||
03 Oct 2023, 13:44 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.