OpenBSD Journal

testers required for NVIDIA Ethernet driver

Contributed by marco on from the NVIDIA-ethernet-driving dept.

So Damien Bergamini and I (jsg@) have put together a driver for the Ethernet controllers NVIDIA put out.

They don't provide documentation or even have a list of names for the chips, but will happily agree to let various parties distribute a driver kludged around a binary blob.

Suffice to say, we have have not taken this approach.

Snapshots starting 5th Feb for i386 and amd64 have the driver (nfe) included.

What we would really like now, is some feedback from a wide range of nforce based systems. Send a dmesg and a mention of whether you have any issues to damien (damien@openbsd.org) and me (jsg@openbsd.org).

(Comments are closed)


Comments
  1. By Anonymous Coward (134.58.253.130) on

    The manpage for nfe says:
    "The nfe driver supports PCI Ethernet adapters based on NVIDIA's nForce Media and Communications Processors (MCP)."

    So I suppose all nForce-based motherboards have one of these onboard. Is this correct?

    Comments
    1. By jsg (210.15.216.215) on

      Some don't, for example dlg's nforce board only has sk(4) from memory.

    2. By Brad (216.138.195.228) brad at comstyle dot com on

      Not all nForce-based boards use the MCP for an Ethernet MAC. Some desktops/workstations/servers with the nForce chipsets use bge(4), re(4) or sk(4) instead for an Ethernet MAC.

  2. By Anonymous Coward (208.252.48.163) on

    How much of this is based on the reverse engineered Linux driver for forcedeth?

    Comments
    1. By jsg (210.15.216.215) on

      It was consulted for register offsets and semantics if we weren't sure what was supposed to happen. If you look at the code you'll see our driver is a hell of a lot easier on the eyes and like half the size.

      Comments
      1. By Anonymous Coward (69.70.207.240) on

        If you look at the code you'll see our driver is a hell of a lot easier on the eyes and like half the size.

        You guys never fail to amaze me... Awesome work dudes!

  3. By GeekGod (216.135.89.5) geekgod@geekgod.com on http://www.pfsense.com

    Does this driver support the hardware firewall built into the chip? If so PF + NForce would be rather nifty.

    Comments
    1. By jsg (210.15.216.215) on

      From "Technical Brief ActiveArmor Firewall PC Security and Hacker Defenses", which contains next to no actual information...

      "Plus, users who demand the most from their PC can also use the optional NVIDIA ActiveArmor Secure Networking Engine (SNE), a hardware processor that accelerates firewall processing and is available in some versions of NVIDIA nForce™ MCPs."

      This "accelerates" is most likely referring to the checksum and segment offloading the hardware supports. I don't really think this classifies as a "hardware firewall".

    2. By Marco Peereboom (67.64.89.177) marco@peereboom.us on http://www.peereboom.us

      This is quite silly. All marketing fluff.

  4. By Anonymous Coward (202.45.99.224) on

    What I want to know is what is OpenBSD doing to thwart firmware and BIOS based rootkits?

    Comments
    1. By Nate (65.94.58.104) on

      Well, nothing. The firmware and BIOS are not OpenBSD's responsibility, if you don't trust the firmware supplier, don't use the firmware - if you don't trust the hardware manufacturer's ability to make firmware, don't buy from them.

      Comments
      1. By Anonymous Coward (202.45.99.224) on

        Firmware and BIOS based rootkits could get installed on an otherwise trustworthy system after you've bought it.

        After compromising an OpenBSD installation an attacker could install a rootkit that would survive a hard drive reformatting.

        Comments
        1. By Anonymous Coward (213.84.84.111) on

          This is all silly. From an os developer point of view, hardware and firmware are the same thing. You'll have to trust both.

          Comments
          1. By Anonymous Coward (202.45.99.224) on

            What I am saying is after your OpenBSD machine has had a root level compromise you can no longer have the same level of trust in the computers hardware/firmware because malicious code could have been placed there by the attacker.

            Comments
            1. By Anonymous Coward (202.45.99.224) on

              So one thing that could be done is to somehow prevent attackers from being able to place malicious code in a devices firmware in the first place.

              Comments
              1. By Roman (169.200.215.16) on

                Please go back to class and stop pretending to be a security professional who knows what they are talking about.

                Comments
                1. By Anonymous Coward (202.45.99.224) on

                  Why don't you educate yourself before telling others to do so "Yet, an insider attacker could flash their laptop before they leave a company and then use the rootkit, which would survive reinstallation of the operating system. The insider could then gain access to the corporate network at a later time." (http://www.securityfocus.com/news/11372)

                  And here is a presentation on the issue: http://www.ngssoftware.com/jh_bhf2006.pdf

                  Clearly there is a role for operating system defenses to play. This security problem is not going away.

                  Comments
                  1. By Anonymous Coward (212.254.169.67) on

                    seen any internet auto-update bios flashing thingies on openbsd lately? no, well then, that's the real issue. on windows.

                    otherwise, if you have evil intentions and physical access the game is already over. all you need is a hammer or a floppy or a dead mouse.

                    it's another blatant case of vendors coming out with a silly, pointless technology and then security companies making a rucus a few years later.

                    as if no one saw the potential for this, and a 36-slide presentation is a demonstration, right.

                    THE END IS NIGH! REPENT!

                    Comments
                    1. By Anonymous Coward (202.45.99.224) on

                      You do not need any "internet auto-update bios flashing thingies" like what is available for windows. An attacker has the capability to write their own code that updates the BIOS from within OpenBSD, duh. How about attempting to be constructive.

                      OpenBSD already has the ability to prevent root from permanently changing contents of hard disks, a feature to prevent modifying of device firmware would imho be very useful. That way if you were running your system in the right securelevel you could be sure that the attacker has not implanted a backdoor inside device firmware.

                      Comments
                      1. By Anonymous Coward (82.197.192.49) on

                        You are overestimating the capabilities of securelevels by far.

                        What you are asking the kernel to do is anologous to asking userland to protect against an evil kernel. That's not gonna work.

                      2. By Anonymous Coward (212.254.169.67) on

                        I am being constructive, I read the article. You need root. Whether by physical access or remote exploit, your security policy at OS level has already failed.

                        And if you're worried about limiting the damage your disgruntled ex-employees can do, what's more important, worrying about a possible backdoor on some laptop or denying them access to your database servers?

                        How many companies have effective policies for this and actually carry them out? I've personally had my laptop seized from me on a Friday and still had full access to critical servers on Monday, and not in a small company.

                        The point is risk-management. This is a silly little issue, UNLESS you're running some kind of automatic BIOS updates, because then you don't need root, you just need to serve the file to the process.

                    2. By Anonymous Coward (202.45.99.224) on

                      Nor do you need physical access, duh.

                      Comments
                      1. By Roman (169.200.215.36) on

                        You would need to compromise the system and get root access to do this. Protecting unauthorized access to root privileges is the security layer of a *NIX operating systems job. Once that has been compromised the game is over. I am not implying that the advisory is not valid. I do however think that you are looking to the OS to do what may now be a new requirement for a SysAdmin anytime a box has been compromised.... (e.g. mandatory BIOS flash on compromised system rebuild becoming part of the local security policy)

                        Comments
                        1. By Anonymous Coward (202.45.99.224) on

                          Well the problem is there are so many places malicious code could be hidden. From DVD burner firmware to the BIOS and god knows what else. And if malicious code has been placed there it could easily stop your BIOS updates from overwriting the malicious code (unless you physically take out the memory chip and flash it that way).

                          Though I do agree a jumper on the motherboard is a much better way to prevent flashing of the BIOS. Though im not sure what hardware enforced methods there are available for preventing flashing of devices like DVD burners and RAID cards.

                          Thanks for offering constructive comments.

              2. By Shane J Pearson (202.45.125.5) on

                If anyone is concerned about a rootkit being installed into their BIOS THAT much, then maybe they should consider using systems with write-protectable BIOS PROM's.

                I've seen some PC's with RO jumpers and certainly my Sun machines have them.

                Honestly though why should we OpenBSD users care about this "issue". I might be concerned about Windows machines but why ask "what is OpenBSD doing about this"? They have already been doing what is needed from the start, coding with correctness in mind. If they keep on that track there is little chance a rootkit could be executed in the first place, let alone actually get write access to the system PROM.

                This is really a silly issue. Wipe out the BIOS, install something nasty in it, wipe out your HDD, install something nasty in it, steal data from it... it is all addressed the same correct way in OpenBSD and in a suspect manner with many other operating systems. So why bother coming here and asking what OpenBSD is doing about this? They already have it covered with the best attitude that can cover it for systems which might be "vulnerable".

    2. By tedu (69.12.168.114) on

      nothing.

      Comments
      1. By Anonymous Coward (202.45.99.224) on

        So it looks like a read-only jumper on the hardware will be the only defense after a root level compromise. This should be the only defense needed, if only more hardware manufacturers had such features.

    3. By Anonymous Coward (216.62.11.163) on

      It's probably a crap idea, but is there any way to checksum the firmware of the various devices? It'd probably require a set of hooks in the drivers, which would suck eggs. But, if you could get the checksum you could check for yourself to see if the firmware has been altered. Do any of the devices even support reading the firmware out or do they just allow loading in new?

      Comments
      1. By Shane J Pearson (202.45.125.5) on

        PC BIOS' can typically be extracted to a file. Look at UNIFLASH.

        Comments
        1. By btimby (12.222.146.208) on

          Yeah, but the OS has to store the checksums somewhere, and if the attacker can flash your BIOS, they can monkey w/ the checksums.

          The best answer is that this is not the job of the OS, the OS must defend against attackers running code on your machine in the first place. Failing that, the best idea is for paranoid admins to flash systems after compromise with known good firmware from their vendors. The problem with Windows and other OSes is that they don't do a good job defending against attackers in the first place, while OpenBSD does.

          Comments
          1. By Anonymous Coward (216.62.11.163) on

            Of course it wouldn't be an absolute test, unless the sums were stored offline (USB dongle, CDR or floppy). But the /etc/security script currently performs a scan that trusts file [c|m|a]times which are easily modified if you've got root. I don't place much faith in it, but it's nice to see the report after I run 'make build' I doubt checking the sums would be something people would want to do daily. Maybe only at machine check-in/out or after a compromise. So, having them offline or on a CD somewhere isn't that big of a deal. But, then again, maybe it could be part of /etc/security too.

        2. By tedu (69.12.168.114) on

          i wonder how it extracts the bios without making any bios calls.

          Comments
          1. By Anonymous Coward (202.45.99.224) on

            This issue makes it so much more difficult to clean out any nasties an attacker may have left behind after compromising your machine. It is reasonable to purchase a motherboard with read-only jumpers for the BIOS but almost no manufacturers have DVD burners, RAID cards and other system components that have read-only jumpers.

            I dont want to have to chuck out a whole PC just because there was a root level compromise of the OS.

            Comments
            1. By Shane J Pearson (202.45.125.5) on

              I dont want to have to chuck out a whole PC just because there was a root level compromise of the OS.

              I think this problem is not all that bad as far a rootkits go.

              1. Motherboard chipset boots BIOS.

              2. BIOS detects and preps some hardware, then boots boot sector of chosen boot device (HDD, etc).

              3. HDD boot sector boots and then boots a kernel or some sort of boot manager.

              4. Kernel is booted and modern OS then mostly no longer uses BIOS calls, right?

              So in effect for the rootkit in the BIOS to be executed with effect to the system OS, it needs to be executed after the system OS has come up. Right? So regardless of whether it is a good BIOS or a tainted one, an OS still would have to be compromised to get that hidden rootkit in the BIOS to be executed. In which case, if the OS could be compromised then they wouldn't need to execute the rootkit from the BIOS.

              Assuming of course that modern OS' take over completely from the BIOS at some stage and never have to use BIOS calls after that? Is this the case?

              Similar deal with DVD firmware. To have the rootkit executed, something needs to execute it (as in read the pertinent contents from the firmware to the system RAM and then execute it). That malicious something has to be on the system and thus that is malicious code on the target system. If that code can get there then why bother hiding a rootkit in some firmware? For next time after the OS is reloaded? It will still need the malicious code to execute the hidden code. There's no point. It's like trying hard to exploit a system which is already exploited. If the OS is reloaded and patched, then you have a system which is currently not exploitable, which has a hidden rootkit which currently can't be executed by the attacker. Pointless.

              I think the real danger is with something I've been waiting for for a long while... a DoS from a virus, worm, etc where a systems BIOS, boot blocks and all are simply zeroed out. I could see that causing havoc to the Windows world.

              Comments
              1. By Brad (216.138.195.228) brad at comstyle dot com on

                Please get back to the real topic and that is the NVidia Ethernet driver in -current and not some bullshit about Windows ACPI rootkits.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]