Announcement

Collapse
No announcement yet.

Nouveau: NVIDIA's New Hardware Is "VERY Open-Source Unfriendly"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Luke
    replied
    We need someone to produce HW that CAN be opened

    Originally posted by bridgman View Post
    Sanitizing microcode is not the problem -- we would need to have different hardware as well. If we open up sanitized microcode for the Linux market then we're basically providing all the HW info required to easily reverse-engineer the un-sanitized microcode used for other markets.
    What we need is hardware that CAN be opened. There are a lot of small devices out there selling to markets smaller than the Linux market for GPU's. Selling us HW that supports DRM and which we have to reverse engineer gives us an incentive to attack the DRM code while we are at it. Nvidia may pay for that one. I could see their fancy card running with their signed firmware loaded-and another, second layer added just above it that alters the functions of some gates to defeat their DRM. We have the binary code and can open it in a hex editor. We can also examine all inputs vs all outputs do determine equivalent bare hardware with the same published command set. Finally, this combined with binary examination of the firmware could work out what is HW and what is firmware that can be changed.

    A lot of us would settle for a card made from an FGPA to be unrelated to any other card, and unable to keep up with any paid game. Cards have had enough power to play the Linux games for many years, look how well the old (but power hogging) Nvidia Gt9800+ ran on Nouveau with clocks all the way up. Using an FGPA would make the card cheap to make-or someone could offer it as a hobbyist kit to get into a different market and not be expected to be able to play DRM'ed movied and games. Remember, those who object to microcode being kept secret usually also object to paid games and don't subscribe to Netflix, Hulu, etc.

    As I've said before, the way things are going I suspect that whole computers will have to be made from FGPA's just to defeat locked boot in the future. Big servers will always be able to run Linux but might end up locked to RHEL or Ubuntu LTS.

    Until that time, how about independent security audits of the hardware and the microcode, hell of the drivers too under NDA by security experts in mutually opposing camps? From where I sit that is the main objection to secret hardware or firmware, regardless of how loaded. In the meantime, things like watching network activity in Wireshark for packets sent over the Internet to hardware makers is a deterrent to the "phone home" behavior feared by so many of us. Yes, I check this stuff myself. That's how I found out that Ubuntu's flashplugin installer has dependencies that phone home automatically, even if only to the package repo webpage. Another good reason not to use flash...

    Leave a comment:


  • nanonyme
    replied
    Originally posted by nanonyme View Post
    I'd see it more as opening it up for educational purposes. You'd end up doing it on too old hardware anyway to be useful for end-users
    Jumped in the middle of the conversation so not totally sure what I was going for was clear with earlier: So fully open microcode including toolchains so it can be used by hackers and students to figure out how hardware works (and get a good impression of why it's a good idea to have the abstraction layer there)

    Leave a comment:


  • nanonyme
    replied
    Originally posted by bridgman View Post
    We do revisit all the policies every couple of years but if the microcode isn't changing then I guess I don't understand how opening it would help the community at all, other than allowing a slightly broken and more-than-slightly destructive set of guidelines to continue unchanged.

    I don't think we would open up the hardware block design so I still don't see how the microcode helps outside of the "eww, mustn't touch binary microcode in our distro but can cheerfully recommend HW with binary microcode we don't have to touch" mindset. Taking HW microcode and calling it software doesn't magically mean you can study or change it.
    I'd see it more as opening it up for educational purposes. You'd end up doing it on too old hardware anyway to be useful for end-users

    Leave a comment:


  • bridgman
    replied
    Originally posted by nanonyme View Post
    Ok. Might want to consider raising the matter internally when it's a more viable option. I'm not sure whether it would bring that much money back to AMD but it would be a nice gesture to the community
    We do revisit all the policies every couple of years but if the microcode isn't changing then I guess I don't understand how opening it would help the community at all, other than allowing a slightly broken and more-than-slightly destructive set of guidelines to continue unchanged.

    I don't think we would open up the hardware block design so I still don't see how the microcode helps outside of the "eww, mustn't touch binary microcode in our distro but can cheerfully recommend HW with binary microcode we don't have to touch" mindset. Taking HW microcode and calling it software doesn't magically mean you can study or change it.
    Last edited by bridgman; 05 May 2015, 01:58 PM.

    Leave a comment:


  • nanonyme
    replied
    Originally posted by bridgman View Post
    We could potentially do it for old HW blocks where the current HW implementation (and hence microcode state bits & toolchains) was totally different, but I don't think enough time has passed for that to be viable yet -- there are "previous generation" HW blocks but most of them did not use microcode
    For better or worse, once you move a block to a microcode-based HW design you don't need to update it as frequently from one HW generation to the next.
    Ok. Might want to consider raising the matter internally when it's a more viable option. I'm not sure whether it would bring that much money back to AMD but it would be a nice gesture to the community

    Leave a comment:


  • bridgman
    replied
    Originally posted by nanonyme View Post
    How about only doing it for old cards?
    We could potentially do it for old HW blocks where the current HW implementation (and hence microcode state bits & toolchains) was totally different, but I don't think enough time has passed for that to be viable yet -- there are "previous generation" HW blocks but most of them did not use microcode.

    For better or worse, once you move a block to a microcode-based HW design you don't need to update it as frequently from one HW generation to the next.

    Leave a comment:


  • nanonyme
    replied
    Originally posted by bridgman View Post
    Sanitizing microcode is not the problem -- we would need to have different hardware as well. If we open up sanitized microcode for the Linux market then we're basically providing all the HW info required to easily reverse-engineer the un-sanitized microcode used for other markets.
    How about only doing it for old cards?

    Leave a comment:


  • bridgman
    replied
    Originally posted by boltronics View Post
    Does this mean that it is technically possible to produce two microcode images - one free and unsupported, but exclusively targeted towards the free software community with none of the DRM functionality included at all, in addition to the existing proprietary one? If it were possible to produce a significantly "cut-down" version of the microcode that only enabled basic acceleration and power management functions, that may be sufficient to at least satisfy the "free operating system" component part of the problem.
    Sanitizing microcode is not the problem -- we would need to have different hardware as well. If we open up sanitized microcode for the Linux market then we're basically providing all the HW info required to easily reverse-engineer the un-sanitized microcode used for other markets.

    Leave a comment:


  • boltronics
    replied
    Originally posted by bridgman View Post
    All of our GPU markets except Linux (so >95% of our sales) have a hard requirement for robust DRM including the ability to respond quickly to a security breach. In order to do that we need to keep some part of the programming model secret, and after analysis it really came down to driver or microcode.
    Does this mean that it is technically possible to produce two microcode images - one free and unsupported, but exclusively targeted towards the free software community with none of the DRM functionality included at all, in addition to the existing proprietary one? If it were possible to produce a significantly "cut-down" version of the microcode that only enabled basic acceleration and power management functions, that may be sufficient to at least satisfy the "free operating system" component part of the problem.

    Leave a comment:


  • Luke
    replied
    If meat were grown on trees

    Originally posted by chithanh View Post
    Well, analogies are always imperfect, but I think that mine is still better than yours.

    An even more accurate analogy could be:
    • A salad bar which sells two things: 1. lettuce 2. a mix of other salad ingredients and yoghurt dressing
    • A steakhouse which sells lettuce (and non-vegetarian dressing), but community members walk around the place giving you a mix of vegetables and vegan dressing (reverse engineered from the non-vegetarian dressing) to go with that lettuce. However there is a recently opened new section of the steak house which the owner has locked down so community members cannot access it (what this Phoronix article is about).


    So as a vegan you have the choice: Go eat only lettuce at the salad bar, or go to the steakhouse and enjoy a salad with a variety of ingredients.

    If we now put
    Unaccelerated graphics = lettuce
    3D acceleration, power management, etc. = other salad ingredients
    People insisting on free firmware = vegans,
    People ok with proprietary firmware = lacto-ovo vegetarians,
    FSF = the vegan association,
    AMD = salad bar owner,
    NVidia = steakhouse owner,
    Putting firmware in ROM = growing meat on trees

    Then the analogy mostly fits and explains nicely why the FSF cannot endorse AMD graphics.
    Putting firmware in ROM = growing meat on trees? Not exactly. The vegan objection to meat is based on what the animals go through to provide it(caged/tortured/killed). If meat grew on trees without animals at all, it would itself be considered vegan, comparable to fruit. In other words, this would be a complete solution to the vegan ethical objection to meat.

    By comparison, putting firmware in ROM does not help anyone understand or modify either the firmware or the underlying hardware, one of the free software issues. Installing say, iOS to s samrtphone's flash ram doesn't make it any freer or more safe than Windows on disk, after all. The advantages are limited to faster boot times if it doess not have to be read from the disk, and greater difficult of malicious replacement. If an exploit is in the unmodified original firmware, this becomes a disadvantage.

    Auditability and the ability to modify code (such as removal of unwanted Hollywood anti-features) require documented firmware or at least a public acceptance and de facto licensing of reverse engineering. If the Nvidia firmware has been reverse engineered, that would be the basis of the FSF's endorsement but due to Nvidia's practices should apply only to USED nvidia cards. This is because the endorsement is based on a community success against Nvidia, not anything Nvidia did themselves. A similar effort could reverse engineer AMD firmware, isn't there that same effort against another vendor's product that is essentially a licensed copy of r600?

    Here's another problem: endorsing Nvidia today endorses a lack of proper power management. With the global warming mess this means extra power consumption. This is like giving up meat but switching to a brand of GMO soy grown with fertilizer derived from the Canadian tar sands pits. The exception is a machine using manual or scripted control on a known good card, setting to its lowest power state for normal desktop work, medium for video, and highest for games. I ran my AMD cards that way before the PM code was released. If the Nouveau team gets automated power management working with Fermi, I will be happy to try it out with the old GTS450 I have on the shelf, a card comparable at mid-clocks on Nouveau to my HD6750 on Radeon in 2013 locked to the middle clock setting. Nouveau actually seems close to Radeon for per-clock performance, it's reverse engineering the power management that's holding tbings up. Nvidia did release some code and it helped, but with less Nvidia input to Nouveau the driver differences are probably more drastic than between Catalyst and Radeon.

    As for that locked shit coming in the future, that's like the bologna sandwitches served in DC Central Cell Block (jail). Do not eat it, sure as hell do not buy it!

    Leave a comment:

Working...
X