I'm booting a GRUB EFI application compiled to x86_64-efi, on a x86_64 firwmare in UEFI only mode.
This GRUB app launches a 32bit Linux v3.18.48, with CONFIG_EFIVAR_FS=y and CONFIG_EFI_VARS=y.
Now I want to read some efivars, but I cannot even mount the efivarfs:
mount -t efivarfs efivarfs /sys/firmware/efi/efivars
which returns "No such device" (ENODEV).
It was expected since dmesg says:
No EFI runtime due to 32/64-bit mismatch with kernel
Looking at the Linux source:
if (!efi_runtime_supported())
pr_info("No EFI runtime due to 32/64-bit mismatch with kernel\n");
else {
if (efi_runtime_disabled() || efi_runtime_init())
return;
}
and
static inline bool efi_is_native(void)
{
return IS_ENABLED(CONFIG_X86_64) == efi_enabled(EFI_64BIT);
}
static inline bool efi_runtime_supported(void)
{
if (efi_is_native())
return true;
if (IS_ENABLED(CONFIG_EFI_MIXED) && !efi_enabled(EFI_OLD_MEMMAP))
return true;
return false;
}
seems that efi_runtime_supported() will always return false to me, since CONFIG_X86_64=n and CONFIG_EFI_MIXED depends on CONFIG_X86_64=y.
Is there any workaround that could allow me to read the efivars, under these conditions?
Constraints:
x86_64 firmware with UEFI only mode;
GRUB x86_64-efi will launch Linux;
Linux kernel v3.18.48 (may be patched), 32bits.
No, the 32-bit OS can't make 64-bit UEFI calls.
I hesitate to say anything can't be done in software, but this is about as close to impossible as you can get. You can't make 64-bit UEFI calls without switching to 64-bit mode, which would be extremely difficult to do the after the 32-bit OS boots.
One possible approach would be to change GRUB to read the variables and save them and provide a 32-bit interface for the OS to retrieve them. Since GRUB doesn't generally persist after the OS boots, this would be a significant change.
I was able to boot a 32-bit Ubuntu on 64-bit EFI machine with help of package grub-efi-amd64-signed, installed via chroot.
See the HowTo here (in German): https://wiki.ubuntuusers.de/Howto/Installation_von_32-Bit_Ubuntu_auf_EFI-System/
Anyway I sometimes have trouble, when GRUB gets updated.
Related
Is there a way of detecting a M1 mac in MATLAB? MATLAB has ismac but that presumably won't differentiate between processor types.
New Answer: Tested on M1 Mac
My impression is that MATLAB is running through Rosetta 2, which means that the result of uname -m is actually x86_64, which does not help guard against calls to Intel targeting mex code.
Instead we'll ask for the kernel version and try to find ARM64
if ismac()
[~,result] = system('uname -v');
is_m1_mac = any(strfind(result,'ARM64'));
else
is_m1_mac = false;
end
Note result above is on my computer : Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:37 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T6000
Old Answer: Not correct
To detect the processor one can call to the system command line:
Detect Apple Silicon from command line
Note, this has not been tested on a m1 mac ...
if ismac()
[~,result] = system('uname -m');
is_m1_mac = strcmp(strtrim(result),'arm64');
else
is_m1_mac = false;
end
Note, this would help if you are running an older version of MATLAB, as MATLAB doesn't officially support M1 macs until 2020b update 3 ...
https://www.mathworks.com/matlabcentral/answers/641925-is-matlab-supported-on-apple-silicon-macs
However, it is not clear to me that this would eventually detect execution of MATLAB natively vs via ROSETTA (when a native option actually exists).
I am self-studying the 2019 version of MIT 6.828/6.S081: Operating System Engineering.
I was trying to attach GDB to xv6 running on RISC-V using QEMU, to learn about what is going on when context switching happens between user mode and kernel mode.
After doing make qemu-gdb and gdb in the same directory, my GDB connected to QEMU successfully. However:
(gdb) x/2i $pc
=> 0xd8c: ecall
0xd90: ret
The problem is: Now if I stepi, it "jumps over" to 0xd90 instead of stepping into the kernel space.
Additionally, accessing any kernel addresses is not allowed, as if I was debugging a normal userland program:
(gdb) i r stvec
stvec 0x3ffffff000 274877902848
(gdb) x/i $stvec
0x3ffffff000: Cannot access memory at address 0x3ffffff000
Environment:
Host VM: Manjaro 19.0.2
sudo pacman -Syy
sudo pacman -S riscv64-linux-gnu-binutils riscv64-linux-gnu-gcc riscv64-linux-gnu-gdb qemu-arch-extra
GDB: 9.1
QEMU: 4.2.0
GCC: 9.2.0
Much appreciate anyone could share some insight about what is going on here. Thanks a lot!
I guess you run your code on ubuntu, that is the problem I experienced, then I change to mac, and flow mit tools tutorials, finally, it works.
run make CPUS=1 qemu-gdb in one window.
run riscv64-unknown-elf-gdb in another window.
ignore the Python Exception
I managed to get around this problem by building the riscv toolchain as explained here.
Building the toolchain as explained in the site, generates a generic ELF/Newlib toolchain identified with the prefix riscv64-unknown-elf- in contrast to the more sophisticated Linux-ELF/glibc toolchain identified by the prefix riscv64-unknown-linux-gnu-. The Newlib build allows the debugger to stepi into kernel space.
For crossdev users it is possible to build the toolchain with Newlib support by running:
crossdev --ex-gcc --ex-gdb --target riscv64-unknown-elf
I want to learn about the linux kernel and this is why I wanted a simple but powerful enough way test kernel changes that I do.
I used the info on this page https://mgalgs.github.io/2015/05/16/how-to-build-a-custom-linux-kernel-for-qemu-2015-edition.html to start.
So now I can start a qemu session with the kernel I choose and also have busybox utilities.
The part I cannot understand is how do I transfer a kernel module .ko on this virtual machine as to load it in my modified kernel ? I tried also transfering a c program by incorporating it in the initramfs but when I try to run the program I receive the following error message:
"/bin/sh: ./proc1: not found" .
Should I use a virtual hdd image ? If so how do I create and use one ? How do I transfer files from host os to the virtual hdd ?
Thnaks in advance.
The created virtual hdd was not discovered because I didn't use mdev -s in the init file.
After that I could mount the sda in qemu session.
The c program that could not be ran I solved by compiling it with the -static flag.
I'm learning how to write a basic OS kernel with intermezzos.github.io
I'm running in Windows Subsystem for Linux on Windows 10 v1607.
I'm at the point where I want to run my .iso with qemu-systems-x86_64 -cdrom os.iso.
Previously I was able to run the command and QEMU would run a window, which was running into another problem, posted here: QEMU, No bootable device, Windows Subsystem for Linux
Now when running the command, I receive the following error: Could not initialize SDL(No available video device) - exiting
When I ran into this problem before I installed Xming, ran it, and then QEMU successfully ran. But now, when I try to run Xming it no longer solves the problem.
I even tried installing xorg and running startx on WSL but that starts another issue: xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
I really don't know what I'm doing and I have so many questions.
I'm under the impression that for QEMU to successfully run, it needs to be able to find a video driver. Is that the purpose of X11?
I am able to get qemu-system-x86_64 -cdrom os.iso to run the expected window after setting: export DISPLAY=:0
Partially solves my problem because I'm still running into QEMU, No bootable device, Windows Subsystem for Linux
I'm wondering if I'm setting the DISPLAY environment variable correctly.
Here's documentation on the DISPLAY variable, for anyone else that wants to learn: http://gerardnico.com/wiki/linux/display
Anyway, this portion is solved!
The instructions found at Setting Up Kernel Debugging are what I used to get to this point. On the machine running the kext I want to debug, I do see the message "Connected to remote debugger". On the machine I am running gdb on, I do see:
(gdb) kdp-reattach localhost
Connected.
The problem is that 'showallkmods' returns an empty list and none of the other similar commands appear to be working:
(gdb) showallkmods
kmod address size id refs version name
(gdb) showalltasks
task vm_map ipc_space #acts pid process io_policy wq_state command
Invalid type combination in equality test.
(gdb) showregistry
Please load kgmacros after KDP attaching to the target.
(gdb) source /Volumes/KernelDebugKit/kgmacros
Loading Kernel GDB Macros package. Type "help kgm" for more info.
(gdb) showallkmods
kmod address size id refs version name
(gdb) showregistry
Please load kgmacros after KDP attaching to the target.
(gdb) showbootargs
Invalid cast.
I am running 10.6.8 and am using kernel_debug_kit_10.6.8_10k540.dmg
I am not sure what other details one might need to diagnose what has gone wrong, but if you want to ask questions in the comments, I can certainly attempt to provide additional details.
The error "Invalid type combination in equality test." indicates to me that gdb might be expecting a different CPU architecture than the kernel you're connecting to is running. The 10.6 kernel exists in both 32-bit and 64-bit variants, and by default it's determined by the hardware which one gets loaded. gdb normally defaults to x86_64 if your CPU supports it (true of all Intel Macs except the very early Core Duo based ones) so if you're connecting to a 32-bit kernel (the default on most Macs released before 2011) you need to pass the -arch i386 argument when starting gdb. You can check the current kernel CPU architecture by running the uname -a command.
Update: on OSX Mountain Lion, the kernel always runs in 64-bit (x86_64) mode. On OSX Lion, the kernel defaults to 64-bit mode on Macs which are capable of running Mountain Lion and in 32-bit mode otherwise.