I heard about USB to LPT adapters that are capable of mapping PC legacy parallel port address. What is the level of such mapping? I mean - is it possible to access the adpater's pins by using 'in' or 'out' x86 assembler instructions (in Windows or Linux)? If not, what does it mean that the addresses are mapped? What kind of emulation is this?
Thanks.
Marcin
A mapping from legacy I/O port addresses to a USB device is most likely handled by trapping the port access in kernel mode operating system code. For several generations of systems now, the operating system has been able to impose itself between application code and the hardware in such a way that even things that look like raw hardware access to the application are not necessarily so.
Effectively, when the processor comes upon that raw port access, it isn't executed but an operating system service routine is called instead.
Related
In order to accept only non-virtual COM ports, how to determine whether the COM port is virtual or not in Delphi ?
It is made virtual by a device driver. You can't get to it from a user-mode program. Running a WMI query for Win32_SerialPort leaves a breadcrumb, Description property, nothing that ever repeats well on a different machine with different hardware. The point of virtualizing it is to make it look as much as a hardware port as possible, a good driver makes it impossible to tell the difference.
You can otherwise just plain assume "yes". It's pretty rare to find a PCI-E card with real UARTs these days, the convenience of pluggable USB is just too great. And ridiculously dirt-cheap, Amazon lists a USB emulator for $3.21. Most of all, do avoid having to know.
I need to create a driver, which will behave similar to software RAID. E.g. driver will need to communicate to multiple physical disks (or maybe even network resources), and shall look like a disk to the OS.
So two main questions are:
1) Are EFI drivers recognized and supported by Windows, MacOS X and Linux? E.g. can these systems use EFI disk drivers, and ?
2) Is it possible in theory to write such a driver for EFI? My primary concern is possibility of accessing other EFI disk drivers from your own virtual disk driver.
I only have time for a quick-ish reply, forgive me for brevity!
Are EFI drivers recognized and supported by Windows, MacOS X and Linux? E.g. can these systems use EFI disk drivers, and ?
To my knowledge, only the bootloaders for these OSs use the UEFI driver stack for loading the native OS kernel and drivers. Once ExitBootServices() is called by the bootloader, most of the drivers are unloaded, and (according to the spec) no calls to handle-based drivers may happen after this, meaning no disk drivers. Like a traditional bootloader, a UEFI bootloader is only using the basic drivers long enough to load the OS's native drivers. You can also use these drivers in the preboot environment if you'd like (although it sounds like you don't!).
TL;DR No, these systems can't use UEFI drivers other than for loading the OS.
Is it possible in theory to write such a driver for EFI?
You should definitely be able to layer your UEFI driver on top of the existing stack. It might be a little tricky if you haven't worked with UEFI before, but conceptually the system is very modular. There appear to be a number of resources on the Internet to help you out, and there is always Beyond BIOS: Developing with the Unified Extensible Firmware Interface by Vincent Zimmer.
As far as testing goes, you can use one of the simulators provided in Intel's EDKII (if you're on Windows, you should probably use the Nt32 project, it works well with Visual Studio).
TL;DR Yes, you can write this driver, but it will only work for bootloaders and applications in the pre-boot environment.
1) Are EFI drivers recognized and supported by Windows, MacOS X and Linux? E.g. can these systems use EFI disk drivers, and ?
No. Once you run ExitBootServices() it goes bubye. You can have a RunTimeDXE Driver, but those are incredibly limited. They cannot allocate memory (the VM Map is controlled by the OS) and they don't have access to any EFI APIs any more. They can be used to transfer information from the Firmware to the OS, but a better choice would be a private EFI Table.
2) Is it possible in theory to write such a driver for EFI? My primary concern is possibility of accessing other EFI disk drivers from your own virtual disk driver.
The bootloader is the only one able to use the EFI drivers. If you want to go to the OS level, you need to write your own OS driver that gets the information from the EFI driver using EFI System Tables. Such examples are Full Disk Encryption implementations.
In theory you would need to write an EFI Block Driver based, a Windows IO Filter or BUS/Volume Driver, an OS X IOStorageFamily KEXT and a Linux Block Device Driver all of them transferring the information from firmware to OS using EFI Tables, Variables or RuntimeDXE.
RuntimeDXE implementations are incredibly difficult due to the conversion to Virtual Memory Maps from the flat addressing available in the EFI.
I'm using Delphi to develop real-time control software and over the last couple of years I have done some work running older Windows installations under Microsoft's VirtualPC and it works fine for 'pure software' development (i.e no or limited access to the outside world). Such tools seem able to work with network connections but I have to maintain software which performs I/O via the parallel port (via a device driver). We also use USB I/O. In the past I've liked Microsoft's virtual tools because it takes time to install a new operating system and then (in my case) install Delphi and a load of libraries and components to provide development support. In these circumstances I've not been too bothered by my lack of access to the low-level I/O ports.
I want to up my game and I'm happy to pay for a good virtualisation tool IF I can have access from it to the outside world, i.e I want to be able to configure it to allow access to my machine's parallel port and com ports in the same way as if it was running natively. This access has to be able to expose the parallel port in register terms, i.e to 'see' the port at address $03f8 for example and to support I/O operations of those registers (via the appropriate kernel access) as my Windows 7 64-bit installation is able to do.
I see that there are a number of virtualisation solution out there now but it's quite hard to acertain the capability of each at such a low level. Does anyone have any experience or knowledge in this area?
The VMware products would be suited best for this. You can add virtual serial and parallel ports and forward them to a physical port on the host, or even to a file or a named pipe.
You can also connect any USB device that is connected to the host machine.
This works with VMware Workstation, but might even work with the free VMware player too.
I have been trying to understand I/O ports and their mappings with the memory & I/O address space. I read about 'Memory Mapped I/O' and was wondering how this is accomplished by OS/Hardware. Does OS/Hardware uses some kind of table to map address specified in the instruction to respective port ?
Implementations differ in many ways. But the basic idea is that when a read or write occurs for a memory address, the microprocessor outputs the address on its bus. Hardware (called an 'address decoder') detects that the address is for a particular memory-mapped I/O device and enables that device as the target of the operation.
Typically, the OS doesn't do anything special. On some platforms, the BIOS or operating system may have to configure certain parameters for the hardware to work properly.
For example, the range may have to be set as uncacheable to prevent the caching logic from reordering operations to devices that care about the order in which things happen. (Imagine if one write tells the hardware what operation to do and another write tells the hardware to start. Reordering those could be disastrous.)
On some platforms, the operating system or BIOS may have to set certain memory-mapped I/O ranges as 'slow' by adding wait states. This is because the hardware that's the target of the operation may not be as fast as the system memory is.
Some devices may allow the operating system to choose where in memory to map the device. This is typical of newer plug-and-play devices on the PC platform.
In some devices, such as microcontrollers, this is all done entirely inside a single chip. A write to a particular address is routed in hardware to a particular port or register. This can include general-purpose I/O registers which interface to pins on the chip.
I am aware that there are programs out there like lojack for laptops that get installed on the BIOS, but I'm still a little confused. When reading about lojack, it seems to me that they can't fully located the laptop's location until the user logs in and tries to access the internet. So I'm thinking that it's a BIOS application so that it wouldn't matter if the thief reformats the HD.
So my question is, does anyone have any ideas of how an internet enables BIOS application would be written. I'm not looking for full answers -- just ideas or resources to get started. For example, is such a thing written in assembly? Once one such app is written, how does it get transfered to the BIOS.
Does the BIOS program itself recognize that there is an internet connection (when the thief logs on to the OS). Or upon logon, does additional processes get spawned? Are there any resources/websites that anyone can direct me too?
You didn't mention whether you were interested in legacy BIOS or EFI BIOS, but I would mention that with EFI there is the capability of writing EFI applications. See Intel Press:
Harnessing the UEFI Shell
The EFI Application toolkit comes with a complete TCP/IP network stack:
http://www.intel.com/technology/efi/toolkit_overview.htm
More at tianocore.org
Regarding "LoJack"-style solutions, one of the providers of this technology is Absolute Software's Computrace product.
Basically there are 3 components: 1) a software component that runs in the OS; 2) a BIOS component which is baked into the system BIOS (accomplished via Absolute working with the PC vendor); 3) servers at Absolute software that talk to the PC.
For more information on how it works visit:
http://www.absolute.com/en/company/Computrace-Persistence.aspx
(see especially the demo video on this site)
To learn something about BIOS, one good source is coreboot.org. It is an open source BIOS (or firmware) and support some physical machines.
Legacy BIOS is written in assembly language, but new generations, such as UEFI or coreboot, are written mostly in C language. BIOS program is stored in the ROM, and executed by the CPU automatically.
The BIOS program itself does not access the internet or perform any of the advertised functions. The LoJack addition to the BIOS firmware is a file copying/patching utility - at boot up it can check the harddrive for a copy of Windows and proceed to silently install/repair the LoJack service if it has been removed. The service itself includes several measures to lower it's profile and prevent itself from being disabled (similar to how many trojans and malware run several processes that each restore the other if one is disabled or killed).
The LoJack BIOS program can't do anything if a unsupported operating system (like Linux) is installed after the harddrive is wiped.