From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-April/014203.html | 129 ++++++++++++++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-April/014203.html (limited to 'zarb-ml/mageia-dev/2012-April/014203.html') diff --git a/zarb-ml/mageia-dev/2012-April/014203.html b/zarb-ml/mageia-dev/2012-April/014203.html new file mode 100644 index 000000000..59daa2131 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-April/014203.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] NVIDIA CVE, mga1: update driver, or patch and break CUDA debugger? + + + + + + + + + +

[Mageia-dev] NVIDIA CVE, mga1: update driver, or patch and break CUDA debugger?

+ Anssi Hannula + anssi at mageia.org +
+ Thu Apr 12 21:19:45 CEST 2012 +

+
+ +
11.04.2012 18:29, Anssi Hannula kirjoitti:
+> 11.04.2012 17:47, Pascal Terjan kirjoitti:
+>> On Wed, Apr 11, 2012 at 15:27, Anssi Hannula <anssi at mageia.org> wrote:
+>>> Hi all!
+>>>
+>>> We'll have to apply a patch for CVE-2012-0946 (access to arbitrary
+>>> system memory by any user) for cauldron and mga1.
+>>>
+>>> However, the security fix (patch to the nvidia kernel interface layer)
+>>> will break CUDA debugger using libcuda older than 295.40.
+>>>
+>>> While I can upgrade cauldron driver (which contains libcuda) to 295.40,
+>>> mga1 will be left with two options:
+>>> a) Apply patch, informing users that CUDA debugger will cease to
+>>>   function unless they upgrade their NVIDIA driver. However, as we have
+>>>   no backports, the remaining (non-system-breaking) option to upgrade
+>>>   their driver is to use http://onse.fi/nvidia-mgabuild/ , but I don't
+>>>   think it is very nice to link to non-official page from an advisory,
+>>>   right?
+>>>
+>>> b) Upgrade our MGA1 driver from 275.09.07 to 295.40 ("long-lived branch
+>>>   release") as well. We have
+>>>   previously shipped an update from 270.41.19 to 275.09.07 for MGA1
+>>>   (that was due to an important stability bugfix). I'm not aware of
+>>>   any blockers for this.
+>>
+>> I would vote for b provided more research about known regressions from
+>> 275 to 295 (like dropping support for some devices)
+>>
+> 
+> No device have been dropped support for there.
+> 
+> And if there were any big regressions, one'd think we would've heard of
+> them in cauldron.
+> 
+> Hmm.. Actually, there is at least one regression: When in XBMC one has
+> enabled "sync playback to display", XBMC will try to spawn a
+> nvidia-settings instance to detect the refresh rate - however with
+> 295.20+ the forked process will simply block on a mutex. This is handled
+> gracefully and XBMC fallbacks to using RANDR, however that only works
+> for integer refresh rates (and when twinview isn't enabled; we default
+> to disabled), otherwise playback won't be synced properly (AFAIU)....
+> 
+> Argh, checking more, the older XBMC 10.1 we have on mga1 apparently
+> won't handle this gracefully, but will just get stuck. I guess we could
+> patch it, but the feature wouldn't still work properly for non-integer
+> rates...
+> 
+> This is reported as
+> http://www.nvnews.net/vbulletin/showthread.php?t=177596
+
+So I think I'll go with option (a). I guess I can attach a current
+version of the nvidia-mgabuild.sh script to the bugreport and then refer
+users to it?
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1