I am using gdb (arm-none-eabi) with a Texas Instruments Hercules (Cortex-R4F) processor. I'm using Texas Instrument's XDS agent as a remote GDB server
After running
target remote ip:port
in GDB, GDB will connect with the XDS GDBserver. I can then print the registers
info all-registers
It shows me the CPU registers, but also f7 and fpa registers which lead me to conclude that the CPU has an floating point coprocessor (FPA). This is however not the case. The processor has vfpv3. So GDB is using the wrong register definitions which leads to problems.
I tried to find the info in the packets sent by XDS GDB server by setting
set debug remote 1
but could not find any info. How does GDB determine the register definitions to use?
Update:
I found the set architecture command:
set architecture
>Requires an argument. Valid arguments are arm, armv2, armv2a, armv3, armv3m, armv4, armv4t, armv5, armv5t, armv5te, xscale, ep9312, iwmmxt, iwmmxt2, arm_any, auto.
Cortex-R4f is armv7 with vfpv3. How can I set it?
TI's XDS agent is acting as a GDBServer.
But it does not respond to packets such as qXfer:features:read... to get information on the target
In the end I manually applied:
set tdesc filename /gdb/binutils-gdb/gdb/features/arm/arm-with-vfpv3.xml
this sets the correct features for the Corter-R4f and allows me to set breakpoints, call functions, etc.
Alas, we're finding other problems now. It seems TI's XDS GDBserver agent is not very stable.
Related
I have a Qualcomm Development board with a Kryo 680 processor running a userdebug build of Android 11. I want to run some programs (e.g., benchmarks) and profile them using the ARM Streamline program. Unfortunately, some PMU registers return zero values.
Zero PMU values
I am getting the following warnings from Streamline.
Streamline Warnings
Warning 1: No Perf PMUs detected
Could not detect any Perf PMUs in /sys/bus/event_source/devices/ but the system contains recognised CPUs. The system may not support perf hardware counters. Check CONFIG_HW_PERF_EVENTS is set and that the PMU is configured in the target device tree.
Warning 2: Profiling Source
Using perf API for primary data source
Warning 3: Atrace is disabled
Unable to locate notify.dex
I am unsure of what to change in order to access the PMU counters. Is it an issue of gator? I am the pre-compiled version of gator provided with Streamline 8.0.
EDIT: Some more information printed by the gator daemon in the adb shell.
Unable to enable 1 perf groups due to them being reported as being disabled due to conflict or insufficient resources.
Another process may be using one or more perf counters.
Use `lsof|grep perf_event` (if available) to find other processes that may be using perf counters.
Not all event data may be available in the capture.
See debug log for more information.
The printout of lsof|grep perf_event is the following.
Binder:7545_3 7545 system 101u 0000 0,13 0t0 15649 anon_inode:[perf_event]
Binder:7545_3 7545 system 103u 0000 0,13 0t0 15649 anon_inode:[perf_event]
I'm trying to boot a kernel (extracted from a firmware) using QEMU.
Qemu emulation seems to start at 0x0.
The problem is that the memory from 0x0 to 0x04000000 is only filled with 0.
How can i debug the bootloader?
You don't say what your command line is. The address where QEMU starts execution depends on many things:
the guest CPU architecture
which board model you are emulating
whether you passed QEMU a BIOS image file
the file format of any file passed to -kernel (ELF, plain kernel image, uImage, etc)
In general, though, you should not expect to be able to pull a random kernel image out of a firmware dump for a piece of Arm hardware and run it under QEMU. This is because every Arm board or machine is different -- RAM may be in different places, the devices such as the serial port are at different addresses, and so on -- and the kernel will only boot on systems which it has been compiled to support. The chances are very high that (a) QEMU does not have a specific emulation of the bit of hardware that the firmware dump is for and (b) the kernel from the firmware has not been built to also run on any of the board types that QEMU does support. So it will almost certainly simply crash very early on in bootup without producing any output.
If you want to debug what's going on in early bootup, the best approach is probably to use QEMU's built in gdbstub, and attach a guest-architecture-aware gdb to it. You may also find QEMU's internal logging via the '-d' option useful, though it requires some familiarity with how QEMU works to make sense of the output.
I am running a C software on an ARM IP (module name is ARM926EJS) provided by Synopsis, and the entire tool I am using is Platform Architect also by Synopsis (based on TLM simulator, the hardware part is implemented in SystemC).
I received from my hardware module an address that the software is not supposed to access. Hardware modules cannot see the information of the software (or I may just not know), so I usually attach arm-none-eabi-gdb to the ARM IP during simulation to debug the software.
I have to check, but I believe that the ARM IP I am using does not support hardware watchpoint (using only one hardware watchpoint returns "too many hardware watchpoints"). I am trying software watchpoint by typing
set can-use-hw-watchpoints 0
I tried to see when the software accesses the strange address by typing
watch *(int*)(0x2056604+0xd0000000)
which the number is the address that I am receiving on the hardware. However, the program freezes, and the interrupt on gdb does not even work, I have to stop the simulation and delete the watchpoint to go on.
Strangely though, rwatch works correctly (although the problem persists since the address is accessed as "write"). It really would be beneficial to see which point in the software has caused the access to address 0x2056604+0xd0000000, but as watchpoints are not working for me, are there alternative ways to break on such access? Or is there a way to fix the freezing problem on software watchpoints?
Additional Note) I also tried to pause simulation on the memory access, then view the stack frame of the software. The software has strange stack and the gdb tells me that the stack is possibly corrupted. Output is the following..
#0 0x00002bf0 in ?? ()
#1 0x00001b94 in ?? ()
#2 0x00001b94 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I am working on a project where I have a router with ARMv7 processor (Cortex A15) and OpenWRT OS. I have a shell on the router and can load kernel modules with insmod.
My goal is to write a kernel module in C which changes the HVBAR register and then executes the hvc instruction to get the processor in the hyp mode.
This is a scientific project where I want to check if I can place my own hypervisor on a running system. But before I start to write my own hypervisor I want to check if and how I can bring the processor in the hyp mode.
According to this picture take from armv7-a manual B.9.3.4 the system must be in insecure mode, not in user mode and the SCR.HCE bit must be set to 1.
My question is how I can prepare the processor with a C kernel module and inline assembly and then execute the hvc instruction. I want to do this with a kernel module because then I start in PL1. This pseudocode describes what I want to achieve:
call smc // to get in monitor mode
set SRC.HCE to 1 // to enable hvc instruction
set SRC.NS to 1 // to set the system to not secure
call hvc #0 // call the hvc instruction to produce a hypervisor exception
The easiest way to elevate privilege is to start off in the needed privilege mode already: You've a root shell. Is the boot chain verified? Could you replace bootloader or kernel, so your code naturally runs in PL2 (HYP) mode? If so, that's probably the easiest way to do it.
If you can't replace the relevant part of the boot chain, the details of writing the rootkit depend a lot on information about your system left out: In which mode is Linux started? Is KVM support enabled and active? Was PL2 initialized? Was it locked? Is there "secure" firmware you can exploit?
The objective is always the same: have HVBAR point at some code you can control and do a hvc. Depending on your environment, solutions may range from spraying as much RAM as possible with your code and hope (perhaps after some reboots) an uninitialized HVBAR would point at an instruction you control to inhibiting KVM from running and accessing the early hypervisor stub to install yourself instead.
Enumerating such exploits is a bit out of scope for a StackOverflow answer; this is rather dissertation material. Indeed, there's a doctoral thesis exactly on this topic:
Strengthening system security on the ARMv7 processor architecture with hypervisor-based security mechanisms
To start with - I don't have JTAG hardware debugger.
What I have:
Pandaboard and serial-USB cable to connect to console and my computer with Freebsd and GNU/Linux distribution.
What I'm looking for
- convinient way to trace/debug bootprocess inside FreeBSD kernel ( I'm mostly interested in this fragment: https://github.com/freebsd/freebsd/blob/master/sys/arm/arm/locore-v6.S and https://github.com/freebsd/freebsd/blob/master/sys/arm/arm/mp_machdep.c as I'm, going to modyfy those files ).
Based on my experience, there are few ways:
KDB / DDB: add call kdb_enter("A", "XYZ") to stop processing and enter interactive debug mode of DDB via serial.
printf-s in machine dependent (mach_dep) code
bootverbose, BUSDEBUG, VERBOSE_SYSINIT in machine independent code
Also it's worth to mention that DDB code contains functions to print registers, stack trace and etc.