Announcement

Collapse
No announcement yet.

Linux 6.6 To Better Protect Against The Illicit Behavior Of NVIDIA's Proprietary Driver

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

  • Originally posted by oiaohm View Post
    No that post is personal option not the legal one is that 2006 post,.
    https://yarchive.net/comp/linux/export_symbol_gpl.html Yes 2005 instead of 2006.
    That the Linus Torvald post after talking to legal in 2005. Yes that is refering to EXPORT_SYMBOL_GPL and it effect on license enforcement.

    Linus Torvald you have to be careful most of the time it his personal option how it should work not the legal reality. The legal reality closed source modules should stay well clear of EXPORT_SYMBOL_GPL.

    Please note this is before DMCA existing. DMCA is designed to enforce Intent. "Intent matters a LOT." is more true today than 2005.


    ​There is more to this.


    Remember Intel and AMD both developed DMA_BUF they both allowed their patent techs to be used. Nvidia paid nothing to the development of DMA_BUF. Guess what here Nvidia said since DMA_BUF was Linux world only they did not need to pay for the patents around DMA_BUF so AMD/Intel could not use DMA_BUF patents to offset their patent payment to Nvidia.

    Remember 80 percent of computers don't have dGPU. Nvidia the less than 20 percent that gets the most revenue was the party who was not paying for development of different Linux things. Party who paid for development of items has the right to license it how they see fit. Nvidia does not have a magic right to break those licenses. Yes the removal of EXPORT_SYMBOL_GPL off of many DMA_BUF symbols came after Nvidia agreed to accept that DMA_BUF releated patents were real patents so AMD/Intel could use those to off set patent cost.
    There is nothing patented in DMA_BUF. You confuse what patent is and what license is.. You can have license without patent, patent has specific number at patent office. If you provide me number of that patent I might believe you but in fact due to how GPL license works with patent, I don't think patent would even matter.

    Intend matters if you can prove actual GPL infringement (example with routers above i mentioned - this is moment intend matters a lot).

    GPL is also distribution license not use license. In fact in manners of use GPL allows you do to anything, it restricts conditions of distribution. Nvidia doesn't distribute GPL code so you cannot sue them.

    And btw. Linus Torvalds did discuss that with lawyers. On discussion of EXPORT_SYMBOL_GPL he explicitly mentioned he consulted with lawyers. Later with banning modules he was very explicit about fair use cases of kernel so i assume he absolutely knows what he is talking about. He absolutly doesn't like Nvidia (famous F you Nvidia) but he himself doesn't consider what Nvidia does is illegal. Fact he explicitly says, go merge that with your Canonical, SUSE, Red Hat kernels first means he clearly doesn't want to hold responsibility in spirit of law. And since none of those companies did that, I assume they also know that it is very stupid idea.

    Comment


    • Originally posted by piotrj3 View Post
      There is nothing patented in DMA_BUF. You confuse what patent is and what license is.. You can have license without patent, patent has specific number at patent office.
      Exactly. A license in this context is to allow usage of copyrighted software under the terms of license (GPLv2). Section 7 of GPLv2 includes a clause that essentially states that if you distribute a program under GPLv2 and you hold any patents that cover the program, you must grant a royalty-free patent license to anyone who uses, modifies, or distributes the program.

      Comment


      • Originally posted by mSparks View Post
        And none of your hypotheticals materialised, or mattered
        Lack of homework there. Oracle did end up refactoring dtrace to use BPF instead in 2018


        Guess why quite a few EXPORT_SYMBOL_GPL functions they were incorrectly using came back and bit them hard. They did not notice the changes..

        mSparks basically you don't know enough about the Oracle case to use it and by attempt to use it all you are going to do is make a fool out of yourself. Yes Oracle was caught by the change in function of the.

        Originally posted by mSparks View Post
        presumably one that would take more than 5 seconds to replace if it did "magically up and disappear."
        Slightly changing function was worse with ktime_get as it resulted in the dtrace making people think the issue happed at the wrong time so stuffing up their debugging.

        The Oracle case of usage of EXPORT_SYMBOL_GPL in dtrace end up showing that its such a bad idea then end up refactoring the complete way the do dtrace.

        Yes 2014 is when you write up is and Oracle only had to suffer though 4 more years of pain to 2018 with dtrace from incorrectly using EXPORT_SYMBOL_GPL stuff to learn their lesson. Yes the bit you quoted the link in it does not work and you did not notice or checkout why.

        This is the case with EXPORT_SYMBOL_GPL lot of cases kernel developers just need to do their normal work and normal usage of EXPORT_SYMBOL_GPL with the majority of the time person incorrectly using it learns that it a really bad idea and refactors so they don't do it. Nvidia is the rare stubborn one.

        Comment


        • Originally posted by piotrj3 View Post
          There is nothing patented in DMA_BUF. You confuse what patent is and what license is.. You can have license without patent, patent has specific number at patent office. If you provide me number of that patent I might believe you but in fact due to how GPL license works with patent, I don't think patent would even matter.
          This is horrible wrong. DMA_BUF required to work effectively AMD/Intel to alter the GPU MMU design. This tech is patented. Do remember Nvidia saying that did not want to implement DMABUF so they wanted to use eglstreams instead. Yes the patents here is why there was so much kicking and screaming by Nvidia not to implement DMABUF.

          Originally posted by Jakobson View Post
          Exactly. A license in this context is to allow usage of copyrighted software under the terms of license (GPLv2). Section 7 of GPLv2 includes a clause that essentially states that if you distribute a program under GPLv2 and you hold any patents that cover the program, you must grant a royalty-free patent license to anyone who uses, modifies, or distributes the program.
          GPL is both a software license and a patent license. That GPL section says you have to provide the patent license but it does not say you have to provide it for software that is not under GPLv2.

          Comment


          • Originally posted by Khrundel View Post
            You should pause for a minute and choose your ground. You may still insist on GPL only as a mechanism for keeping kernel stable, but you'll have to admit this case was a grave abuse of this mechanism, accepting dmabuf API as gpl only export should never happen in first place, patented API, even if you believe in such nonsense, should have no place within free kernel. Longevity of this crisis and fact that AMD and/or Intel have extorted some money should show all these gpl export just doesn't work as intended and should be removed instead of forcing.
            Few things. Linux kernel only has to acquire patents for it users under the terms of Linux kernel license. Nvidia said they did not want to use DMABUF back when it was implemented and other users like AMD/Intel/Arm were perfectly fine with it being GPLv2 so why not accept it as GPLv2. Also remember eglstreams Nvidia did attempt to implement their own alternative to DMABUF and Nvidia was not wanting to pay for the patent license so they could use it.

            Nvidia does extort money out of AMD and Intel with patent licenses as well. The DMABUF is just business as normal. Nvidia does not provide stuff to opengl and vulkan standard without getting their pound of flesh in patent licenses to implement the features in hardware.

            Linux kernel developers are paid employees and the company behind them at times expects to be paid if you want their code usable in non GPLv2 works.

            Originally posted by Khrundel View Post
            GPL clearly allow using any interface of GPLed software, you won't be able to run any non-GPL software on linux if just calling a function from GPL library or system call from GPL kernel would require GPL license from caller.
            This is why you need to check out the Linux kernel license.


            The Linux kernel license has a special exception so that GPLv2 license does not spread to user-space software. There is a reason why LGPL exists and why GCC has a special exception and so on.

            Khrundel you need to take a closer look at so called GPL licensed libraries. You will find they are LGPL or have some other exception clause that the GPL license viral nature does not happen.

            Originally posted by Khrundel View Post
            Google v Oracle say you don't need a license to implement some inteface (API/ABI). That's it, period. Out of tree kernel modules are not derived work of kernel, they are separate software products just implementing/using required interfaces following fair use rules.
            That ruling does not apply. That ruling is to make a clone of interface(API/ABI). This is using the GPLv2 function itself. Linux kernel has the special exception for user-space so it GPLv2 does not infect user-space.

            Derived work is not as clear cut.

            You need to read above. Sorry copyright laws on derived work does not say out of tree kernel modules are not derived works also does not say they are this is a grey zone. Depending on what the out of tree Linux kernel module has used it could be derived work like it or not.

            Something to be aware of some functions are clearly not GPL that are EXPORT_SYMBOL because they are either MIT/BSD code that happens to exist in the BSDs as well. Yes the stuff under EXPORT_SYMBOL does the Google v Oracle ruling come into play. Yes when the EXPORT_SYMBOL is a derived work from BSD and the like in the Linux kernel then the GPLv2 viral nature does not apply.

            Linux kernel is not licensed to support closed source kernel modules safely and it been that way since day one. On the other hand Linux kernel is licensed to have user-space drivers and applications safely also since day one. Writing closed source kernel driver on Linux and being legal you are serous-ally looking for license loopholes.

            Comment


            • Originally posted by oiaohm View Post
              Guess why quite a few EXPORT_SYMBOL_GPL functions they were incorrectly using came back and bit them hard. They did not notice the changes..

              mSparks basically you don't know enough about the Oracle case to use it and by attempt to use it all you are going to do is make a fool out of yourself. Yes Oracle was caught by the change in function of the.



              Slightly changing function was worse with ktime_get as it resulted in the dtrace making people think the issue happed at the wrong time so stuffing up their debugging.

              The Oracle case of usage of EXPORT_SYMBOL_GPL in dtrace end up showing that its such a bad idea then end up refactoring the complete way the do dtrace.

              Yes 2014 is when you write up is and Oracle only had to suffer though 4 more years of pain to 2018 with dtrace from incorrectly using EXPORT_SYMBOL_GPL stuff to learn their lesson. Yes the bit you quoted the link in it does not work and you did not notice or checkout why.

              This is the case with EXPORT_SYMBOL_GPL lot of cases kernel developers just need to do their normal work and normal usage of EXPORT_SYMBOL_GPL with the majority of the time person incorrectly using it learns that it a really bad idea and refactors so they don't do it. Nvidia is the rare stubborn one.
              So basically, you made it all up, and don't have any example of anything you are saying.

              Have you been copying leaked windows source code into the kernel like Christoph Hellwig as well?

              I mean, I can't find an example of either of you doing so, but because hypothetically you could in an alternate reality everyone should just accept is as true right?

              Originally posted by oiaohm View Post
              Lack of homework there. Oracle did end up refactoring dtrace to use BPF instead in 2018
              https://www.brendangregg.com/blog/20...inux-2018.html
              ROFL. No, that is verifiable BS

              Additional kernel tracing features merged with recent Linux kernel releases. DTrace makes use of these additional features. - oracle/dtrace-linux-kernel
              Last edited by mSparks; 02 September 2023, 08:31 PM.

              Comment


              • Additional kernel tracing features merged with recent Linux kernel releases. DTrace makes use of these additional features. - Commits · oracle/dtrace-linux-kernel


                Should have looked deeper Oracle stopped the version 1.0 of the dtrace kernel module in 2018. It is version 2.0 now. Yes the patches for 2.0 kernel code don't touch EXPORT_SYMBOL_GPL items that include ktime_get.

                Dtrace 2.0 has the same user interface as Dtrace 1.0. Except now for the questionable items it use BPF. Yes BPF happens to have wrappers over all those. Dtrace 2.0 on Linux has been more reliable on Linux than Dtrace 1.0.

                The performance difference between Dtrace 1.0 and Dtrace 2.0 is a whooping 0.0001 percent worse for Dtrace 2.0. Yes not using EXPORT_SYMBOL_GPL comes with a performance cost sometime that small its really what hell.

                The reality on Linux is there is more than 1 way to implement most things. Linux kernel does support kernel drivers using usermode programs. Yes the usermode programs run by usermode helper feature of the Linux kernel is not restricted by GPLv2 terms the Linus kernel exception applies to it.

                Yes Dtrace is one of the examples that there is more than 1 way to implement stuff under Linux and that most of the time there is no need to be using EXPORT_SYMBOL_GPL items. It might take awhile to find how to do it otherwise but it worth the time to have a more stable solution..

                So your no is wrong mSparks in fact dtrace is example that when parties say they need to use EXPORT_SYMBOL_GPL most of the time they wrong its they want to use EXPORT_SYMBOL_GPL because they don't want to invest the time to find how to do it the other ways using the more stable interfaces.

                Dtrace is not a good example for why EXPORT_SYMBOL_GPL is wrong in fact with the issues that Dtrace 1.0 on Linux had its a really good example why third party modules should avoid EXPORT_SYMBOL_GPL.

                PS here the release notes from Oracle.

                DTrace v2.0 is a reimplementation of DTrace that uses existing Linux kernel tracing facilities,
                like eBPF, which didn't exist when DTrace was first ported to Linux. The new implementation
                removes DTrace dependencies on specialized kernel patches.​
                Notice something all those Dtrace 2.0 kernel patches are optional the new orcale Dtrace 2.0 95% works without them on a mainline Linux kernel even without the kernel module. Dtrace 2.0 for Linux is a major refactor.
                Last edited by oiaohm; 02 September 2023, 07:54 PM.

                Comment


                • Originally posted by oiaohm View Post
                  Should have looked deeper Oracle stopped the version 1.0 of the dtrace kernel module in 2018.
                  You just want to keep diggin eh.

                  It's still maintained and used.
                  Additional kernel tracing features merged with recent Linux kernel releases. DTrace makes use of these additional features. - GitHub - oracle/dtrace-linux-kernel at v1/5.18


                  So much so, that Oracle UEK is in the process of overtaking Redhat to become the de facto standard Enterprise Linux Distribution.

                  Originally posted by oiaohm View Post
                  Dtrace is not a good example for why EXPORT_SYMBOL_GPL is wrong
                  DTrace and ktime_get are a good example why EXPORT_SYMBOL_GPL is about a valuable to the Linux kernel as a fart in an elevator.
                  I think you were trying to make the case to keep EXPORT_SYMBOL_GPL. But all you've done so far is justify deleting it completely.
                  If you can't give a single example of a function that should stay EXPORT_SYMBOL_GPL.
                  And there are numerous examples of it being problematic
                  why should it remain?

                  Comment


                  • Originally posted by oiaohm View Post

                    Few things. Linux kernel only has to acquire patents for it users under the terms of Linux kernel license. Nvidia said they did not want to use DMABUF back when
                    All of that doesn't matter. There are kernel maintainers who review and accept any patches. Assuming you are right and intention behind GPL only was to protect sensitive structures, that maintainer shouldn't accept these patches, he should've reject them saying "sorry, guys, looks like there is some misunderstanding here, GPL only was never intended to gatekeep some API, so either change this to usual export or implement some protected usual export counterpart.
                    Nvidia does extort money out of AMD and Intel with patent licenses as well. The DMABUF is just business as normal. Nvidia does not provide stuff to opengl and vulkan standard without getting their pound of flesh in patent licenses to implement the features in hardware.
                    Sure. Nvidia is a commercial company, they will use and abuse every way to get profit. But imagine nvidia would bribe some guys from kernel team and inject kernel with something which allows them to cripple competition. Will you still protect these guys decision or you will at least call this decision mistake and ask what measures were taken to prevent such case again? Just to remind, we are discussing news about enforcing GPL only rule which is proven to be abused in the past, see dmabuf case. And remember, it wasn't something very harmful to nvidia, they target server and workstation market with products for unix-like system. When some guy can't use his laptop with linux because of nonfunctional PRIME it is he who harmed and linux reputation.
                    Linux kernel developers are paid employees and the company behind them at times expects to be paid if you want their code usable in non GPLv2 works.
                    We are talking about API. How it came when FSF zealot is advocating such great abuse of copyright law? No freedom for enemies of freedom?


                    This is why you need to check out the Linux kernel license.


                    The Linux kernel license has a special exception so that GPLv2 license does not spread to user-space software. There is a reason why LGPL exists and why GCC has a special exception and so on.
                    OMG. Just look at the adding date,
                    How many times I should repeat to you, this texts have no legal meaning. GPL is viral and it is final, everything based on GPL must be republished under GPL. Period. You may look at this file as some sort of clarification, nothing more.

                    If you really believe this txt file creates some exceptions then imagine two companies which both now will fork kernel repo.
                    Company A will add into this directory another exception, they will say they do not allow redistribution of code marked as "COMPANY_A_PROPERTY" without commercial license and then will implement some great feature marked such and will start to sell this as linux+.
                    Company B will add another file to LICENSES directory, just add note "we, company B, also release this source code under MIT license", and then create internal fork of this MIT repo where they will do some private development and later release commercial superlinux.
                    Both this cases impossible only due to the fact that no derived work can be relicensed under any terms except GPL2. Without any exceptions.

                    Khrundel you need to take a closer look at so called GPL licensed libraries. You will find they are LGPL or have some other exception clause that the GPL license viral nature does not happen.
                    Yes, GPL2 is not only copyeft license. But that doesn't matter, kernel is licensed under GPL2 so only GPL2 terms apply.


                    That ruling does not apply. That ruling is to make a clone of interface(API/ABI).
                    No. Making clone of interface is when you are renaming Graphics to Canvas and draw() to paint() and vice versa. Google's java is using same interfaces for libraries and that was Oracle claim, they argued function names and parameter list are copyrightable. Court ruled it fair use.

                    This is using the GPLv2 function itself.
                    You are using vague term "using" to prevent clarity? What "using" means? Calling a function? You will advocate someone needs license to call a function?
                    Linux kernel has the special exception for user-space so it GPLv2 does not infect user-space.
                    And these exceptions strictly violate GPL2 so they are null and void.
                    So it is another either or situation. It either interaction with GPL kernel using it's API poisons interacting part which means libc, regardless of it's own license, becames GPL2 and so anything intended to compile with gcc is derived work of GPL2 and so must be licensed under GPL2 and there are no single programmer who haven't violated GPL2...
                    or calling a function is a fair use, and then kernel module must not be derived work.

                    And you can't escape through "there are exceptions for system calls": libc had started to work with linux (maybe using even linux specific system calls) long before file with these exceptions was added.

                    You need to read above. Sorry copyright laws on derived work does not say out of tree kernel modules are not derived works
                    Google vs Oracle does. Software can implement an API without becoming derived work.
                    Something to be aware of some functions are clearly not GPL that are EXPORT_SYMBOL because they are either MIT/BSD code that happens to exist in the BSDs as well. Yes the stuff under EXPORT_SYMBOL does the Google v Oracle ruling come into play. Yes when the EXPORT_SYMBOL is a derived work from BSD and the like in the Linux kernel then the GPLv2 viral nature does not apply.
                    Khm... So you are telling me that nvidia kernel module is derived work and must be relicensed under GPL because it uses GPL functions and simultaneously that GPL kernel contains some nongpl functions?
                    Looks like contradiction to me.

                    Kernel does not contain any nongpl part. Even if some file says it's licensed under MIT it is still gpled. If someone will modify that file within kernel tree, rights to this modified version will be controlled by GPL2. Compatibility between MIT and GPL2 comes from the fact that MIT allows relicensing so it is possible to apply viral nature of GPL to MIT licensed code.

                    Comment


                    • Originally posted by mSparks View Post
                      You just want to keep diggin eh.

                      It's still maintained and used.
                      Additional kernel tracing features merged with recent Linux kernel releases. DTrace makes use of these additional features. - GitHub - oracle/dtrace-linux-kernel at v1/5.18

                      Little fact its a stale branch as of a year ago is no its not maintained any more. You did not read the date did you.

                      Used yes there are some people still using dtrace 1.0. Maintained the answer is Dtrace 1.0 is not maintained any more in fact Oracle UEK is changing over to Dtrace 2.0 even on long-term supported releases.

                      Originally posted by mSparks View Post
                      If you can't give a single example of a function that should stay EXPORT_SYMBOL_GPL.
                      ktime_get caused tracing mistake by dtrace due to minor changes in operation is one of the examples why EXPORT_SYMBOL_GPL needs to be respected.

                      Comment

                      Working...
                      X