This question already has an answer here:
Linking Dylibs in Kexts?
(1 answer)
Closed 9 years ago.
I am writing a kext driver for OS X and would like to use functions from the library libpcap.dylib. Libpcap.dylib lives in /usr/lib on OS X. Can it be used from kernel space? How can I use libpcap.dylib from a kext using Xcode?
I manage to compile -- (-lpcap apears as link option) but:
got an warning on "unexpected dylib" by linker. It is clear that is misplaced somehow.
kextload can't resolve libpcap dependencies.
kextlibs shows only libs that I include thru OsBundleLibraries suggesting that my dylib is ignored.
I am aware of similar question Linking Dylibs in Kexts? but want to know if someone have have used libpcap on a kext.
As is noted in Linking Dylibs in Kexts?, it's not possible to load a dylib in to the kernel via a kernel extension.
You don't mention what it is you're trying to achieve so it's difficult to know what alternatives would be relevant to you. I'd suggest reading up on [Network Kernel Extensions][1] to see if one of the techniques they cover could be used instead of pcap. Alternatively, you could make use of pcap from a userspace program and communicate with it from your kernel extension.
WinPcap has both user-land and kernel-mode components, because the Windows kernels don't provide the necessary kernel-mode components.
On UN*X systems - for example, on OS X - the kernel-mode components are part of the OS, and libpcap only includes user-mode code.
The equivalent, in *BSD and OS X, of WinPcap's kernel-mode code is BPF, which you won't be able to use from a kext. In addition, BPF has no equivalent of the send-queue stuff to do synchronized transmission of packets - you can send packets, but that just immediately injects the packet into the network stack - so neither using libpcap from your kext, nor using raw BPF from your kext, would help you with your timing needs.
Related
I have a student task to read PCI info via 0xCF8 and 0xCFC ports using outl(), inl() functions. It assumes I use Linux x86, but can I do such things on macos with M1 chip?
I found <sys/uio.h> header but it does not define functions prototypes.
outl and inl are platform-specific functions for Linux. If it is an exercise, and you have to submit a code snippet, then I suggest installing some kind of virtual machine (VirtualBox or maybe Docker Desktop) and write a program for Linux, otherwise your code would be unlikely to be accepted, since it'd use completely different low-level API.
I try to understand this whole "compiling" topic in a way more detailed than all those "what is a compiler (doing)?" articles out there.
One big question to me is processor- and os-platform dependency when compiling directly to machine code (e.g. C). I try to formulate concrete questions that needs to be resolved in order to get my picture clearer:
I compile my C code via gcc on a Linux distribution... :
Can I run the resulting executable on any other Linux Distribution?
Is that executable bound the processor platform compiled on? Do I need to search for another e.g. power-pc gcc when I am running a x86 distro?
Can I somehow execute this on windows? I know executables differs but the binary code is the same, isn't it?
So in the end my questions aims on: Is compiling about targeting a specifiy OS paltform, processor platform or both?
Thanks!
Compiling targets both, OS, and Architecture.
The OS needs to be targeted because:
The format of what is an "executable" file is different among operating systems.
Programs call the operating system even for common tasks like writing to the console, reading from a file, or terminating cleanly (standards like POSIX mitigate OS dependencies by defining a common layer between the program and the OS).
The CPU architecture must be targeted because the CPU instructions are different, even among different generations of the "same architecture".
Can I run the resulting executable on any other Linux Distribution?
In general, Yes, but on specific cases it may depend on the type of program (f.i. GUI) and the services assumed available on the OS.
Is that executable bound the the processor platform compiled on? Do I need to search for another e.g. power-pc gcc when I am running a x86 distro?
I don't understand what you mean by "search", but, Yes, you can cross-compile from, say, x86 targeting PPC.
Can I somehow execute this on Windows? I know executables differ but the binary code is the same, isn't it?
These days Windows has Ubuntu integration, and that allows for some kind of exceptions, but the general answer is No, because of the above.
Can a user application on macOS receive raw ethernet packets? I have a piece of hardware that uses it's own custom ethernet protocol and has it's own ether type defined. Is there anyway I can create a user application that sends / receives these packets? Mac OS does not support AF_PACKET. I believe Berkeley Packet Filter requires root access. Are there any other options?
Install libpcap library - https://formulae.brew.sh/formula/libpcap
Then you could sniff and/or inject arbitrary packets.
Can a user application on macOS receive raw ethernet packets?
Yes. See, for example, /usr/sbin/tcpdump.
I believe Berkeley Packet Filter requires root access.
Yes, by default; that's what the "launch daemon that adjusts capture permissions at system startup" provided by Wireshark does (it's based on stuff from the libpcap source distribution) - it makes the BPF devices readable and writable by a group, so if your code runs with that group as one of the groups in its group set, it can read (capture) and write (transmit) on BPF devices.
Are there any other options?
PF_NDRV sockets might work. See, for example, this chapter from a macOS/iOS/etc. internal book and this StackOverflow answer.
Install libpcap library
Note that libpcap ships as part of macOS, and the headers ship as part of the macOS SDK, so that, on macOS, you can build programs that use it without installing anything other than Xcode (or the Xcode Command Line Tools), just as you can, on Linux, build programs that use libpcap without installing anything other than a compiler and your distribution's libpcap "developer package", and you can, on *BSD, build it without having installed anything other than whatever the installer says you need for developing software (it might even install the compiler/linker and the appropriate headers by default).
We have built a simple instruction set simulator for the sparc v8 processor. The model consists of a v8 processor, a main memory and a character input and a character output device. Currently I am able to run simple user-level programs on this simulator which are built using a cross compiler and placed in the modeled main memory directly.
I am trying to get a linux kernel to run on this simulator by building a simplest bootloader. (I'm considering uClinux which is made for mmu-less systems). The uncompressed kernel and the filesystem are both assumed to be present in the main memory itself, and all that my bootloader has to do is pass the relevant information to the kernel and make a jump to the start of the kernel code. I have no experience in OS development or porting linux.
I have the following questions :
What is this bare minimum information that a bootloader has to supply to the kernel ?
How to pass this information?
How to point the kernel to use my custom input/output devices?
There is some documentation available for porting linux to ARM boards, and from this documentation, it seems that the bootloader passes information about the size of RAM etc
via a data structure called ATAGS. How is it done in the case of a Sparc processor? I could not find much documentation for Sparc on the internet. There exists a linux bootloader for the Leon3 implementation of Sparc v8, but I could not find the specific information I was looking for in its code.
I will be grateful for any links that explain the bare minimum information to be passed to a kernel and how to pass it.
Thanks,
-neha
I'm trying to compile a C program that uses libpcap in statistical mode on OSX. The original code was written for Windows, using the winpcap library. The version of libpcap on my Mac has never heard of the pcap_setmode function that it uses - I've got a nasty feeling that it might be Windows-specific.
Is there any way to capture in stats-mode on OSX? If not, is there something about the architecture/capabilities of the OS that prevents this, or is this an extra feature added to WinPcap which has never been a feature of the main library?
pcap_setmode() only has a definition in the Win32 port, because the WinPcap driver for Windows is the only packet capture mechanism that supports statistical mode; BPF in Mac OS X and *BSD and AIX and Solaris 11 don't support it, PF_PACKET sockets in Linux don't support it, DLPI in Solaris and HP-UX don't support it, etc..
UN*Xes generally come with a mechanism that supports capturing packets, so libpcap can just use that, without adding its own kernel-mode code; this means it can't control what facilities those capture mechanisms have - if a capture mechanism doesn't have it, libpcap can't add it. Windows doesn't come with such a mechanism; it does come with NDIS, which can support such a mechanism, so WinPcap comes with a kernel-mode driver that uses NDIS to implement such a mechanism, and thus has some more control over what features it offers.
pcap_setmode() only has a definition in the Win32 port (for unknown reasons to me).