Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nvidia releases open-source GPU kernel modules

developer.nvidia.com

Post reply on HN
Print view View original

411–415 of 415 posts

Re: Nvidia releases open-source GPU kernel modules

#411

Post by hoistbypetard »

mjan22640 wrote: post #400
hoistbypetard wrote: post #354

Earlier quoted context omitted.

> With a security-strengthened operating system, or with a VM/container/sandbox, it is possible to ensure that any opaque user-space program is no security risk. In theory this may be true. But the particular opaque user-space program is talking to a driver authored by the same team. That driver is talking to hardware that has access to all of the memory in your computer. The odds are high that a userspace program ta…

> has access to all of the memory in your computer You can use IOMMU to restrict the access to the appropriate memory sections.

I don't think, for accelerating a desktop graphics card used across your entire desktop environment, IOMMU changes my argument at all.

I believe it *does* help if, say your desktop's integrated video works natively and you have a second card you want to pass through to a gaming VM. Or if you have a server with no card shared between users and a one-card-per-user scenario.

Re: Nvidia releases open-source GPU kernel modules

#414

Post by parasense »

mort96 wrote: post #325
pjmlp wrote: post #305

Earlier quoted context omitted.

Interesting, so they can do whatever they want, provided it runs as firmware.

My view is that nvidia's hardware can work however they want it to. FOSS firmware would be cool in the same way that FOSS hardware would be cool, but it's not something I expect. I also don't care that much whether the proprietary firmware is stored on on-board flash and programmed from the factory or if it's uploaded by my OS when the driver is loaded. But I would prefer if the code I run in userspace or kernelspace…

> I also don't care that much whether the proprietary firmware is stored on on-board flash and programmed from the factory or if it's uploaded by my OS when the driver is loaded.

Bingo!

Nobody cares about firmware, that's not the issue, never was... but somehow that became the narrative repeated by people who don't know what they are talking about.

Many firmware loading drivers have caused drama over the years. I'm not sure if anybody remembers when Pottering and Sievers re-worked udev to change the ordering of how firmware was loaded from user-space, trying to improve how computers booted, by graphing firmware loads, determining the loading ordering, etc... which sometimes need to happen before it's kernel driver loads, or sometimes the driver itself is able to load the firmware, or the driver begin lazy, expects udev to load the firmware after the kmod is loaded... As a result, the kernel loads firmwares itself.

I'd say the whole firmware thing needs to be put under review, with concrete rules how they are loaded, and what their interfaces has to look like, and what hardware abstraction rules actually apply.

Post reply on HN