[{quoted}](name=Naked Baby Thief,realm=NA,application-id=ZGEFLEUQ,discussion-id=voyQpEJE,comment-id=0000000000000000000000000000000000000000000000000000,timestamp=2017-03-07T11:47:47.326+0000)
Right so what you are saying is that you are just smart enough to not know what hardware abstraction is.
And that you have no clue how complex flashing an EEPROM actually is.
Writing to a EEPROM chip isn't as simple as downloading a script guy. And most of the trolls that get banned don't know how to locate a EEPROM on a green board, remove it with a solder station, rip the data from the EEPROM, figure out exactly what all the stored data is, reprogram the EEPROM using a EEPROM programmer, and then resolder it onto the card.
But sure... if you think all of that is 'simple', it is simple.
A first year EE student could do it with minimal effort, so yes, it is simple. So simple in fact, that you actually can do it from software with a number of NIC's.
Further, if your COMPLETELY FALSE CLAIM THAT, " the OS moderates ALL hardware access. Period.", were true, SpeedFan, OpenHardwareMonitor, GPUz, CPUz, and several THOUSANDS of other programs wouldn't work as they do.
Guess what, those still go through the OS. They bypass the OS drivers for that specific hardware, but they still go through the OS to access the hardware. They don't have direct access to PCI, or I2C, or SPI, or whatever interface the hardware uses. They by definition can't have such access, because the required instructions immediately trap out to kernel mode (ring 0 on x86, supervisor mode on most other ISA's). Using your specific examples:
- SpeedFan: Uses OS API's to talk to the firmware, which then manipulates the hardware, so actually it has 2 layers between it and the hardware.
- OpenHardwareMonitor: Uses OS APi's to either talk to the hardware through the OS bus drivers, or to the firmware.
- GPU-Z: Similar to OpenHardwareMonitor, except it goes through the GPU drivers so it can access the I2C bus on the card to talk to the monitoring chips directly, or, more commonly, just reads back information from the GPU driver (modern Intel, NVidia and AMD drivers provide almost all of the info that GPU-Z reports already, they just don't have an easy way to see it from userspace).
- CPU-Z: Uses the x86 CPUID instruction and reads a small number of MSR's. This is the closest to direct hardware access, except it has to trap through the OS to read the MSR's (because certain MSR's contain inherently sensitive data).
You really shouldn't misrepresent facts just to attempt and drive home a false narrative.
" nothing running in user mode without administrative privileges has access to BIOS or UEFI settings"
Settings no, however you can read data from the bios any time you want. If you couldn't, your PC would stop working correctly.
No programs could read current time (bios holds time), generate random numbers, read or write text, etc, etc, etc. This is all hardware access, that goes through bios.
None of that has gone through BIOS on PC compatibles for years. No modern OS can afford to trap out to real mode just to talk to the BIOS all the time. Windows does use UEFI interfaces for some things (power management (although that's ACPI, not UEFI), RTC, and on embedded platforms boot management) these days, but networking and disk access are not among those things despite having reasonable API's (because both are insanely slow through the UEFI API's).
Seeing as you like the RTC as an example, go start a VM running any modern OS and trace it to see how often the RTC emulation code gets called. You'll see it get hit a couple of times during boot, and then almost never afterwards (possibly every 11 minutes under Linux, but only if you're running a time sync daemon, and even then those will only be writes, not reads). The RTC isn't used for timekeeping while the system is running, that job is done by any of a number of other pieces of hardware (usually the HPET or TSC on x86 systems, although if it's an old OS it may use the PIT) because they keep crappy time. They are kept for a couple of specific reasons, namely keeping time while the OS isn't running, and allowing automatic startup at a specific time.
As for the hardware RNG argument, if it's a TPM, there's an OS driver that mediates access, because that's what the TCG spec requires for certification. If it's a CPU instruction (RDRAND or RDSEED on x86), then you can call it from user code, but you're not touching the firmware at all (except possibly asking the CPU to run some specific snippet of microcode). If it's anything else, it's probably got an OS driver. Very little calls hardware directly for random numbers because it's not portable and it's much easier to just read /dev/urandom or make the equivalent API call on Windows.
Go take a look at the source code for Linux if you don't believe me. Almost nothing there goes through firmware if at all possible, regardless of platform, because it's horribly inefficient and looks bad for the OS when the firmware has bugs.
EVEN IF what you were saying were the case, which it is not, the most that would happen is windows would prompt that the program requested administrator privileges. And 99.99% of the home users would already be the default admin, and that would be no problem.
Being an admin account, running a program with administrative privileges, and using the real Administrator account are three different things. There is very little physical hardware access outside
The really funny thing about all these arguments is that companies already successfully ban by MAC address. What I am saying is already in practice elsewhere. Yet here you kids are, arguing against reality.
So is the fact that it is trivial to spoof a MAC address. Anyone with a decent gaming rig could easily run a virtual machine and run the game inside that, thus letting them use whatever the hell they want for the MAC address. Nothing is unique and impossible to spoof. Not MAC addresses, not UUID's, not WWN's, not anything.
Further,
http://git.kernel.org/cgit/network/ethtool/ethtool.git/tree/ethtool.c
Example source code of how to pull MAC directly from the hardware itself.
Ethtool uses kernel API's, not direct hardware access. That's why it can only do things the driver supports for any given NIC, regardless of what the hardware supports. The same goes for anything else. Some other specific examples from Linux include usb_modeswitch, i2c-tools, ddcontrol, bbswitch, DirectFB, hwclock, and any number of other userspace drivers.
I think the most disgusting thing about all of this, is the massive downvotes simply from being educated on the topic. Really shows how anti-intellectual and trollish this community is.
At least half the downvotes are because of your attitude, not the content.