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/014148.html | 138 ++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-April/014148.html (limited to 'zarb-ml/mageia-dev/2012-April/014148.html') diff --git a/zarb-ml/mageia-dev/2012-April/014148.html b/zarb-ml/mageia-dev/2012-April/014148.html new file mode 100644 index 000000000..f33fc9adf --- /dev/null +++ b/zarb-ml/mageia-dev/2012-April/014148.html @@ -0,0 +1,138 @@ + + + + [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 +
+ Wed Apr 11 17:29:00 CEST 2012 +

+
+ +
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
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

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