I have tried to see if I could get Brendan Gregg's sshkeysnoop.d to work on Mac OS X, but am having trouble. Is it possible to get this working? If so, how?
The error I am getting is:
dtrace: failed to compile script ./sshkeysnoop.d: line 40: probe description syscall::exec:return does not match any probes
Is it possible to do any other kind of key logging on Mac OS X using DTrace?
A couple things you can do to adapt scripts like this. First, you can ask dtrace what probe points it has:
$ sudo dtrace -l -f 'syscall::exec*'
ID PROVIDER MODULE FUNCTION NAME
18442 syscall execve entry
18443 syscall execve return
Second, you can trace all syscalls on a single process to see what's going on.
$ sudo dtruss ssh somewhere 2>dtrussout
Password: (type something here)
If you look through dtrussout you can see
read_nocancel(0x5, "a\0", 0x1) = 1 0
read_nocancel(0x5, "s\0", 0x1) = 1 0
read_nocancel(0x5, "d\0", 0x1) = 1 0
read_nocancel(0x5, "f\0", 0x1) = 1 0
read_nocancel(0x5, "\n\0", 0x1) = 1 0
With that knowledge, it's pretty easy to adapt the script.
$ diff sshkeysnoop.d{.orig,}
40c40
< syscall::exec:return, syscall::exece:return
---
> syscall::execve:return
51c51
< syscall::open:entry, syscall::open64:entry
---
> syscall::open:entry
58c58
< syscall::open:return, syscall::open64:return
---
> syscall::open:return
68c68
< syscall::read:entry
---
> syscall::read_nocancel:entry
75c75
< syscall::read:return
---
> syscall::read_nocancel:return
OS X does not have a syscall::exec DTrace probe. It does have a syscall::execve though. Similarly it doesn't have syscall::open64, which is also used in this script. However, even with replacing exec with execve and removing open64, the script doesn't function correctly.
Also make sure you are loading with the all option
kldload dtraceall
and not just
kldload dtrace
Or the syscalls are not going to get loaded.
Related
I like to assemble a Linux image for RaspberryPi with ROS2 and Turtlebot3 stuff. Yocto environment is already set up and worked fine until end of last year. Image file was successfully built and started as expected at target system.
My new application needs further dependencies, therefore I pulled latest changes from origin repositories few days ago. Unfortunately, this seem to broke functionality of build system. Own changes not yet applied.
Build process fails at the last stage when rootfs should be created. It claims several rpm would be missing. It turned out they're existing at different location.
Below example is about glibc-localedata-pa-pk-2.31-r0.cortexa7t2hf_neon_vfpv4.rpm but after several tries I noticed that a tons of packages are affected.
Expected: build/BUILD-poky-foxy-dunfell/deploy/rpm/cortexa7t2hf_neon_vfpv4/glibc-localedata-pa-pk-2.31-r0.cortexa7t2hf_neon_vfpv4.rpm
Existing: build/BUILD-poky-foxy-dunfell/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/glibc-locale/2.31-r0/deploy-rpms/cortexa7t2hf_neon_vfpv4/glibc-localedata-pa-pk-2.31-r0.cortexa7t2hf_neon_vfpv4.rpm
Another afftected package:
Expected:
build/BUILD-poky-foxy-dunfell/deploy/rpm/cortexa7t2hf_neon_vfpv4/libatomic1-9.3.0-r0.cortexa7t2hf_neon_vfpv4.rpm
Existing: build/BUILD-poky-foxy-dunfell/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/gcc-runtime/9.3.0-r0/deploy-rpms/cortexa7t2hf_neon_vfpv4/libatomic1-9.3.0-r0.cortexa7t2hf_neon_vfpv4.rpm
Basically rpm are expected to be at build/BUILD-poky-foxy-dunfell/deploy/rpm/cortexa7t2hf_neon_vfpv4/ but they are at build/BUILD-poky-foxy-dunfell/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/XXX/YYY/deploy-rpms/cortexa7t2hf_neon_vfpv4/
Were there any changes in buildsystem or configuration since end of 2020 or any known issues found? Any help would be appreaciated, many thanks in advance!
$ bitbake ros-image-turtlebot3-core -k
Build Configuration:
BB_VERSION = "1.46.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "raspberrypi3"
DISTRO = "poky"
DISTRO_VERSION = "3.1.11"
TUNE_FEATURES = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard"
TARGET_FPU = "hard"
DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
ROS_DISTRO = "foxy"
ROS_VERSION = "2"
ROS_PYTHON_VERSION = "3"
meta
meta-poky
meta-yocto-bsp = "dunfell:6a7335170ed70263c4b2c55d10fe741c237c2357"
meta-oe
meta-python
meta-perl
meta-networking = "dunfell:c56d6309efc11e9f0f4a549be45a783c73a49ba0"
meta-raspberrypi = "dunfell:59c2d6f7a8b1239bd7b587b9180c2a55f9c695a2"
meta-ros-common
meta-ros2
meta-ros2-foxy
meta-ros-backports-hardknott
meta-ros-backports-gatesgarth = "ros2foxy:638a8b93e7b328fab9ccf2321bea039a93a57dde"
meta-communication
meta-system
meta-usercode = "ros2foxy:886b2fed39384970dc7476a15009765785b52512"
Initialising tasks: 100% |##########################################################################################| Time: 0:00:16
Sstate summary: Wanted 367 Found 365 Missed 2 Current 2770 (99% match, 99% complete)
NOTE: Executing Tasks
ERROR: ros-image-turtlebot3-core-1.0-r0 do_rootfs: Error executing a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:do_rootfs(d)
0003:
File: '/home/user/ros_target/poky/meta/classes/image.bbclass', lineno: 247, function: do_rootfs
0243: progress_reporter.next_stage()
0244:
0245: # generate rootfs
0246: d.setVarFlag('REPRODUCIBLE_TIMESTAMP_ROOTFS', 'export', '1')
*** 0247: create_rootfs(d, progress_reporter=progress_reporter, logcatcher=logcatcher)
0248:
0249: progress_reporter.finish()
0250:}
0251:do_rootfs[dirs] = "${TOPDIR}"
File: '/home/user/ros_target/poky/meta/lib/oe/rootfs.py', lineno: 975, function: create_rootfs
0971: env_bkp = os.environ.copy()
0972:
0973: img_type = d.getVar('IMAGE_PKGTYPE')
0974: if img_type == "rpm":
*** 0975: RpmRootfs(d, manifest_dir, progress_reporter, logcatcher).create()
0976: elif img_type == "ipk":
0977: OpkgRootfs(d, manifest_dir, progress_reporter, logcatcher).create()
0978: elif img_type == "deb":
0979: DpkgRootfs(d, manifest_dir, progress_reporter, logcatcher).create()
File: '/home/user/ros_target/poky/meta/lib/oe/rootfs.py', lineno: 366, function: __init__
0362: self.manifest = RpmManifest(d, manifest_dir)
0363:
0364: self.pm = RpmPM(d,
0365: d.getVar('IMAGE_ROOTFS'),
*** 0366: self.d.getVar('TARGET_VENDOR')
0367: )
0368:
0369: self.inc_rpm_image_gen = self.d.getVar('INC_RPM_IMAGE_GEN')
0370: if self.inc_rpm_image_gen != "1":
File: '/home/user/ros_target/poky/meta/lib/oe/package_manager.py', lineno: 765, function: __init__
0761: self.primary_arch = self.d.getVar('MACHINE_ARCH')
0762:
0763: if needfeed:
0764: self.rpm_repo_dir = oe.path.join(self.d.getVar('WORKDIR'), rpm_repo_workdir)
*** 0765: create_packages_dir(self.d, oe.path.join(self.rpm_repo_dir, "rpm"), d.getVar("DEPLOY_DIR_RPM"), "package_write_rpm", filterbydependencies)
0766:
0767: self.saved_packaging_data = self.d.expand('${T}/saved_packaging_data/%s' % self.task_name)
0768: if not os.path.exists(self.d.expand('${T}/saved_packaging_data')):
0769: bb.utils.mkdirhier(self.d.expand('${T}/saved_packaging_data'))
File: '/home/user/ros_target/poky/meta/lib/oe/package_manager.py', lineno: 733, function: create_packages_dir
0729: if destdir not in seendirs:
0730: bb.utils.mkdirhier(destdir)
0731: seendirs.add(destdir)
0732: try:
*** 0733: os.link(l, dest)
0734: except OSError as err:
0735: if err.errno == errno.EXDEV:
0736: bb.utils.copyfile(l, dest)
0737: else:
Exception: FileNotFoundError: [Errno 2] No such file or directory: '/home/user/ros_target/build/BUILD-poky-foxy-dunfell/deploy/rpm/cortexa7t2hf_neon_vfpv4/glibc-localedata-pa-pk-2.31-r0.cortexa7t2hf_neon_vfpv4.rpm' -> '/home/user/ros_target/build/BUILD-poky-foxy-dunfell/work/raspberrypi3-poky-linux-gnueabi/ros-image-turtlebot3-core/1.0-r0/oe-rootfs-repo/rpm/cortexa7t2hf_neon_vfpv4/glibc-localedata-pa-pk-2.31-r0.cortexa7t2hf_neon_vfpv4.rpm'
ERROR: Logfile of failure stored in: /home/user/ros_target/build/BUILD-poky-foxy-dunfell/work/raspberrypi3-poky-linux-gnueabi/ros-image-turtlebot3-core/1.0-r0/temp/log.do_rootfs.2708
ERROR: Task (/home/user/ros_target/3rdParty/meta-ros/meta-ros-common/recipes-core/images/ros-image-turtlebot3-core.bb:do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 9034 tasks of which 9033 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
/home/user/ros_target/3rdParty/meta-ros/meta-ros-common/recipes-core/images/ros-image-turtlebot3-core.bb:do_rootfs
Summary: There were 358 WARNING messages shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
Edit:
I tried to make all missing RPM available by symlinks. Since really a lot (but still not all) packages were affected, I created short script for that:
#!/bin/bash
currDir=`pwd`
#find all existing RPM in WORK directory
find build/BUILD-poky-foxy-dunfell/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi -iname "*.rpm" > ${currDir}/tmp_allRpm.log
#find all RPM that are already deployed
cd build/BUILD-poky-foxy-dunfell/deploy/rpm/cortexa7t2hf_neon_vfpv4/
ls -1 *.rpm > ${currDir}/tmp_deployedRpm.log
cd $currDir
#create list of all RPM that are not yet deployed
grep -v -f ${currDir}/tmp_deployedRpm.log ${currDir}/tmp_allRpm.log > ${currDir}/tmp_toBeLinkedRpm.log
#create symlinks
xargs -i ln -s {} build/BUILD-poky-foxy-dunfell/deploy/rpm/cortexa7t2hf_neon_vfpv4/ <${currDir}/tmp_toBeLinkedRpm.log
This seemed to solved the origin issue but lead to further weired errors. So I decided to set up new Yocto/OpenEmbedded environment using my existing config files and recipes. It turned out to be a good decision - after several hours of compilation everything was done ;) Only downside of this is that I can't tell what went wrong and when it may happen again?!
I don't want my code to be repeated several times. Grub4Dos has options for solving this problem, such as functions?
Grub4Dos don't have functions in the usual sense (as in Grub2) but you can use configfile command as functions.
Example:
menu.lst:
set ldpartnew=(hd0,0)/boot/grub4dos/load_partnew.lst
title archlinux-2021.02.01-x86_64
set ISO=(hd0,1)/ISO/archlinux-2021.02.01-x86_64.iso
configfile %ldpartnew%
load_partnew.lst:
partnew (hd0,3) 0 0 0
partnew (hd0,3) 0 0 0
partnew (hd0,3) 0 0 0
ls %ISO% && partnew (hd0,3) 0x00 %ISO%
map %ISO% (hd0,3)
map --hook
root (hd0,3)
chainloader (hd0,3)
Casper:
menu.lst:
set ldcasper=(hd0,0)/boot/grub4dos/load_casper.lst
title ubuntu-20.04.2.0-desktop-amd64
set ISO=(hd0,1)/ISO/ubuntu-20.04.2.0-desktop-amd64.iso
# ISOwohd is path to ISO without (hdX,X)
set ISOwohd=/ISO/ubuntu-20.04.2.0-desktop-amd64.iso
# initrdX is file extension of initrd file
configfile %ldcasper%
load_casper.lst:
map %ISO% (0xff)
echo -e \r\n
map --hook
root (0xff)
kernel (0xff)/casper/vmlinuz%vmlinuzX% file=/cdrom/preseed/ubuntu.seed boot=casper persistent iso-scan/filename=%ISOwohd% splash
initrd (0xff)/casper/initrd%initrdX%
Tested on grub4dos-0.4.6a-2021-01-27.
The problems I encountered in the process of using this method:
A variable name that is too long causes an error.
Since it is impossible to pass parameters to such functions in the usual way, it is necessary to declare additional variables of the type ISO, ISOwohd and initrdX.
Here is the file to be read, a.tab:
7.600000e-05
1.580000e-04
1.384140e-01
4.566700e-02
1.530000e-04
1.374210e-01
2.238700e-02
3.871300e-02
1.339930e-01
-2.231400e-02
3.835000e-02
1.313520e-01
-4.551300e-02
2.350000e-04
1.327270e-01
-2.207500e-02
-3.697500e-02
1.261490e-01
My program:
PROGRAM MAIN
implicit none
integer :: j,iostatus
double precision :: test(18)
open(unit = 100, file = 'a.tab', status = 'old', action = 'read',iostat=iostatus)
write(*,*) iostatus
do j = 1,18
read(100,*,end=10) test
end do
10 close(100)
write(*,*)test
end
the output is:
0
0
Why not read the file correctly if the iostat is equal to 0? The same program run on Windows works.
Since the program works on Windows, you might need to convert your input file for use in Unix. Try the dos2unix utility on a.tab before running on the Mac.
I was trying to debug a Python 2 script running on Raspbian (Raspberry Pi flavoured Debian Linux) which had code like
euid = os.geteuid()
if euid != 0:
print("you must be root!")
exit(1)
It seemed like, in the user's environment, euid would sometimes be nonzero even if the script was called with sudo.
To investigate whether this was actually the case, I tried to figure out what os.geteuid() is actually doing.
Since the os module is pretty OS-specific by its nature, the source doesn't actually have a clear definition for os.geteuid().
I also tried hg cloneing the source and compiling it, then using inspect.findsource(os.geteuid), but:
TypeError: <built-in function geteuid> is not a module, class, method, function, traceback, frame, or code object
It's... a builtin? Then "geteuid" in dir(__import__("__builtin__")) should be True, but it isn't.
Is geteuid's definition hidden because it could be spoofed into returning the wrong thing (and that would be bad)? Where can I see these sorts of functions' actual source?
ASCII stupid question, get a stupid ANSI.
I did try full-text searching the source, but apparently I used the wrong command the first time and gave up.
$ grep -rnw '.' -e "geteuid"
./Misc/setuid-prog.c:129: uid_t euid = geteuid();
./Lib/site.py:209: if hasattr(os, "getuid") and hasattr(os, "geteuid"):
./Lib/site.py:211: if os.geteuid() != os.getuid():
./Lib/test/test_shutil.py:84: #unittest.skipIf(hasattr(os, 'geteuid') and os.geteuid() == 0,
./Lib/test/test_httpservers.py:339: if os.name == 'posix' and os.geteuid() != 0:
./Lib/test/test_httpservers.py:395:#unittest.skipIf(hasattr(os, 'geteuid') and os.geteuid() == 0,
./Lib/test/test_spwd.py:8:#unittest.skipUnless(hasattr(os, 'geteuid') and os.geteuid() == 0,
./Lib/test/test_posix.py:44: "getegid", "geteuid", "getgid", "getgroups",
./Lib/test/test_argparse.py:1532:#unittest.skipIf(hasattr(os, 'geteuid') and os.geteuid() == 0,
Binary file ./Lib/tarfile.py matches
./Lib/rexec.py:148: 'getcwd', 'getuid', 'getgid', 'geteuid', 'getegid')
Binary file ./Modules/posixmodule.o matches
./Modules/posixmodule.c:4047:"geteuid() -> euid\n\n\
./Modules/posixmodule.c:4053: return _PyInt_FromUid(geteuid());
./Modules/posixmodule.c:8944: {"geteuid", posix_geteuid, METH_NOARGS, posix_geteuid__doc__},
./Doc/library/rexec.rst:234: 'times', 'uname', 'getpid', 'getppid', 'getcwd', 'getuid', 'getgid', 'geteuid',
./Doc/library/os.rst:136:.. function:: geteuid()
Binary file ./python matches
Binary file ./libpython2.7.a matches
./Modules/posixmodule.c:4053, indeed:
#ifdef HAVE_GETEUID
PyDoc_STRVAR(posix_geteuid__doc__,
"geteuid() -> euid\n\n\
Return the current process's effective user id.");
static PyObject *
posix_geteuid(PyObject *self, PyObject *noargs)
{
return _PyInt_FromUid(geteuid());
}
#endif
I don't know what I expected, subprocess.check_output(["id"])?
It uses the C standard library, it's never wrong.
I have written a simple kernel module which allocates objects using the slab layer. This module uses kernel API's (kmem_cache_{create,alloc,free}). The version of the kernel I am working on 3.15.4-200.
Though, my code works as expected with no issues, I am unable to see the new object/slab "my_cache" created using kmem_cache_create() when I grep /proc/slabinfo. The objects created are a simple list of objects, being inserted or removed from the list.
Note: My module works fine with no issues. I can view the slab creating under, /sys/kernel/slab/my_cache, but not in /proc/slabinfo or vmstat -m or slabtop
mycache = kmem_cache_create("my_cache",
sizeof(struct mystruct),
0, SLAB_HWCACHE_ALIGN, NULL);
if (mycache == NULL)
return -ENOMEM;
`
$ sudo cat /sys/kernel/slab/my_cache/objects
49108 N0=49108
$ sudo cat /sys/kernel/slab/my_cache/object_size
64
$ sudo cat /sys/kernel/slab/my_cache/order
0
$ sudo cat /sys/kernel/slab/my_cache/aliases
12
$ sudo cat /sys/kernel/slab/my_cache/cache_dma
0
$ sudo cat /sys/kernel/slab/my_cache/slab_size
64
$ sudo cat /sys/kernel/slab/my_cache/trace
0
$ sudo cat /sys/kernel/slab/my_cache/validate
$ sudo cat /sys/kernel/slab/my_cache/total_objects
49920 N0=49920
`
kmem_cache_create usually tries to merge this cache with other caches. So for example if it found another cache for the same size with the same properties ( slab is going to be poisoned, etc ) it will just use this cache instead of creating a new cache.
If you really want to make sure that it'll definitely create a new cache for you ( = appear in slabinfo ), you can always pass a valid constructor to kmem_cache_create. Something like this:
static void mystruct_constructor(void *addr)
{
memset(addr, 0, sizeof(struct mystruct));
}
mycache = kmem_cache_create("my_cache",
sizeof(struct mystruct),
0, 0, mystruct_constructor);
A constructor is usually called for every object allocation from this cache.
passing the additional flag SLAB_POISON solves the issue.
from link SLAB_POISON - Poison the slab with a known test pattern (a5a5a5a5) to catch references to uninitialised memory.