Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
On Thu, Feb 15, 2024, at 15:45, Mario Limonciello wrote: > On 2/15/2024 12:39, Henrique de Moraes Holschuh wrote: >> While adding linux-firmware's amdtee/ directory to the Debian >> amd64-microcode package, I have noticed that the linux-firmware WHENCE file >> mentions a symbolic link that is not present in the git repository. >> >> The missing symlink is: >> amdtee/amd_pmf_v3.bin -> 773bd96f-b83f-4d52-b12dc529b13d8543.bin >> >> Is the amd_pmf driver functional without that symlink ? >> > > symlinks are created by copy-firmware.sh Thanks. I have to take that into account, then. Hopefully this is the first instance of that bug in the amd64-microcode packaging, I will check every other file in there to ensure no links were missed. -- Henrique de Moraes Holschuh
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
While adding linux-firmware's amdtee/ directory to the Debian amd64-microcode package, I have noticed that the linux-firmware WHENCE file mentions a symbolic link that is not present in the git repository. The missing symlink is: amdtee/amd_pmf_v3.bin -> 773bd96f-b83f-4d52-b12dc529b13d8543.bin Is the amd_pmf driver functional without that symlink ? -- Henrique de Moraes Holschuh
Re: Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?
On Tue, Feb 13, 2024, at 17:04, Diederik de Haas wrote: > I'll add the `amdtee` dir to `Files-Excluded` in firmware-nonfree and > Henrique > can add those files to the amd64-microcode package. Agreed. For now, let's have amd64-microcode package to be the "SoC-and-CPU-related" firmware distribution for AMD, and keep the firmware for other AMD hardware, such as GPU adapter cards in the other firmware packages. Since Diederik confirmed that amd-tee has never been shipped in a firmware-* package in Debian, it will not cause issues for amd64-microcode backports. Good, I can just have it on every branch, then. I am currently waiting my updated gpg subkey to be activated (it is already in keyring.d.o, but it needs to wait for the monthly push). It should happen in about 10 days, and then I will upload the new packages to unstable. Meanwhile, I will prepare the updated packages in salsa.debian.org, if there's a need for a faster upload, we can ask someone to sponsor it next week. PS: Mario, we're considering the newer AMD processor microcode sitting in linux-firmware to be a non-critical functional update since nobody was informed otherwise AFAIK, and I could not find the newer revisions listed in any AMD advisories. If you know otherwise, drop us a note privately (e.g. inform the Debian security team, or inform me directly) and we will issue it as a security update. -- Henrique de Moraes Holschuh
Re: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs
On Tue, 26 Jan 2021, Debian Bug Tracking System wrote: > > reassign 970395 amd64-microcode > Bug #970395 [src:firmware-nonfree] firmware-nonfree: Please add AMD-SEV > firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs > Bug reassigned from package 'src:firmware-nonfree' to 'amd64-microcode'. > Ignoring request to alter found versions of bug #970395 to the same values > previously set > Ignoring request to alter fixed versions of bug #970395 to the same values > previously set > > # please update to latest bc9cd0b7b0e96038ccc041ff409948d8f176142d > > # 20/11/2020 in linux-firmware > > done > Unknown command or malformed arguments to command. > > bc9cd0b7b0e96038ccc041ff409948d8f176142d has: > Unknown command or malformed arguments to command. > >Update AMD SEV firmware to version 0.17 build 44 for AMD family 17h > Unknown command or malformed arguments to command. > > processors with models in the range 00h to 0fh. > Unknown command or malformed arguments to command. > > Update AMD SEV firmware to version 0.24 build 7 for AMD family 17h > Unknown command or malformed arguments to command. > Too many unknown commands, stopping here. I will look into this soon, probably this weekend. I will direct any questions I have to the submitters and to this bug report. However, I have to find out if these firmware data files should go into the early initramfs like the microcode (and *how*: naming, packaging into a single file? the early initramfs works differently than normal firmware loading). Or should it go into the normal initramfs ? Or both? If you have the answer to these questions and can follow up with them, it will hasten the fix since I will not have to spend time looking for the answers. -- Henrique Holschuh
Re: Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs
On Sun, Sep 27, 2020, at 18:27, Ben Hutchings wrote: > On Sun, 2020-09-27 at 13:43 -0300, Henrique de Moraes Holschuh wrote: > > Answering from my phone, please excuse brevity and other netiquete > > issues such as poor quoting cleanup. This is still true :( > However, we normally take all changes from linux-firmware.git up to a > specific tag, and that might not be appropriate for the AMD microcode > given the potential for system-breaking regressions. So, until a more workable solution is found, if you need amd64-microcode to carry any other data files, please file a bug. If I am behind an update for any reason, please file a bug. I will see it and act on it. You don't need to wait to see if I noticed the upstream update or not, file the bug as soon as you're prepared to. There was a mention about a pending security update of SES firmware in this thread. If this needs an amd64-microcode release and if the ses firmware should go into that release, please explicitly say so, preferably in a new bug report, so that we can keep this one open until a final decision is done whether we should drop amd64-microcode as a separate package or keep it just for scripts, or keep the status-quo. -- Henrique de Moraes Holschuh
Re: Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs
Answering from my phone, please excuse brevity and other netiquete issues such as poor quoting cleanup. On Fri, Sep 25, 2020, at 09:14, maximilian attems wrote: > Dear Henrique, > > It be great to get your input, hence repinging (; > > Especially as linux-firmware is the common upstream source, it be ideal to > ship > the amd64 mircrocode out of our firmware packages. We can ship the ucode and other related data files in linux-firmware-nonfree, yes. But the initramsfs glue needs.to go somewhere. Either it can stick in the older package, and a depends ensures it gets installed, or linux-firmware-nonfree must carry it as debian packaging. I.e. I am not opposed. But there is more than a bunch of data files involved: the initramsfs integration must be somehow handled by whatever ships the data files. However, you can also try opening a bug against amd64-microcode with a pointer to new upstream releases should I miss any for longer than a week, or asking for more files to be switched to amd64-microcode, e.g. if the ses datafiles should be in there along with the ucode ones, this could be done. Either way is fine, what does the majority of the maintainers of linux-firmware-nonfree think about it ? > On Sun, Sep 20, 2020 at 10:36:12AM +0200, maximilian attems wrote: > > Dear Henrique, dear debian kernel maintainers, Cc: Michael, > > > > Would you agree to generate the amd64-firmware packages directly out of the > > debian > > linux-firmware source package? > > > > This way the microcode would be updated on every linux-firmware non-free > > upload? If you guys think this will improve update delivery latency in Debian, I am not opposed. But ucode updates go to security, backports and stable unless there is too little feedback to gauge regression risk. Is that viable for the whole of linux-firmware-nonfree ? If not, it would make sense to keep the amd64 ucode in a separate package. > > I am asking as it keeps nugging me to have to outcomment the updates of that > > microcode in the changelog (there is again a new one for the upcoming > > 20200918). This should be very very easy to automate, but... > > Would you want to be added in counterpart to the uploaders of > > firmware-nonfree? I can do it myself if there is a need to upload a new release and I have to do that upload, but if you guys are using salsa, I'd need to be in the salsa group you're using. > > Thank you very much for your amd64 microcode work. > > > > kind regards, > > maximilian > > > > On Tue, Sep 15, 2020 at 04:55:43PM +0200, Michael Musenbrock wrote: > > > Source: firmware-nonfree > > > Severity: important > > > > > > Dear maintainer, > > > > > > first of all thanks for maintaining and packaging the linux-firmware > > > files repository as debian packages. > > > > > > We currently need to manually obtain the > > > linux-firmware.git:amd/amd_sev_fam17h_model3xh.sbin [1] file on > > > our AMD EPYC servers. The firmware files containing the AMD SEV firmware > > > closing security vulnerabilities [2] > > > and fixes bugs and adds improvements to the AMD SEV implementation. > > > > > > I'm most likely unqualified for legal questions but the LICENSE.amd-sev > > > [3] reads quite similar to the already > > > added amdgpu license [4]. So I hope this is not the reason, why those > > > files were not added in the past. > > > > > > The severity was choosen because it fixes a security vulnerability, > > > please change accordingly if you think > > > it is wrong. > > > > > > Thanks in advance. Best regards, > > > michael > > > > > > [1] > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd > > > [2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9836 > > > [3] > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amd-sev > > > [4] > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amdgpu -- Henrique de Moraes Holschuh
Re: Updating x86 microcode in stable
On Tue, 15 May 2018, Ben Hutchings wrote: > I notice that amd64-microcode and intel-microcode haven't been updated > in stable this year. (Indeed, amd64-microcode hasn't been updated at > all this year, but I know AMD has issued an update!) AMD did not issue any public updates AFAIK(!), the one we have [which is not in stable] is only for EPYC processors, and came from SuSE... So far we do not have a *single* report from someone with an EPYC box whether it works or not, as far as I know. I am not confortable with proposing a stable update for this one unless we get such a report, since that microcode update is *still* not available in linux-firmware upstream... If I am wrong about this, please correct me (and point me to the AMD microcode release) and I will fix it ASAP. > You have updated intel-microcode in backports suites instead. What's > the reasoning behind this? I would expect all microcode updates to One of the stable release managers suggested to be more careful with this recent crop of microcode updates... Given the fact that it triggered a number of issues in the kernels of some vendors (kernel bug, not microcode bug), I agree with their reasoning, so I did not send a SPU request after an one-month wait. However, I don't see any reason why we could not start the process for an upload of intel-microcode to stable right now. It has been tested widely enough by Debian users and other distros by now, and the only kernels that regressed were Ubuntu's (related to apparmor and IBPB support, worked around by noibpb), AFAIK. > As you probably know, updated microcode is needed to mitigate against > Spectre v2 when running code that has not been rebuilt with the > "retpoline" mitigation, such as when making BIOS/UEFI calls. I think > it's also needed to support Spectre v2 mitigation in KVM guests running > Windows. Yes, that's correct. > The Linux kernel in stretch has had support for the microcode-based > mitigation since version 4.9.82-1+deb9u1. I'm currently working on > backporting these changes to jessie, so microcode updates would be > useful there too. ACK. I usually send spu and ospu requests at the same time anyway, since the criteria for acceptance is mostly the same. -- Henrique Holschuh
Bug#864716: modules and custom kernels
It is recommended that users building their own kernels never configure as a module any driver that Debian doesn't configure as a module. Anyway, essential modules for system operation should preferably be added to /etc/modules. They will be early-loaded by whatever gets to them first (be it the initramfs, or systemd, or sysvinit). Both initramfs-tools and dracut know to always add modules present in /etc/modules to the initramfs, and attempt to manually load them. Adding essential modules to /etc/initramfs-tools/modules works, but it is specific to initramfs-tools. -- Henrique Holschuh
Bug#815915: lsinitramfs fails to properly skip the padding after each cpio archive
On Sat, 16 Apr 2016, Ben Hutchings wrote: > On Wed, 30 Mar 2016 14:33:52 -0300 Henrique de Moraes Holschuh > wrote: > > (note: I am not subscribed to this bug report. If you want a reply from > > me, please keep me Cc'd). > [...] > > Now, to the root cause of the breakage: > > > > The heuristics initramfs-tools "lsinitramfs" uses (used?) to locate the > > next initramfs are incomplete (it does not skip over the padding at the > > end of each initramfs) > > Nope. > > [...] > > lsinitramfs needs to skip all zero bytes (or dwords) to locate the next > > initramfs segment, instead of assuming a cpio block size of 512 bytes. > [...] > > That is exactly what it does. > > Please don't guess what the 'root cause' is, actually do the research. Eh, unfortunately I actually did it (sometime ago, for the Ubuntu bug report), and evidently got it completely wrong. Then, I copied my (faulty) anaylsis from the Ubuntu bug report to the Debian bug report without attempting to re-verify it. So, it was actually even worse than not doing the research: it was doing it incorrectly in the first place, and not revalidating it sometime later. I apologise for that. Here is a data file that triggers the zcat crash, from one of the Ubuntu bug reports: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1507443/+attachment/4499699/+files/initrd.img-4.2.0-16-generic.bak Instrumenting lsinitramfs, we get the correct offset (0x2c00) for the next segment start offset, and the temporary file (subarchive) is also correct. So, lsinitramfs indeed skips the uncompressed initramfs properly. Changing lsinitramfs to keep the temporary subarchive makes it simple to check it and to test it against zcat. A hexdump of the subarchive looks fine. gzip -d will process it very happily, no errors at all. So will cat (subarchive) | gzip -d | cpio -t. zcat either works or crashes depending on how you call it on the resulting subarchive: zcat -t (subarchive) >/dev/null crashes. zcat (subarchive) | cpio -t, and zcat (subarchive) >/dev/null both work fine. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Bug#815915: lsinitramfs fails to properly skip the padding after each cpio archive
(note: I am not subscribed to this bug report. If you want a reply from me, please keep me Cc'd). The padding between the component initramfs images that make up a "hybrid initramfs" is a sequence of zeros, and it is aligned to the cpio block/record size boundary. There are several valid block sizes for cpio, e.g. 512 (used by iucode v1.0 and earlier, and cpio default) or 1024, which iucode-tool v1.1 and later uses (as a defensive measure). I can revert the 1024-byte block size in iucode-tool to 512 bytes, but that's neither here nor there: it would just work around the bug in lsinitramfs. It would be better to fix lsinitramfs (assuming this isn't fixed already in unstable). Now, to the root cause of the breakage: The heuristics initramfs-tools "lsinitramfs" uses (used?) to locate the next initramfs are incomplete (it does not skip over the padding at the end of each initramfs) and causes zcat to crash (which is likely a bug in zcat itself). It will work fine for 512-byte cpio block size, but not for 1024-byte block size (and also likely not for other block sizes). lsinitramfs needs to skip all zero bytes (or dwords) to locate the next initramfs segment, instead of assuming a cpio block size of 512 bytes. And zcat should not crash if it gets a file that begins with a lot of zeroes before the compressed data... it should either abort with an error (invalid file), or skip the zeroes without crashing. But that's a separate bug. For the record, a full account of how the kernel parses and loads an initramfs (which is how lsinitramfs should behave in an ideal world): EARLY cpio loader (lib/earlycpio.c, loads the microcode data and ACPI table override data): always skips zero DWORDs (4 bytes) before any cpio header, including the first. So, it will just concatenate every non-compressed cpio archive and skip any dword-aligned zero padding before, after, or between cpio archive headers (and, therefore, also between cpio archives). Note: the early cpio loader does not care for subdirectories, it can find data by the whole path, and that's how microcode is loaded. This means the cpio archive with microcode does not need to have any of the subdirectories inside, it doesn't matter to the kernel. I didn't check how the ACPI table override loader behaves. LATE cpio loader (init/initramfs.c, loads the real initramfs): 1. Skips any zero bytes before the compressed or uncompressed data (thus, skips any padding between cpio archives). 2. Unpacks any compressed or uncompressed cpio archive it finds, concatenating the contents (thus, it *will* also unpack the microcode in the first cpio archive, and this file will be available inside the initramfs). 3. It *depends* on subdirectories being created *first* before any files inside them. If this is not done, it will ignore the file (so you could have data in the early initramfs that is "invisible" for the late cpio loader). 4. It does NOT skip inital zero-padding on the *decompressed* data (i.e. if you compress a cpio archive, it must not have any initial zero padding). 5. It skips any zero padding at the end (compressed or not), but the zeros must *end* at a DWORD boundary. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh
Re: Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
reassign 775812 linux retitle 775812 linux-image-3.16.0-4-amd64: HP EliteBook 840 G1 laptop fails to halt/poweroff after 3.16.7-ckt2-1 upgrade thanks For the kernel maintainers: according to the user's report and his aptitude update log: Last known-good version: 3.16.7-2 First known-bad version: 3.16.7-ckt2-1 Synopsis: System will not power down if WoWLAN is enabled in BIOS/UEFI (platform default!). System will properly power down if WoWLAN is disabled in BIOS/UEFI. This is a regression in the CKT stable kernels. On Tue, Mar 31, 2015, at 05:40, Miguel Ortiz Lombardía wrote: > Attached a file listing what was upgraded via apt on December 15, the > day I first noticed the problem. I halt the computer every day, so that > should be in principle the first day it refused to do so properly. Thank you. It was a quite large update run, but you did update the kernel, which is the main suspect for this type of regression, anyway... so that's likely it. Other suspects (but very unlikely ones) from your update log: packagekit and grub2-pc. I will reassign this bug report to the kernel. It is likely caused by some change in either the shutdown path, or the wlan driver or subsystem. If it at all possible, please attach to this bug report the kernel boot logs of 2014-12-14, 15 and 16. They're usually either in /var/log/dmesg* (if they have not been rotated out yet), or you'll need to extract the relevant sections of /var/log/kern.log*. Please also attach the output of "lspci -v -v" (run as root). Let's hope the kernel guys can track down the problem and fix it. I understand it would be easy for you to reproduce the problem if they need more data. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1427800262.539311.247482813.6f68f...@webmail.messagingengine.com
Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
On Sun, 15 Dec 2013, Robert Millan wrote: > > Backporting the fix to these kernels might be a good idea, probably best > > routed through an stable update upload (and not a security upload). > > This might be a bit complicated due to significant changes in internal > APIs. I'm also unsure if the yarrow algorithms used in those versions > are good enough for the task. > > Perhaps we should just disable Via chipset from sys/dev/random/probe.c. > Would this be a terrible loss for a Technology Preview release? I don't think it would be a terrible loss. OTOH, I wouldn't lose any sleep over a VIA PadLock HRNG driving /dev/random in a tech preview release. I am not sure VIA ever updated the design with CPRNGs, but the original one-HRNG and the following two-HRNG designs are very audit-friendly. Just make sure you give xstore (the new instruction used to read the VIA PadLock HRNG) a full cacheline worth of buffer (which must also be cacheline-aligned), due to CPU errata... you'll get memory corruption of nearby data otherwise. You also have to audit (or otherwise lock down) the HRNG configuration, or assume it is operating in its worst mode while post-processing. The VIA PadLock RNG *is* a single MSR-write away from being misconfigured. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131216004912.ga7...@khazad-dum.debian.net
Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
On Sat, 14 Dec 2013, Steven Chamberlain wrote: > On 14/12/13 01:08, Henrique de Moraes Holschuh wrote: > > Yeah, I think Linux went through similar blindness braindamage sometime ago, > > but blind trust on rdrand has been fixed for a long time now, and it never > > trusted any of the other HRNGs (or used them for anything at all without a > > trip through "rng-tools" userspace until v3.12). > > I seem to remember that Ted T'so's committed the fix for this only after > the release of Linux 3.2, so I assuemd wheezy's kernels might be still > affected? I'd need to check it througoutly, but almost all important /dev/random changes in Linux were backported to all stable kernels, and thus eventually migrated into the Debian kernel (which is based on 3.2.y-stable plus lots of other backports). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131214210047.ga29...@khazad-dum.debian.net
Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
On Sat, 14 Dec 2013, Robert Millan wrote: > "we are going to backtrack and remove RDRAND and Padlock backends and feed > them into Yarrow instead of delivering their output directly to /dev/random. Yeah, I think Linux went through similar blindness braindamage sometime ago, but blind trust on rdrand has been fixed for a long time now, and it never trusted any of the other HRNGs (or used them for anything at all without a trip through "rng-tools" userspace until v3.12). > Advice from Security Team would be appreciated in order to determine which > action needs to be taken in Debian. IMO, Debian kernels ought to never blindly trust RDRAND, or any other HRNG, for anything related to /dev/random. Note that the kernel can trust such in-cpu, high-bandwidth/low-latency HRNGs for other uses that are not related to key material (such as to implement ASLR). > kfreebsd 8.3 and 9.0 (wheezy): > Sets Via chipset to serve /dev/random unconditionally whenever detected, > but only on i386 (not amd64). Does not support Intel entropy source. > (see sys/dev/random/probe.c) Backporting the fix to these kernels might be a good idea, probably best routed through an stable update upload (and not a security upload). > kfreebsd 9.2 (jessie / sid): > Sets Via or Intel chipset to serve /dev/random when detected, > unless hw.nehemiah_rng_enable or hw.ivy_rng_enable are set to zero > to disable them. Remove, switch to kfreebsd 10. Either that, or backport the fix from kfreebsd 10. > kfreebsd 10~ (sid): > All versions in Debian already have the fixed code, which replaces > random_adaptor_register() with live_entropy_source_register(), thereby > registering Via and Intel chips as "entropy sources" to be post > processed by Yarrow, rather than directly as "random adaptors". Quite acceptable, as it means we'd have the same policy across Linux and kFreeBSD. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131214010823.gc26...@khazad-dum.debian.net
Bug#728975: linux: [ARM] CONFIG_OABI_COMPAT harmful (slower, unsafe, breaks at least seccomp and audit)
Package: linux Severity: normal Tags: security Please refer to: https://lkml.org/lkml/2013/11/5/448 https://lkml.org/lkml/2013/11/6/633 The issue is not yet closed in LKML, but basically OABI_COMPAT enabled seems to be a danger: at least seccomp and audit should not be used with OABI, and to top it off it is not "free" as far as performance goes, either: a fair amount of added complexity, and an extra D-cache miss on every syscall. -- System Information: Debian Release: 7.2 APT prefers proposed-updates APT policy: (990, 'proposed-updates'), (990, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.4.68+ (SMP w/8 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131107124637.ga4...@khazad-dum.debian.net
Bug#719944: intel-microcode stable backport upload waiting for the initramfs-tools backport upload
Ben, I have the intel-microcode wheezy-backport update tested, and ready for upload. Do you have any timeframe for the initramfs-tools backport upload (of v0.113)? The intel-microcode backport really wants it, so it is best to have initramfs-tools in bpo70 before I upload the intel-microcode backport... Thanks! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1377176476.31560.12854713.02633...@webmail.messagingengine.com
Bug#719944: initramfs-tools: backport of prepend_earlyinitramfs() to Wheezy
On Sat, 17 Aug 2013, Ben Hutchings wrote: > There should be no changes to make in initramfs-tools, other than adding > a changelog entry. Please test > git://git.debian.org/git/kernel/initramfs-tools.git#wheezy-backports > with the backported microcode patches, then I can upload if you confirm > that the combination works. Yes, it works just fine. Thank you! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130818013902.ga21...@khazad-dum.debian.net
Bug#719944: initramfs-tools: backport of prepend_earlyinitramfs() to Wheezy
On Sat, 17 Aug 2013, Ben Hutchings wrote: > You'll need to fix the initramfs-tools version dependency on the > microcode patches (i.e. append a ~ to the minimum version). Please do > that in unstable as well as wheezy-backports. Unstable currently depends on (>= 0.113), is there a pressing need for a new upload to unstable just to change that versioned dependency to (>= 0.113~) ? Otherwise, I will left that change pending for the next upload instead of uploading a new package to unstable immediately. I will make sure the stable-backports packages depend on initramfs-tools (>= 0.113~), of course. > There should be no changes to make in initramfs-tools, other than adding > a changelog entry. Please test > git://git.debian.org/git/kernel/initramfs-tools.git#wheezy-backports > with the backported microcode patches, then I can upload if you confirm > that the combination works. I will test that now. Thanks. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130817192923.ga6...@khazad-dum.debian.net
Bug#719944: initramfs-tools: backport of prepend_earlyinitramfs() to Wheezy
On Sat, 17 Aug 2013, Ben Hutchings wrote: > > I can do it, it will be somewhat annoying due to version numbering dances, > > but it is not difficult at all. However, we could really enhance the > > support of out-of-the-box wheezy for newer kernels with a no-risk stable > > update of initramfs-tools v0.113... > > This is not 'out-of-the-box wheezy' any more then... whichever > administrator is customising with a new kernel package can also add the > new initramfs-tools package. There is no point in adding just one of > them to wheezy. Ok. Could you please backport v0.113 to wheezy-backports, then? I will have to prepare both a stable update (without early fw support) and a wheezy backport (with early fw support) of intel-microcode. I could also upload an initramfs-tools v0.113 backport to wheezy-backports if you're too busy right now, but it is always best when the maintainer does a backport, instead of some other DD... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130817134107.ga18...@khazad-dum.debian.net
Bug#719944: initramfs-tools: backport of prepend_earlyinitramfs() to Wheezy
On Sat, 17 Aug 2013, Ben Hutchings wrote: > On Sat, 2013-08-17 at 00:22 -0300, Henrique de Moraes Holschuh wrote: > [...] > > People do use the LTS 3.10 kernel with Debian wheezy, it would be a very > > good thing to be able to better support this kernel, and support early > > firmware updates for those people out-of-the-box. It will also come on very > > handy for wheezy-and-a-half (updated kernel) if we decide to release it. > [...] > > We have wheezy-backports for this. I don't see any need to change the > wheezy version. So, I should do a stable update for intel-microcode that doesn't support early firmware mode? And anyone trying a 3.10 kernel on wheezy with encrypted root will get stuck without a keyboard and no way to boot because they need initramfs-tools v0.112 or later? I can do it, it will be somewhat annoying due to version numbering dances, but it is not difficult at all. However, we could really enhance the support of out-of-the-box wheezy for newer kernels with a no-risk stable update of initramfs-tools v0.113... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130817124520.gc16...@khazad-dum.debian.net
Bug#719944: initramfs-tools: backport of prepend_earlyinitramfs() to Wheezy
Package: initramfs-tools Version: 0.109.1 Severity: wishlist I'd like to backport the prepend_earlyinitramfs() support to a stable update of initramfs-tools. The two patches in 0.112..0.113 apply directly on top of 0.109.1, and are apropriate to 0.109.1. The feature has been in unstable and testing for some time now, and no bugs were reported. Alternatively, we could backport v0.113 as is to stable, as it fixes some real bugs that can cause trouble for stable users that use new kernels (such as #700572), and doesn't introduce any risky changes. A stable update of initramfs-tools adding prepend_earlyinitramfs() support to wheezy would make it possible to do a stable update of intel-microcode (which will be required anyway due to critical fixes recently issued by Intel for several processors) that can support early firmware updates. People do use the LTS 3.10 kernel with Debian wheezy, it would be a very good thing to be able to better support this kernel, and support early firmware updates for those people out-of-the-box. It will also come on very handy for wheezy-and-a-half (updated kernel) if we decide to release it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130817032205.ga28...@khazad-dum.debian.net
Bug#712521: initramfs-tools: please add early-initramfs support for ucode update
On Mon, 17 Jun 2013, Michael Prokop wrote: > * Henrique de Moraes Holschuh [Sun Jun 16, 2013 at 03:42:45PM -0300]: > > Enclosed you will find two patches to add early-initramfs support to > > initramfs-tools. > > > It adds, and properly documents, a hook function that allows packages > > to _prepend_ data to the main initramfs archive. > [...] > > Please review and comment. If it is OK, please apply. > > git tree for git merge available upon request. > > Thanks! I just applied it after reviewing it together with maks and > pushed it to master. Thank you. I have the intel-microcode side ready and tested, do you have any tentative time-frame for the initramfs-tools upload? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130617211227.ga22...@khazad-dum.debian.net
Bug#712521: initramfs-tools: please add early-initramfs support for ucode update
Package: initramfs-tools
Version: 0.112+nmu1
Severity: wishlist
Tags: patch
Enclosed you will find two patches to add early-initramfs support to
initramfs-tools.
It adds, and properly documents, a hook function that allows packages
to _prepend_ data to the main initramfs archive.
It will be used by intel-microcode and amd64-microcode to supply an early
initramfs with microcode data for the kernel. This is extremely important
to properly work around bugs that would otherwise force the kernel to
disable important functionality (such as the ones in the Atom that requires
disabling PME, which previously required a bios update or the use of Intel
BITS to work around. We have several documented cases of Debian users that
cannot use either method).
Please review and comment. If it is OK, please apply.
git tree for git merge available upon request.
-- no debconf information
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
>From 53852844059e8dac529618acfeffc285b32a3ee5 Mon Sep 17 00:00:00 2001
From: Henrique de Moraes Holschuh
Date: Fri, 31 May 2013 22:16:44 -0300
Subject: [PATCH 1/2] implement early initramfs support
Add a new hook function, prepend_earlyinitramfs(), which prepends
the content of the file passed as a parameter to the initramfs
that will be generated.
This will be used to pass system processor microcode and ACPI table
overrides to the kernel (requires Linux kernel v3.9 or later).
Signed-off-by: Henrique de Moraes Holschuh
---
hook-functions| 10 ++
initramfs-tools.8 | 14 ++
mkinitramfs | 19 ---
3 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/hook-functions b/hook-functions
index 817d06c..e751021 100644
--- a/hook-functions
+++ b/hook-functions
@@ -10,6 +10,16 @@ catenate_cpiogz() {
cat "${1}" >>"${__TMPCPIOGZ}"
}
+prepend_earlyinitramfs() {
+ # Sanity check
+ if [ ! -e "${1}" ]; then
+ echo "W: prepend_earlyinitramfs: arg1='${1}' does not exist." >&2
+ return
+ fi
+
+ cat "${1}" >>"${__TMPEARLYCPIO}"
+}
+
# force_load module [args...]
force_load()
{
diff --git a/initramfs-tools.8 b/initramfs-tools.8
index 375e5c1..546bb01 100644
--- a/initramfs-tools.8
+++ b/initramfs-tools.8
@@ -240,6 +240,20 @@ and copy them to the initramfs. This means that most executables, unless
compiled with klibc, will automatically include glibc in the image which will
increase its size by several hundred kilobytes.
+.SS Including a system firmware preimage (early initramfs)
+If you need to prepend data to the initramfs image, you need to prepare it
+in a file, and call the \fB\fIprepend_earlyinitramfs\fR function. The file
+can be disposed of as soon as the function returns.
+
+.B Example:
+.nf
+TEMP_FILE=$(mktemp ...)
+ ...
+prepend_earlyinitramfs ${TEMP_FILE}
+rm -f ${TEMP_FILE}
+
+.RE
+
.SS Exported variables
mkinitramfs sets several variables for the hook scripts environment.
diff --git a/mkinitramfs b/mkinitramfs
index d9a54e2..cdec420 100755
--- a/mkinitramfs
+++ b/mkinitramfs
@@ -175,6 +175,7 @@ if [ -n "$fs" ] && mount | grep -q "on $fs .*noexec" ; then
fi
__TMPCPIOGZ="$(mktemp ${TMPDIR:-/var/tmp}/mkinitramfs-OL_XX)" || exit 1
+__TMPEARLYCPIO="$(mktemp ${TMPDIR:-/var/tmp}/mkinitramfs-FW_XX)" || exit 1
DPKG_ARCH=`dpkg --print-architecture`
@@ -193,6 +194,9 @@ export BUSYBOX
# Private, used by 'catenate_cpiogz'.
export __TMPCPIOGZ
+# Private, used by 'prepend_earlyinitramfs'.
+export __TMPEARLYCPIO
+
for d in bin conf/conf.d etc lib/modules run sbin scripts ${MODULESDIR}; do
mkdir -p "${DESTDIR}/${d}"
done
@@ -331,9 +335,17 @@ if [ "$DPKG_ARCH" = armhf ]; then
fi
[ "${verbose}" = y ] && echo "Building cpio ${outfile} initramfs"
+
+if [ -s "${__TMPEARLYCPIO}" ]; then
+ cat "${__TMPEARLYCPIO}" >"${outfile}" || exit 1
+else
+ # truncate
+ > "${outfile}"
+fi
+
(
# work around lack of "set -o pipefail" for the following pipe:
-# cd "${DESTDIR}" && find . | cpio --quiet -R 0:0 -o -H newc | gzip >"${outfile}" || exit 1
+# cd "${DESTDIR}" && find . | cpio --quiet -R 0:0 -o -H newc | gzip >>"${outfile}" || exit 1
exec 3>&1
eval `
# http://cfaj.freeshell.org/shell/cus-faq-2.html
@@ -343,7 +355,7 @@ eval `
find . 4>&-; echo "ec1=$?;" >&4
} | {
cpio --quiet -R 0:0 -o -H newc 4>&-; echo "ec2=$?;" >&4
- } | ${compress} >"${outfile}"
+ } | ${compress} >>"${outfile}"
echo
Updating processor microcode in stable (squeeze)
Please refer to the relevant history at the bottom of this email. Summary for debian-release: 1. We have AMD and Intel microcode update packages in Wheezy and also in stable-backports. These packages have been available for a reasonable amount of time (~two months for AMD, ~three months for Intel), without any relevant issues (i.e. they're field-tested). 2. Uptake of these packages was low, and only picked up a bit after an announcement to some Debian MLs. However, once they started being recommended by the linux-firmware-nonfree packages in Wheeze, there was an extreme increase of uptake, as far as popcon data can tell us[1][2][3]. 3. These packages fix very relevant, system-crash-class issues as well as feature issues (such as perf support, power management) for both Intel and AMD processors. The less tech-savy the user is, the higher the probability of these packages being useful to the user (due to lack of BIOS/EFI updates being applied). 4. The microcode packages in stable (squeeze) only cover Intel processors, and it is also very outdated. Just updating the intel-microcode package in squeeze would not address the issues of AMD users at all. 5. AMD microcode updates are not easily available in any other way than distro packages right now. AMD upstream said in LKML that they will sort it out by the time the next update needs to be published, and likely do it through the linux-firware.git tree now that amd64.org is no more. Therefore, I'd like to propose that the packages in debian-backports (iucode-tool, amd64-microcode, intel-microcode) be uploaded to stable-proposed-updates. This would add one package to contrib stable (iucode-tool), add one package to non-free stable (amd64-microcode), and update one package in non-free stable (intel-microcode). I'd also propose that the firmware-linux-nonfree package in stable be updated to "recommends: intel-microcode | amd64-microcode". If this request is approved by the stable release manager, I'll rebuild the backport packages with a stable-compatible version before the upload. They will superseed the backported packages, but still sort before the wheezy packages to not cause issues with the upgrade path. Thank you! [1] http://packages.qa.debian.org/i/intel-microcode.html, http://qa.debian.org/popcon.php?package=intel-microcode [2] http://packages.qa.debian.org/a/amd64-microcode.html, http://qa.debian.org/popcon.php?package=amd64-microcode [3] http://packages.qa.debian.org/i/iucode-tool.html, http://qa.debian.org/popcon.php?package=iucode-tool On Thu, 24 Jan 2013, Ben Hutchings wrote: > On Thu, 2013-01-24 at 01:00 -0200, Henrique de Moraes Holschuh wrote: > > On Wed, 23 Jan 2013, Ben Hutchings wrote: > > > On Wed, Jan 23, 2013 at 11:15:37PM +0200, Touko Korpela wrote: > > > > When using squeeze system, with wheezy (backports) of kernel and > > > > firmware, > > > > recently firmware-linux started to recommend intel-microcode and > > > > amd64-microcode packages. > > > > I think that intel-microcode recommends can be versioned, so that it > > > > prefers > > > > reworked versions (1.20120606.1 or newer) instead of old squeeze > > > > version. > > > > > > I don't think a versioned Recommends will have the effect you're > > > hoping for. > > > > > > Also if there have been important bug fixes to the microcode then they > > > should be included in stable-updates, not just squeeze-backports. > > > > Ideally, we should get iucode-tool (which would be adding *new* package to > > stable, something that is extremely rarely done) and the new versions of > > amd64-microcode (also a new package for stable) and intel-microcode to > > stable-updates. > > > > I can certainly create an old-style intel-microcode package for > > stable-updates, and that will give non-broken hardware counters for stable > > Intel users [that run with a custom kernel, stable's doesn't support perf > > AFAIK] > > It does. > > > and some nasty bugs removed. But AMD users would still run with > > microcode that screws up power management, has none/broken hardware counter > > support, and some nasty bugs that hit rarely. > > > > BTW, currently you cannot get AMD microcode updates from anywhere else other > > than the distros and the internet archive. Makes it somewhat more important > > to add the package to stable proper, IMHO. > > > > Should we take this to the stable release manager? > > Please do. > > > Good, up-to-date packages *are* available in stable-backports, though. > > Sending word to the users to install those might make more sense and gi
Re: Should intel-microcode recommends be versioned (firmware-linux)?
On Wed, 23 Jan 2013, Ben Hutchings wrote: > On Wed, Jan 23, 2013 at 11:15:37PM +0200, Touko Korpela wrote: > > When using squeeze system, with wheezy (backports) of kernel and firmware, > > recently firmware-linux started to recommend intel-microcode and > > amd64-microcode packages. > > I think that intel-microcode recommends can be versioned, so that it prefers > > reworked versions (1.20120606.1 or newer) instead of old squeeze version. > > I don't think a versioned Recommends will have the effect you're > hoping for. > > Also if there have been important bug fixes to the microcode then they > should be included in stable-updates, not just squeeze-backports. Ideally, we should get iucode-tool (which would be adding *new* package to stable, something that is extremely rarely done) and the new versions of amd64-microcode (also a new package for stable) and intel-microcode to stable-updates. I can certainly create an old-style intel-microcode package for stable-updates, and that will give non-broken hardware counters for stable Intel users [that run with a custom kernel, stable's doesn't support perf AFAIK] and some nasty bugs removed. But AMD users would still run with microcode that screws up power management, has none/broken hardware counter support, and some nasty bugs that hit rarely. BTW, currently you cannot get AMD microcode updates from anywhere else other than the distros and the internet archive. Makes it somewhat more important to add the package to stable proper, IMHO. Should we take this to the stable release manager? Good, up-to-date packages *are* available in stable-backports, though. Sending word to the users to install those might make more sense and give better results, as people don't install these microcode packages by themselves. I've seen an absurd increase of popcon results for the two microcode packages since the Recommends was added to firmware-linux. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130124030051.ga18...@khazad-dum.debian.net
Bug#696059: linux: PATCH required for server interrupt load balancing/irqbalance (tested)
On Sun, 16 Dec 2012, Ben Hutchings wrote: > On Sun, 2012-12-16 at 11:24 -0200, Henrique de Moraes Holschuh wrote: > > Package: linux > > Version: 3.2.35-1 > > Severity: important > > Tags: patch > > > > Please include the attached patch in Wheezy, without it, irqbalance fails to > > do its job properly on any server (actually any multi-core system with > > MSI/MSI-X irqs). > > > > It is important to have irqbalance work properly out-of-the-box, since it is > > the only trivial way to get better network/storage behaviour out of the > > MSI-X capable NUMA systems that are >95% of the post-2010 server market. > > Would be nice, but it has been broken for so long that 'everyone knows' > to disable irqbalance. Yeah, and nobody knows how to use hwloc either, so they probably leave it at whatever the kernel/BIOS/EFI default mapping is. And since the kernel doesn't irqbalance by itself anymore, it will either be round-robin if you're lucky, or all-in-the-first-core if you're unlucky... > > I've tested the attached patch on stock (kernel.org) 3.2.34 on production, > > and it works fine. The patch is very simple, it just publishes the MSI > > IRQ vector information to sysfs, which irqbalance uses. > > Changes ABI, so will have to wait if we apply it at all. It is a new ABI, actually, so it has no ill effects on existing applications. And this new ABI is already stable, too. > > git commit upstream: b50cac55bf859d5b2fdcc1803a553a251b703456 > > > > Alternatively, we might want to add it to -stable series upstream, on the > > grounds that it is widely desired functionality (i.e. useful for all > > distros). > > This doesn't suddenly become urgent because you just noticed it. I don't recall claiming for urgency anywhere, unless you mean the request that it should be added to the Wheezy kernel. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121217183738.gb32...@khazad-dum.debian.net
Bug#696059: linux: PATCH required for server interrupt load balancing/irqbalance (tested)
Package: linux
Version: 3.2.35-1
Severity: important
Tags: patch
Please include the attached patch in Wheezy, without it, irqbalance fails to
do its job properly on any server (actually any multi-core system with
MSI/MSI-X irqs).
It is important to have irqbalance work properly out-of-the-box, since it is
the only trivial way to get better network/storage behaviour out of the
MSI-X capable NUMA systems that are >95% of the post-2010 server market.
I've tested the attached patch on stock (kernel.org) 3.2.34 on production,
and it works fine. The patch is very simple, it just publishes the MSI
IRQ vector information to sysfs, which irqbalance uses.
git commit upstream: b50cac55bf859d5b2fdcc1803a553a251b703456
Alternatively, we might want to add it to -stable series upstream, on the
grounds that it is widely desired functionality (i.e. useful for all
distros).
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.35+ (SMP w/8 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
>From b50cac55bf859d5b2fdcc1803a553a251b703456 Mon Sep 17 00:00:00 2001
From: Neil Horman
Date: Thu, 6 Oct 2011 14:08:18 -0400
Subject: [PATCH] PCI/sysfs: add per pci device msi[x] irq listing (v5)
This patch adds a per-pci-device subdirectory in sysfs called:
/sys/bus/pci/devices//msi_irqs
This sub-directory exports the set of msi vectors allocated by a given
pci device, by creating a numbered sub-directory for each vector beneath
msi_irqs. For each vector various attributes can be exported.
Currently the only attribute is called mode, which tracks the
operational mode of that vector (msi vs. msix)
Acked-by: Greg Kroah-Hartman
Signed-off-by: Jesse Barnes
---
Documentation/ABI/testing/sysfs-bus-pci | 18 +
drivers/pci/msi.c | 111 +++
include/linux/msi.h |3 +
include/linux/pci.h |1 +
4 files changed, 133 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index 349ecf2..34f5110 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -66,6 +66,24 @@ Description:
re-discover previously removed devices.
Depends on CONFIG_HOTPLUG.
+What: /sys/bus/pci/devices/.../msi_irqs/
+Date: September, 2011
+Contact: Neil Horman
+Description:
+ The /sys/devices/.../msi_irqs directory contains a variable set
+ of sub-directories, with each sub-directory being named after a
+ corresponding msi irq vector allocated to that device. Each
+ numbered sub-directory N contains attributes of that irq.
+ Note that this directory is not created for device drivers which
+ do not support msi irqs
+
+What: /sys/bus/pci/devices/.../msi_irqs//mode
+Date: September 2011
+Contact: Neil Horman
+Description:
+ This attribute indicates the mode that the irq vector named by
+ the parent directory is in (msi vs. msix)
+
What: /sys/bus/pci/devices/.../remove
Date: January 2009
Contact: Linux PCI developers
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 0e6d04d..e6b6b9c 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -323,6 +323,8 @@ static void free_msi_irqs(struct pci_dev *dev)
if (list_is_last(&entry->list, &dev->msi_list))
iounmap(entry->mask_base);
}
+ kobject_del(&entry->kobj);
+ kobject_put(&entry->kobj);
list_del(&entry->list);
kfree(entry);
}
@@ -403,6 +405,98 @@ void pci_restore_msi_state(struct pci_dev *dev)
}
EXPORT_SYMBOL_GPL(pci_restore_msi_state);
+
+#define to_msi_attr(obj) container_of(obj, struct msi_attribute, attr)
+#define to_msi_desc(obj) container_of(obj, struct msi_desc, kobj)
+
+struct msi_attribute {
+ struct attributeattr;
+ ssize_t (*show)(struct msi_desc *entry, struct msi_attribute *attr,
+ char *buf);
+ ssize_t (*store)(struct msi_desc *entry, struct msi_attribute *attr,
+ const char *buf, size_t count);
+};
+
+static ssize_t show_msi_mode(struct msi_desc *entry, struct msi_attribute *atr,
+ char *buf)
+{
+ return sprintf(buf, "%s\n", entry->msi_attrib.is_msix ? "msix" : "msi");
+}
+
+static ssize_t msi_irq_attr_show(struct kobject *kobj,
+ struct attribute *attr, char *buf)
+{
+ struct msi_attribute *attribute = to_msi_attr(attr);
+ struct msi_desc *entry = to_msi_desc(kobj);
+
+ if (!attribute->show)
+ return -EIO;
+
+ return attribute->show(entry, attribute, buf);
+}
+
+static const struct sysfs_ops msi_irq_sysfs_ops = {
+ .show = msi_irq_attr_show,
+};
+
+stati
Bug#692604: firmware-linux-nonfree: please recommend amd64-microcode, intel-microcode
On Wed, 07 Nov 2012, Ben Hutchings wrote: > On Wed, Nov 07, 2012 at 05:55:48PM -0200, Henrique de Moraes Holschuh wrote: > > Package: firmware-linux-nonfree > > I think the firmware-linux metapackage would be more appropriate. Sure, that would work as well. > > Please recommend amd64-microcode | intel-microcode for Wheezy. It would be > > best if the majority of our users run with up-to-date microcode... > > And you think that the package manager will somehow pick the right > one just by luck? ;-) Heh, you're right. We can recommend both packages at the same time, then. They can be co-installed, and will do the right thing. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121108004025.ga18...@khazad-dum.debian.net
Bug#692604: firmware-linux-nonfree: please recommend amd64-microcode, intel-microcode
Package: firmware-linux-nonfree Version: 0.36 Severity: wishlist Please recommend amd64-microcode | intel-microcode for Wheezy. It would be best if the majority of our users run with up-to-date microcode... Unfortunately, since these packages are arch-specific, this recommendation cannot be met on arches other than i386 and amd64. AFAIK, this shouldn't cause any operational problems, though. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.33+ (SMP w/8 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash firmware-linux-nonfree depends on no packages. firmware-linux-nonfree recommends no packages. Versions of packages firmware-linux-nonfree suggests: ii initramfs-tools 0.109 ii linux-image-3.2.0-3-amd64 [linux-image] 3.2.23-1 -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121107195548.ga7...@khazad-dum.debian.net
Bug#688794: Circular dependancy after reboot when..
On Tue, 09 Oct 2012, maximilian attems wrote: > > On Tue, 09 Oct 2012, maximilian attems wrote: > > > On Mon, Oct 08, 2012 at 06:03:20PM -0300, Henrique de Moraes Holschuh > > > wrote: > > > > Well, I don't mind changing the name of the initramfs-tools helper > > > > scripts > > > > in the *-microcode packages, > > > > > > please do so. > > > > As long as the release managers agree. I will try. > > Of course they will as it only your package that triggers this bug. For now. "-" is common in package names, much more than "_". It *will* happen again if left as-is. If anything at all (update-initramfs, documentation or even lintian) either mentioned or warned about this pitfall, it wouldn't have happened to intel-microcode and amd64-microcode. FWIW, I have already uploaded intel-microcode and amd64-microcode packages that work around the bug, and I will bug the Wheezy release-managers about it 10 days from now. I definately own them a beer or two already. And I have to bug the Ubuntu release-managers for a freeze exception there too :-( -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121009141912.ga15...@khazad-dum.debian.net
Bug#688794: Circular dependancy after reboot when..
On Tue, 09 Oct 2012, maximilian attems wrote: > On Mon, Oct 08, 2012 at 06:03:20PM -0300, Henrique de Moraes Holschuh wrote: > > Well, I don't mind changing the name of the initramfs-tools helper scripts > > in the *-microcode packages, > > please do so. As long as the release managers agree. I will try. > > but this _really_ needs to be documented in the > > initramfs-tools manpages, AND it needs to generate an warning on > > update-initramfs time. It is really non-obvious. > > The corner case infact involves a noexec /var/tmp, which is why allmost > no one sees it. This makes it worse. Please document this now, an upload that only changes manpages and static docs in /usr/share/doc is not going to endanger the freeze. > > However, I do propose that instead of changing intel-microcode, > > amd64-microcode, and any other packages present and future that might run > > afoul of this restriction, the initramfs scripts should suitably transform > > all valid script names so that they can be valid variable names. > > well oh well progress, we did issue a warning, but it went away, > because in the common cases it does work. ?!! > > Also, I suggest that initramfs-tools should either provide tsort inside the > > initramfs, or drop the code that conditionally uses it. That codepath could > > be hiding landmines as well. > > The landmines are that this codepath is real crap, still dating jbailey. > No way we going to touch that at this point of the release. You're aware that post-freeze or not, the fix for this kind of crap needs to go to stable, I hope. So it is either fix it during the freeze, or fix it through stable-proposed-updates. >From what I can see, the only fix that is not going to over-complicate things is to make sure update-initramfs will ALWAYS create the ORDER file, and remove the other two codepaths from scripts/functions. If the ORDER file is missing, the initramfs code should try to run things in C collation order, as that has at least a non-zero chance of working, and therefore it is MUCH better than dying with an error message *during boot*. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121009102647.ga28...@khazad-dum.debian.net
Bug#688794: Circular dependancy after reboot when..
On Mon, 08 Oct 2012, maximilian attems wrote: > "Variables set by the user must have a name consisting solely of alphabet‐ > ics, numerics, and underscores - the first of which must not be numeric." > - dash.1 > > it seems the initramfs-tools manpage added the "dash" along > the lines, which is wrong for this cornercase of /tmp noexec and > no busybox. > Then scripts are unfortunately variable names and thus should not > have dash in their names. Well, I don't mind changing the name of the initramfs-tools helper scripts in the *-microcode packages, but this _really_ needs to be documented in the initramfs-tools manpages, AND it needs to generate an warning on update-initramfs time. It is really non-obvious. However, I do propose that instead of changing intel-microcode, amd64-microcode, and any other packages present and future that might run afoul of this restriction, the initramfs scripts should suitably transform all valid script names so that they can be valid variable names. Maybe it could internally replace all characters that are valid for package names but not for variables with "_", or just skip any characters outside of [a-zA-Z0-9_]. This has the advantage of being a central fix, and also avoiding a very nasty breakage on a fallback mode of the initramfs that is rarely exercised. Also, I suggest that initramfs-tools should either provide tsort inside the initramfs, or drop the code that conditionally uses it. That codepath could be hiding landmines as well. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121008210320.ga25...@khazad-dum.debian.net
Bug#684569: microcode module loaded on Celeron CPU
On Mon, 13 Aug 2012, Jonathan Nieder wrote: > You can see why an OS distributor would be stuck in this situation, > though. If the microcode updates are installed by default, Debian is > taking responsibility for their effect (in the sense of receiving bug > reports and providing updates when appropriate to address them). And > that is very hard to do without the corresponding source code. It is not the lack of "source code"[1] that is the problem. It is the absolute lack of any sort of release guidance whatsoever from Intel when a new microcode update is made available. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120813183119.gc3...@khazad-dum.debian.net
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
On Mon, 13 Aug 2012, Paul Menzel wrote: > Looking into this some more, this seems unlikely in Debian because the > microcode packages are in non-free [1] and therefore not available for > Debian users not having enabled non-free repositories. > > Because of that the microcode packages are also non-essential, that > means not installed by default even when non-free packages are allowed. > And normal users will never install them by themselves. > > So currently I am pretty sure 99, % of Debian users do not have it > installed. That is correct, yes. We may change the Debian installer to offer to install the microcode packages for AMD and/or Intel to users that enable non-free. We could also document the availability of the microcode packages in the release documentation, I suppose. But Debian really isn't big on the non-free stuff. > > With the latest mainline kernel the microcode driver should be automatically > > loaded by CPUID probing through udev. > > How can I find out, if the microcode provided by my BIOS is older than > the one provided by the processor vendor? I am pretty sure, that for > example Intel does not release any updates for the Celeron CPU in my > ASUS Eee PC 701 4G. The easiest way, by far, is to attempt to update to the latest microcode in the microcode distribution. Assuming you're using Debian testing/unstable, install the intel-microcode package (in unstable, install also package iucode-tool to avoid bloating the initramfs). Then grep for "microcode" in the kernel logs. The 3.2 kernel will log the fact that it had to update the processor microcode. If it doesn't log anything, either no microcode for that processor model is available, or you're already running newer microcode. In Debian stable, it works the same way but I am not sure the kernel will log anything of value. If you want to do it the hard way: "iucode-tool --scan-system" will tell you your processor's signature (requires the cpuid module to be loaded first). If you're running Debian stable, wait a few days for the Squeeze backport to hit the mirrors. You can get the pf_mask and current version of microcode on each core from /sys/devices/system/cpu/cpu*/microcode/, and you can check the intel-microcode package changelog for your processor's signature to see if a higher revision is available. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120813163215.ga3...@khazad-dum.debian.net
Bug#678519: after about a month, routing gets wedged
On Sat, 28 Jul 2012, Rudy Zijlstra wrote: > stopping aiccu, rmmod sit and tunnel4 and then reloading and > restarting aiccu did solve it > > Next time i will start with restarting aiccu, and not rmmoding the > related modules Hmm, okay. That should help narrow it down a lot. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120729023827.gb3...@khazad-dum.debian.net
Bug#681418: debugfs is a big security hole
On Fri, 13 Jul 2012, Ben Hutchings wrote: > I certainly consider mounting of debugfs to be significant security > liability. I'm not at all happy that people use it as the basis for Seconded. I know of at least three ways to hardcrash boxes through debugfs (system specific, not a kernel bug), and the unfortunate naming DOES help kernel maintainers take an even more irresponsible instance regarding security than what is already [unfortunately] normal. e.g. missing calls to capable() in debugfs handlers. It really should be called "advcfgfs". Either that, or it should taint the kernel when mounted, and any production stuff would be forced to "graduate" to a proper peer-reviewed interface. > I would like to address this by backporting this feature: > > commit d6e486868cde585842d55ba3b6ec57af090fc343 > Author: Ludwig Nussel > Date: Wed Jan 25 11:52:28 2012 +0100 > > debugfs: add mode, uid and gid options > > and then changing the default mode (mask) to be 0700. This should > leave debugfs functional (most such applications will require root > anyway) and allow users to relax permissions if they really don't > care about the security problems. Actually, it would be best if we could set mode, uid and gid per inode/dentry, with defaults to the ones in the mount command (or root:root 700). Just like tmpfs does. > However, currently there is not a single place for the user options. > I think that either (1) debugfs should be mounted by default in a > similar way to other pseudo-filesystems, or (2) debugfs should have a > noauto entry in /etc/fstab where users can set options, and packages > may use 'mount /sys/kernel/debug' to mount debugfs with those options > (not 'mount -t debugfs debugfs /sys/kernel/debug', as now). Both ideas would work. Can you provide a patch for the relevant initscripts? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120713134317.gb7...@khazad-dum.debian.net
Re: Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Sun, 24 Jun 2012, Ben Hutchings wrote: > On Sun, 2012-06-24 at 12:21 -0300, Henrique de Moraes Holschuh wrote: > > On Sat, 23 Jun 2012, Ben Hutchings wrote: > > > > > The package template system currently only supports one optional > > > > > postinst action, but it wouldn't be hard to extend to add others. > > > > Ok, I tried to ship the microcode for amd processors using firmware-nonfree. > > There are a few problems: > > > > 1. firmware-nonfree seems to be very tightly tied to module names. We'd > > need to join all microcode upstream packages under "microcode" which is the > > module name. This is not a good thing IMO. > > No such tying is required. Uh? I failed at attempting it, it aborts complaining that it cannot find something in (base, microcode), (base, cpu-x86-amd), etc. And it only runs after I install the -support package, as it wants python modules that are in there. > > 2. firmware-nonfree simply doesn't want to work without MODULE_FIRMWARE > > support in the official kernel-image, that somehow migrates to magic binary > > dumps in the -support package for that image, that gets used by > > firmware-nonfree to generate its own metadata. Yikes! > > I don't know where you get this idea, as there is no such information in > linux-support-. The set of files to be included in > firmware-foo is specified by foo/defines. It was not enough to get it to run, but maybe I did something wrong. Help is appreciated (or a pointer to the documentation for how to work with firmware-nonfree). > > 3. firmware-nonfree _really_ needs a README.source :-) > > Yeah. > > > So, I am stumped. Assuming it is simply not a matter of me not groking how > > to shoehorn firmware-nonfree to do what I need, at this point, it either > > means we need some changes to firmware-nonfree so that it can ALSO work as a > > generic multi-upstream dumping ground for stuff that does not benefit from > > (or actively gets harmed by) the automation it currently does, or that we > > should have separate source packages for such stuff, and leave > > firmware-nonfree for regular firmware that fits well with the automation it > > currently implements. > > > > Any ideas? > > I think it might be better in the long term to split up firmware-nonfree > and provide a dh_firmware used by multiple source packages. > > But I think you are seeing obstacles that don't exist. Other than the lack of a README.source to avoid it? Maybe. But at the end of the day, the fact is that I still don't know how to get firmware-nonfree to do what I need it to :-( -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624160531.ga3...@khazad-dum.debian.net
Re: Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Sat, 23 Jun 2012, Ben Hutchings wrote: > > > The package template system currently only supports one optional > > > postinst action, but it wouldn't be hard to extend to add others. Ok, I tried to ship the microcode for amd processors using firmware-nonfree. There are a few problems: 1. firmware-nonfree seems to be very tightly tied to module names. We'd need to join all microcode upstream packages under "microcode" which is the module name. This is not a good thing IMO. 2. firmware-nonfree simply doesn't want to work without MODULE_FIRMWARE support in the official kernel-image, that somehow migrates to magic binary dumps in the -support package for that image, that gets used by firmware-nonfree to generate its own metadata. Yikes! 3. firmware-nonfree _really_ needs a README.source :-) So, I am stumped. Assuming it is simply not a matter of me not groking how to shoehorn firmware-nonfree to do what I need, at this point, it either means we need some changes to firmware-nonfree so that it can ALSO work as a generic multi-upstream dumping ground for stuff that does not benefit from (or actively gets harmed by) the automation it currently does, or that we should have separate source packages for such stuff, and leave firmware-nonfree for regular firmware that fits well with the automation it currently implements. Any ideas? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624152154.ge24...@khazad-dum.debian.net
Re: Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Sat, 23 Jun 2012, Ben Hutchings wrote: > On Fri, 2012-06-22 at 23:49 -0300, Henrique de Moraes Holschuh wrote: > > On Sat, 23 Jun 2012, Ben Hutchings wrote: > > > On Fri, 2012-06-22 at 16:03 -0300, Henrique de Moraes Holschuh wrote: > > > > On Fri, 22 Jun 2012, Ben Hutchings wrote: > > > > > On Sat, 2012-06-16 at 15:08 -0300, Henrique de Moraes Holschuh wrote: > > > > > > They have to: > > > > > > > > > > > > 1. Issue sysfs commands to refresh running microcode > > > > > > > > > > With a current kernel, udev will load the firmware just as for any > > > > > other > > > > > device. > > > > > > > > Yes, it will. At boot. And only if the driver is modular. And only if > > > > something specifically modprobes microcode, because it has no > > > > autoloading > > > > support in kernel 3.2 and earlier (I think that support was to land in > > > > 3.5, > > > > but it might already have landed in 3.4). > > > > > > > > So, Microcode needs to be refreshed when you upgrade the data files, and > > > > also when the driver is not modular (at least last time I tested it in > > > > a 3.0 > > > > kernel for Intel), and that requires postinst and initramfs specific > > > > magic > > > > (quite a lot for Intel, nearly none for AMD). > > > > > > > Backporting the autoload code is not straigthforward. > > > > > > I backported the general support for x86 CPU module autoloading in > > > 3.2.21-1. The rest should be easy, shouldn't it? > > > > Probably yes. > > > > However, the microcode core also went through a large code change > > because it was ported from half-braindead sysdev to a full blown device. > > I am not sure if you can do the autoloading properly without that > > conversion, it depends on whether the code in 3.2 generates the required > > uevents and sysfs attributes, or not. > > > > Do we have a git tree with the Debian kernel somewhere? > > The source package is currently still in svn, but there is a git mirror > of the patched source at > <http://anonscm.debian.org/gitweb/?p=kernel/linux.git>. > > > > > > > and update the initramfs when updated/installed. > > > > > > > > > > firmware-nonfree can do that (some network drivers need firmware). > > > > > > > > Is it amicable to special postinst code? If it is, it can take care of > > > > amd64-microcode. > > > > > > The package template system currently only supports one optional > > > postinst action, but it wouldn't be hard to extend to add others. > > > > Let's see if I can get that to work over the weekend. I will be unable to > > do any Debian work next week, which is rather unfortunate given the freeze > > deadline. > > It's not a hard deadline for package updates. > > [...] > > > Why is this 'needed'; are future processors expected to be particularly > > > buggy? > > > > A few current ones already are, and there is no reason to believe it > > won't happen again in the future. "buggy" here means something the > > kernel wants (or cannot afford not to) to test for only once, and > > disable functionality if the relevant microcode update is not already > > installed in the processor. > > Right, good point. > > > Anyway, we will need to update the userspace microcode facilities for > > new kernels, as early-init microcode update support should land in 3.6 > > or 3.7 and will require changes on how it interacts with the initramfs. > > I'd rather this was something simple to do for wheezy-stable through > > either a stable update, or a backport or a single simple package. > [...] > > I don't see why that should be included in wheezy. Maybe as a backport at first. People do like to use more recent kernels than the stable one with stable userspace... and it would be useful for wheezy-and-a-half if it comes to happen. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120623160840.gb9...@khazad-dum.debian.net
Re: Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Sat, 23 Jun 2012, Ben Hutchings wrote: > On Fri, 2012-06-22 at 16:03 -0300, Henrique de Moraes Holschuh wrote: > > On Fri, 22 Jun 2012, Ben Hutchings wrote: > > > On Sat, 2012-06-16 at 15:08 -0300, Henrique de Moraes Holschuh wrote: > > > > They have to: > > > > > > > > 1. Issue sysfs commands to refresh running microcode > > > > > > With a current kernel, udev will load the firmware just as for any other > > > device. > > > > Yes, it will. At boot. And only if the driver is modular. And only if > > something specifically modprobes microcode, because it has no autoloading > > support in kernel 3.2 and earlier (I think that support was to land in 3.5, > > but it might already have landed in 3.4). > > > > So, Microcode needs to be refreshed when you upgrade the data files, and > > also when the driver is not modular (at least last time I tested it in a 3.0 > > kernel for Intel), and that requires postinst and initramfs specific magic > > (quite a lot for Intel, nearly none for AMD). > > > Backporting the autoload code is not straigthforward. > > I backported the general support for x86 CPU module autoloading in > 3.2.21-1. The rest should be easy, shouldn't it? Probably yes. However, the microcode core also went through a large code change because it was ported from half-braindead sysdev to a full blown device. I am not sure if you can do the autoloading properly without that conversion, it depends on whether the code in 3.2 generates the required uevents and sysfs attributes, or not. Do we have a git tree with the Debian kernel somewhere? > > > > and update the initramfs when updated/installed. > > > > > > firmware-nonfree can do that (some network drivers need firmware). > > > > Is it amicable to special postinst code? If it is, it can take care of > > amd64-microcode. > > The package template system currently only supports one optional > postinst action, but it wouldn't be hard to extend to add others. Let's see if I can get that to work over the weekend. I will be unable to do any Debian work next week, which is rather unfortunate given the freeze deadline. > > > > 2. Ensure that the microcode module and processor microcode will be > > > > added > > > > to the initramfs. > > > > > > Can be done by initramfs-tools. > > > > Yes, it can. But initramfs-tools has no specific code other than some NFS > > stuff, so we would probably benefit from a firmware-cpu-tools or whatever, > > which could drop the initramfs helper, dpkg triggers and helper scripts to > > get things done for both amd and intel microcode. > > > > I'd rather not duplicate this code for Intel and AMD, so it would need to > > end up in a -common/-util package of some sort (or in intramfs-tools > > directly, but I don't think that's a good idea): soon we will also need a > > new type of hook to piggyback the microcode using a initramfs-like > > container, either to the initramfs itself, or to the kernel image (I am not > > clear on that detail yet), and the microcode will be loaded on the BSP very > > very early, and on other cores BEFORE they're activated. > > Why is this 'needed'; are future processors expected to be particularly > buggy? A few current ones already are, and there is no reason to believe it won't happen again in the future. "buggy" here means something the kernel wants (or cannot afford not to) to test for only once, and disable functionality if the relevant microcode update is not already installed in the processor. Anyway, we will need to update the userspace microcode facilities for new kernels, as early-init microcode update support should land in 3.6 or 3.7 and will require changes on how it interacts with the initramfs. I'd rather this was something simple to do for wheezy-stable through either a stable update, or a backport or a single simple package. > Named firmware files can generally be included in the kernel image, but > of course we won't do that in official Debian packages. It won't go through the firmware interface, that thing is not available early enough... the microcode update needs to be available during the bootstrap processor init. So far, it looks like it will be something initramfs-like that gets either added to the real initramfs or to the kernel image (I am not sure of the details), and has files with specific names inside with the relevant data blobs. Anyway, it will require updated userland to be used to its full functionality, so I'd prefer to have all userland logic in a single place that we can update and backport, instead o
Re: Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Fri, 22 Jun 2012, Ben Hutchings wrote: > On Sat, 2012-06-16 at 15:08 -0300, Henrique de Moraes Holschuh wrote: > > On Tue, 12 Jun 2012, Daniel Baumann wrote: > > > On 06/12/2012 06:04 PM, Henrique de Moraes Holschuh wrote: > > > > I don't care as long as nobody is going to get in the way of an > > > > urgency=high upload of firmware-nonfree to stable-proposed-updates or > > > > stable-updates. > > > > > > there have been updates of firmware-* packages in the past and more > > > recently for squeeze too, so i don't think that's a problem. > > > > > > > Well, the amd64-microcode has not cleared NEW yet. How should we > > > > proceed? > > > > > > in my personal opinion, i'd prefere having it integrated into > > > firmware-nonfree. but it's not my call but the kernel team to decide. > > > > Ok, I've looked into firmware-nonfree. > > > > The intel and amd64 microcode packages are not simple static data-drop > > packages (next upload of amd64-microcode will add the required postinst > > bits). > > > > They have to: > > > > 1. Issue sysfs commands to refresh running microcode > > With a current kernel, udev will load the firmware just as for any other > device. Yes, it will. At boot. And only if the driver is modular. And only if something specifically modprobes microcode, because it has no autoloading support in kernel 3.2 and earlier (I think that support was to land in 3.5, but it might already have landed in 3.4). So, Microcode needs to be refreshed when you upgrade the data files, and also when the driver is not modular (at least last time I tested it in a 3.0 kernel for Intel), and that requires postinst and initramfs specific magic (quite a lot for Intel, nearly none for AMD). Backporting the autoload code is not straigthforward. Adding MODULE_FIRMWARE() to the amd microcode driver is trivial and I think we should do it anyway. MODULE_FIRMWARE() is currently impossible for Intel and unless we want to possibly deviate from upstream, there is no way we can fix that right now. > > and update the initramfs when updated/installed. > > firmware-nonfree can do that (some network drivers need firmware). Is it amicable to special postinst code? If it is, it can take care of amd64-microcode. > > 2. Ensure that the microcode module and processor microcode will be added > > to the initramfs. > > Can be done by initramfs-tools. Yes, it can. But initramfs-tools has no specific code other than some NFS stuff, so we would probably benefit from a firmware-cpu-tools or whatever, which could drop the initramfs helper, dpkg triggers and helper scripts to get things done for both amd and intel microcode. I'd rather not duplicate this code for Intel and AMD, so it would need to end up in a -common/-util package of some sort (or in intramfs-tools directly, but I don't think that's a good idea): soon we will also need a new type of hook to piggyback the microcode using a initramfs-like container, either to the initramfs itself, or to the kernel image (I am not clear on that detail yet), and the microcode will be loaded on the BSP very very early, and on other cores BEFORE they're activated. This functionality has not landed in the kernel yet, but since we do know it is coming, we better make sure we will be able to take advantage of it without too much packaging rework. A -common/-util package is probably best for that, and I intend to upload something to that effort this weekend. > > This doesn't integrate automatically with firmware-nonfree right now, and I > > really don't have the time to add support to figure out everything in > > firmware-nonfree and add these operations to firmware-nonfree right before > > the freeze, > [...] > > Why don't you upload your package somewhere I can look at it? So far I > don't see any reason to add a new source package. Here: http://people.debian.org/~hmh/microcode/ as one cannot download from the NEW queue, where it is currently. The -1 packages are lacking the postinst snippet to refresh microcode, as that area was in flux over the last few days and I was actively participating on the thread in LKML to make sure we got something sane for userspace as the result. I was going to add the code to -2, now that the new sysfs nodes are set. It is in my laptop at home, and I can send it in later today. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120622190334.ga32...@khazad-dum.debian.net
Re: Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Tue, 12 Jun 2012, Daniel Baumann wrote: > On 06/12/2012 06:04 PM, Henrique de Moraes Holschuh wrote: > > I don't care as long as nobody is going to get in the way of an > > urgency=high upload of firmware-nonfree to stable-proposed-updates or > > stable-updates. > > there have been updates of firmware-* packages in the past and more > recently for squeeze too, so i don't think that's a problem. > > > Well, the amd64-microcode has not cleared NEW yet. How should we proceed? > > in my personal opinion, i'd prefere having it integrated into > firmware-nonfree. but it's not my call but the kernel team to decide. Ok, I've looked into firmware-nonfree. The intel and amd64 microcode packages are not simple static data-drop packages (next upload of amd64-microcode will add the required postinst bits). They have to: 1. Issue sysfs commands to refresh running microcode and update the initramfs when updated/installed. 2. Ensure that the microcode module and processor microcode will be added to the initramfs. This doesn't integrate automatically with firmware-nonfree right now, and I really don't have the time to add support to figure out everything in firmware-nonfree and add these operations to firmware-nonfree right before the freeze, while I have 95% of that work already done and tested for the intel-microcode and amd64-microcode packages. I am just waiting the amd64-microcode package to get past NEW to upload the required changes to intel-microcode. So, please approve the amd64-microcode package ASAP. I will make sure to provide a forward migration path to get both Intel and AMD64 microcodes integrated in firmware-nonfree for at least amd64-microcode, and if we get to a concensus that it makes sense to do so, also for intel-microcode. But I'd really prefer to defer that work to post-freeze. For Wheezy, we can just add suggests or recommends to firmware non-free for the amd64 and i386 arches, pointing to "intel-firmware | amd64-firmware". -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120616180842.ga32...@khazad-dum.debian.net
Re: Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Tue, 12 Jun 2012, Daniel Baumann wrote: > > so what is the point of adding it to firmware-nonfree? > > it would be nice to have everything in one place (= one src package), > than to have things split over several, make the firmware stuff be > updated all at once, and better integrated (by using '^-firmware' prefix). Well, I am really not sure about the "update all at once", especially if you take into account that stable updates are needed for processor microcode (we didn't do it for Intel because Intel's public microcode release management is a joke that is not even remotely funny. This _does not_ apply to AMD microcode, which has proper changelogs). But I don't care as long as nobody is going to get in the way of an urgency=high upload of firmware-nonfree to stable-proposed-updates or stable-updates. If this sort of upload is not a good idea for firmware-nonfree, then the processor microcodes would be better off in a separate package. > > We could make firmware-nonfree "recommend intel-microcode | > > amd64-microcode" on [i386, amd64], though. That sounds like a good > > idea to help people install the microcode updates. > > ack. Well, the amd64-microcode has not cleared NEW yet. How should we proceed? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612160430.ga17...@khazad-dum.debian.net
Re: Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Mon, 11 Jun 2012, Daniel Baumann wrote: > On 06/10/2012 04:31 PM, Henrique de Moraes Holschuh wrote: > > The microcode data file for Linux contains the latest microcode definitions > > for all AMD AMD64 processors. > > i'm aware that there's the intel-microcode package, however, why not > integrate this into firmware-nonfree (as firmware-amd-microcode or > something) and keep all this stuff at one place? intel-microcode will be some trouble to integrate, at least at this time, so I'd rather not do it for Wheezy. amd64-microcode could be integrated into firmware-nonfree without trouble. However, amd64-microcode has a different upstream, and it would already have to generate a separate binary package anyway for license reasons, so what is the point of adding it to firmware-nonfree? We could make firmware-nonfree "recommend intel-microcode | amd64-microcode" on [i386, amd64], though. That sounds like a good idea to help people install the microcode updates. After all, just about every new Intel and AMD processor has microcode patches issued, and both people and vendors are still as bad as they have always been at keeping their BIOS/EFI up-to-date... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612113426.ga26...@khazad-dum.debian.net
Re: Linux kernel hardening - link restrictions
On Fri, 02 Mar 2012, Ben Hutchings wrote: > We know that these are going to break some programs, most notably > 'at' (#597130, fixed in wheezy/sid). But of course it's possible Please consider pushing for a stable update of "at" to address this. It is extremely common to run Debian stable userspace with a newer kernel, and a lot of people will run Squeeze+3.x for a while yet... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120303024125.ga30...@khazad-dum.debian.net
Re: Bug#652026: amavisd-new: Init-script not working (stop/restart)
reassign 652026 amavisd-new thanks On Fri, 16 Dec 2011, Ben Hutchings wrote: > > What are those changes exactly? > [...] > > Whatever they are, they're not in the kernel. Hmm, I noticed /proc//stat was different on a 3.0 kernel, but it was a system that was not yet upgraded to perl 5.14. I recalled (possibly incorrectly) some talks about prctl changes in LKML. Obviously I should have tested this in a up-to-date chroot... I apologise for that. > It is possible to change command names stored by the kernel, by writing > to /proc//tasks//comm or by calling prctl(PR_SET_NAME, ...) > within the process. A quick grep doesn't show amavis using those > explicitly; it just sets $0. > > Sure enough, this is a documented change in Perl 5.14: > > Assignment to $0 sets the legacy process name with prctl() on > Linux > > On Linux the legacy process name is now set with prctl(2), in > addition to altering the POSIX name via argv[0], as Perl has > done since version 4.000. Now system utilities that read the > legacy process name such as ps, top, and killall recognize the > name you set when assigning to $0. The string you supply is > truncated at 16 bytes; this limitation is imposed by Linux. Hmm, this means we _will_ have to drop the use of --name in amavisd-new, no way around it. I wish I could use -u and -g, but that requires actually parsing the config files the same way amavisd-new does. Reassiging back to amavisd-new. I will file a wishlist bug for a --namere parameter for start-stop-daemon later, if we cannot find a better way to do it in amavisd-new. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111216233646.ga9...@khazad-dum.debian.net
Re: [Pkg-sysvinit-devel] system hangs during shutdown...
On Sun, 24 Jul 2011, Bruce Sass wrote: > On July 23, 2011 06:56:44 AM Henrique de Moraes Holschuh wrote: > > On Thu, 21 Jul 2011, Bruce Sass wrote: > > > > This is not a bug. NFS clients are supposed to keep on trying to reach > > > > the server, by default. You should have unmounted the directory from > > > > the NFS client(s) before shutting down the server. > > > > > > > > Ben. > > > > > > Sounds like a desirable behaviour when the system is coming up, but > > > having the client hang when *going down* because a server disappeared > > > doesn't seem right. > > > > Don't use NFS, then. It does NOT tolerate servers going away. Maybe > > NFSv4 is a bit better, but v3 does not let you get away with it (maybe > > it should for read-only mounts). > > It looks like NFSv4 doesn't like that happening either. > > Well, that kinda sucks,.. > > ...I'm thinking that initscripts should be smarter in that it should > recognize > hopeless cases and set a limit on how long the system will wait before > shutting down. Fully configurable, of course. The kernel will hang the umount command. Maybe a cluster filesystem would be a better fit for your needs? They tolerate that sort of thing a lot better. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011072526.ga28...@khazad-dum.debian.net
Re: [Pkg-sysvinit-devel] system hangs during shutdown...
On Thu, 21 Jul 2011, Bruce Sass wrote: > > This is not a bug. NFS clients are supposed to keep on trying to reach > > the server, by default. You should have unmounted the directory from > > the NFS client(s) before shutting down the server. > > > > Ben. > > Sounds like a desirable behaviour when the system is coming up, but having > the > client hang when *going down* because a server disappeared doesn't seem right. Don't use NFS, then. It does NOT tolerate servers going away. Maybe NFSv4 is a bit better, but v3 does not let you get away with it (maybe it should for read-only mounts). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110723125644.gb26...@khazad-dum.debian.net
Re: Linux 3.0
On Mon, 30 May 2011, Marco d'Itri wrote: > On May 30, Ben Hutchings wrote: > > There are likely to be many programs and build scripts that test for a > > kernel version prefix of '2.6' vs '2.4' and will behave incorrectly when > > they find '3.0'. Others require that there are at least 3 numeric > Expect module-init-tools and three udev scripts to break, for a start. > I will fix them in the next upload. > > This is hugely annoying, because it means that squeeze installs will > not work with the kernel from wheezy. Can't we fix that in a point release, by backporting fixes? > (How much difficult would it be to add some knob to the kernel or the > libc to make it report to userspace version 2.6.40? :-) ) That way lies madness :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110531140301.gd8...@khazad-dum.debian.net
Bug#600384: dm-crypt: please backport support for plain64 IV
Package: linux-2.6
Version: 2.6.32-25
Severity: important
Please backport commit 61afef614b013ee1b767cdd10325acae1db1f4d2
"dm crypt: add plain64 iv" from upstream. It should be a clean
cherry-pick.
Without it, Debian squeeze users might not be able to use dm-crypt
volumes created on newer kernels using *-xts-plain64, nor will be able
to create such volumes.
Using "plain" for IVs on block devices with more than 2^32 blocks will
cause the same IV to be used twice due to roll-over. This is not a good
thing, although it might be not bad enough to matter much (or it could
be a terrible problem. Someone who groks crypto for real would have to
answer that).
One cannot fix the "plain" IV to not warp at 2^32, or data after the
roll-over point becomes unreadable on any already-existing devices.
Thus, the only solution was to add a new IV ("plain64"). For devices
smaller than 2^32 512 byte blocks, plain and plain64 are equivalent.
Userspace and docs are already beggining to tell users to use
aes-xts-plain64 and not aes-xts-plain. They will use them in their
portable HDs, possibly on other distros, and then will not be able to
read them back in squeeze.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32.23 (SMP w/8 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20101016165729.32565.38223.report...@khazad-dum2.khazad-dum.debian.net
Re: CVE 2010-3081 changes internal API
Of course, it helps if I actually use the correct address for the debian-kernel ML... On Wed, 22 Sep 2010, Henrique de Moraes Holschuh wrote: > On Wed, 22 Sep 2010, Dan Serban wrote: > > On 09/22/10 07:54, Henrique de Moraes Holschuh wrote: > > >On Wed, 22 Sep 2010, Dan Serban wrote: > > >>[1012115.235704] ipmi_devintf: Unknown symbol compat_alloc_user_space > > >This module and the running kernel are not compatible with each other. > > > > > > > > So what you're telling me then, is that a bug needs to be filed > > against the stable kernel? I can't see stable being stable when > > modules won't load due to a security update. At least I'd assume > > that a broken kernel implementation needs to be fixed. > > compat_alloc_user_space() is only used for syscalls AFAIK. The rule is: you > do that, you have to track the kernel. In fact, it is now GPL-only (so, for > example, fglrx needs to be modified as it is forbidden from using > compat_alloc_user_space()). > > I'm adding a CC for the Debian kernel ML, just in case. > > Summary: > compat_alloc_user_space() is now EXPORT_SYMBOL_GPL > * cannot be used by fglrx and other non-GPL modules > * using arch_compat_alloc_user_space() may reopen CVE-2010-3081 > if the non-GPL module doesn't do access_ok by itself > > compat_alloc_user_space() moved from asm/compat.h to linux/compat.h > * requires #include changes on out-of-tree modules that use > compat_alloc_user_space() for them to build > > > OT: I've found about 4 major bugs with the lenny implementation > > running in different server roles. Mainly things that have been > > File bugs. Provide as much information as you can, the most useful being > the commits that you want backported, but if you don't know that, at least > full descriptions of the problem, how to reproduce, and what kernel version > you know fixed it would be helpful. > > > While I do understand and agree with the "no need to fix it if it > > a'int broken" mentality, does that mean that lenny does not get > > patched/bugfixed... just security updates? > > No. It does get patched/bugfixed. That's why we have "point releases", and > that's why it is at 5.0.6 (sixth point release) right now. But you usually > have to prod maintainers to fix something on stable, unless it is a very big > issue or a security issue. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100923004650.gb16...@khazad-dum.debian.net
Bug#565790: [stable] [ltp] Re: Bug#565790: cat /proc/acpi/ibm/video and must press power button
On Thu, 18 Mar 2010, Greg KH wrote: > On Wed, Mar 10, 2010 at 05:29:42PM -0300, Henrique de Moraes Holschuh wrote: > > On Tue, 09 Mar 2010, Moritz Muehlenhoff wrote: > > > On Mon, Feb 08, 2010 at 09:53:57PM -0200, Henrique de Moraes Holschuh > > > wrote: > > > > On Wed, 27 Jan 2010, jida...@jidanni.org wrote: > > > > > go reading /proc/acpi/ibm/video every day. But the curious user should > > > > > have to resort to the power button if he steps on this landmine. > > > > > > > > Sure. I limited it to CAP_SYS_ADMIN now, which usually means root. > > > > > > > > The patch will be sent for merging, but I can't promise it will be > > > > merged > > > > before the next merge window for 2.6.34, and only after that will it be > > > > a cantidade for a 2.6.32.y stable. > > > > > > > > Patch attached for reference. > > > > > > Adding sta...@kernel.org to CC. Please apply for 2.6.32.x : > > > This was merged in Linus' git as b525c06cdbd8a3963f0173ccd23f9147d4c384b5 > > > > They should already have it somewhere in their queue, since I have Cc'd them > > in the git commit message, which I understand is automatically parsed when > > the commit gets merged in mainline. > > Yes, I applied it to the .33.1 release. But it does not apply cleanly > to the .32 kernel. If you wish to see it there, please, can someone > provide me with a backported version? Will do, it will be in the next batch of -stable thinkpad-acpi fixes. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100319133114.gb16...@khazad-dum.debian.net
Bug#565790: [ltp] Re: Bug#565790: cat /proc/acpi/ibm/video and must press power button
On Tue, 09 Mar 2010, Moritz Muehlenhoff wrote: > On Mon, Feb 08, 2010 at 09:53:57PM -0200, Henrique de Moraes Holschuh wrote: > > On Wed, 27 Jan 2010, jida...@jidanni.org wrote: > > > go reading /proc/acpi/ibm/video every day. But the curious user should > > > have to resort to the power button if he steps on this landmine. > > > > Sure. I limited it to CAP_SYS_ADMIN now, which usually means root. > > > > The patch will be sent for merging, but I can't promise it will be merged > > before the next merge window for 2.6.34, and only after that will it be > > a cantidade for a 2.6.32.y stable. > > > > Patch attached for reference. > > Adding sta...@kernel.org to CC. Please apply for 2.6.32.x : > This was merged in Linus' git as b525c06cdbd8a3963f0173ccd23f9147d4c384b5 They should already have it somewhere in their queue, since I have Cc'd them in the git commit message, which I understand is automatically parsed when the commit gets merged in mainline. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100310202941.gb21...@khazad-dum.debian.net
Bug#565790: [ltp] Re: Bug#565790: cat /proc/acpi/ibm/video and must press power button
On Wed, 27 Jan 2010, jida...@jidanni.org wrote:
> go reading /proc/acpi/ibm/video every day. But the curious user should
> have to resort to the power button if he steps on this landmine.
Sure. I limited it to CAP_SYS_ADMIN now, which usually means root.
The patch will be sent for merging, but I can't promise it will be merged
before the next merge window for 2.6.34, and only after that will it be
a cantidade for a 2.6.32.y stable.
Patch attached for reference.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
commit 72772159f8105d2bfa8306ba079e0b2878b32e93
Author: Henrique de Moraes Holschuh
Date: Sun Feb 7 20:03:24 2010 -0200
thinkpad-acpi: lock down video output state access
Given the right combination of ThinkPad and X.org, just reading the
video output control state is enough to hard-crash X.org.
Until the day I somehow find out a model or BIOS cut date to not
provide this feature to ThinkPads that can do video switching through
X RandR, change permissions so that only processes with CAP_SYS_ADMIN
can access any sort of video output control state.
Reported-by: Jidanni
Signed-off-by: Henrique de Moraes Holschuh
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt
index 75afa12..39c0a09 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -650,6 +650,10 @@ LCD, CRT or DVI (if available). The following commands are available:
echo expand_toggle > /proc/acpi/ibm/video
echo video_switch > /proc/acpi/ibm/video
+NOTE: Access to this feature is restricted to processes owning the
+CAP_SYS_ADMIN capability for safety reasons, as it can interact badly
+enough with some versions of X.org to crash it.
+
Each video output device can be enabled or disabled individually.
Reading /proc/acpi/ibm/video shows the status of each device.
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 7e9cb67..dd7d286 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -319,9 +319,15 @@ config THINKPAD_ACPI_VIDEO
server running, phase of the moon, and the current mood of
Schroedinger's cat. If you can use X.org's RandR to control
your ThinkPad's video output ports instead of this feature,
- don't think twice: do it and say N here to save some memory.
+ don't think twice: do it and say N here to save memory and avoid
+ bad interactions with X.org.
- If you are not sure, say Y here.
+ NOTE: access to this feature is limited to processes with the
+ CAP_SYS_ADMIN capability, to avoid local DoS issues in platforms
+ where it interacts badly with X.org.
+
+ If you are not sure, say Y here but do try to check if you could
+ be using X.org RandR instead.
config THINKPAD_ACPI_HOTKEY_POLL
bool "Support NVRAM polling for hot keys"
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 0c40713..d12b61b 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -286,6 +286,7 @@ struct ibm_init_struct {
char param[32];
int (*init) (struct ibm_init_struct *);
+ mode_t base_procfs_mode;
struct ibm_struct *data;
};
@@ -4625,6 +4626,10 @@ static int video_read(struct seq_file *m)
return 0;
}
+ /* Even reads can crash X.org, so... */
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
status = video_outputsw_get();
if (status < 0)
return status;
@@ -4658,6 +4663,10 @@ static int video_write(char *buf)
if (video_supported == TPACPI_VIDEO_NONE)
return -ENODEV;
+ /* Even reads can crash X.org, let alone writes... */
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
enable = 0;
disable = 0;
@@ -8483,9 +8492,10 @@ static int __init ibm_init(struct ibm_init_struct *iibm)
"%s installed\n", ibm->name);
if (ibm->read) {
- mode_t mode;
+ mode_t mode = iibm->base_procfs_mode;
- mode = S_IRUGO;
+ if (!mode)
+ mode = S_IRUGO;
if (ibm->write)
mode |= S_IWUSR;
entry = proc_create_data(ibm->name, mode, proc_dir,
@@ -8676,6 +8686,7 @@ static struct ibm_init_struct ibms_init[] __initdata = {
#ifdef CONFIG_THINKPAD_ACPI_VIDEO
{
.init = video_init,
+ .base_procfs_mode = S_IRUSR,
.data = &video_driver_data,
},
#endif
Bug#565789: [ltp] Re: Bug#565789: say what the current Thinkpad BIOS/Firmware should be
On Thu, 21 Jan 2010, jida...@jidanni.org wrote: > >>>>> "H" == Henrique de Moraes Holschuh writes: > The warning to upgrade comes with the users current version number. The driver always logs the current version number at INFO priority at startup, because otherwise I don't know what firmware is in a thinkpad when I request the logs from someone. That is NOT part of the warning. It is not even in the same priority level. > I looked for the small file that corresponds to > drivers/platform/x86/thinkpad_acpi.ko > > Maybe it is somewhere on > http://repo.or.cz/w/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git/ > > I can't find it. You'd need to get it from one of the recent "release/*" branches. It will be easier if you just look at whatever is in Linus main kernel tree (the URL I sent you). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565789: [ltp] Re: Bug#565789: say what the current Thinkpad BIOS/Firmware should be
On Thu, 21 Jan 2010, jida...@jidanni.org wrote: > Candidate out of your binary. So I needn't download the whole kernel > source tar just to extract that one number each time I want to know what Go to http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree and navigate to drivers/platform/x86/thinkpad_acpi.c -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565789: say what the current Thinkpad BIOS/Firmware should be
On Thu, 21 Jan 2010, jida...@jidanni.org wrote: > Indeed, why tease the user with any version numbers in the first place, I don't. > if there is no way provided for him to pry the other half out of your > binary. If you care so much, go read the source code, which incidently is the ONLY thing I provide to anyone. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565789: [ltp] Re: Bug#565789: say what the current Thinkpad BIOS/Firmware should be
On Wed, 20 Jan 2010, jida...@jidanni.org wrote: > >>>>> "H" == Henrique de Moraes Holschuh writes: > > H> The version the driver thinks you should use is the latest that was > H> available when I wasted a few hours tracking them all. > > Yes, but in addition to giving the message > "Your version 1234 is out of date". > > You need to say "we believe the current version is 1236". No, I don't. You will either update or you will not update when you see that message. If you are going to try to update, you will need to download the firmware, and the web page where you can download it will give you the latest firmware. So, any version information is pointless, and it would look like I recommend a certain version instead of whatever is the latest. > And you need to say "this is based on information from > http://www.thinkwiki.org/wiki/BIOS_Upgrade ". No, because it is not. When I decide a BIOS type needs to be added to that table, I track down the lenovo page for that model and get the information from there. Whether a BIOS type will be added depends on it being stable (no updates for a long time), what the changelog says it fixes, and whether it fixes some problem I got a report for. It is not automatic. I also happen to take the opportunity to update thinkwiki, since I consider thinkwiki to be a really important resource, but that's orthogonal to the issue. And the canonical location IS the lenovo/IBM site. > Or else each user > 1. Will spend even more hours than the ones you mentioned, trying to track > down what you are warning him about. He will end up all over the You're the first one I know of that had so much trouble to locate it. I guess most people just ask in the thinkpad or lenovo forums (which I don't monitor). Some ask how to upgrade the bios in one of the two thinkpad MLs, and get told to look in thinkwiki. And some won't have much trouble locating it through the Lenovo site. > 2. He will be unable to write down on paper "don't worry about 1236. It's The "public changelog" is NOT complete, and I have received that information from official sources. > 3. Perhaps consider allowing the user to put the BIOS etc. numbers he is > happy with in some file that could be checked, so he could say "don't > warn me about anything up thru 1238 (even though he really has only 1236 > installed.) Well, you could just tell whatever tool you use to check the system logs to ignore it. It is logged only once per boot for most users (which don't rmmod/modprobe thinkpad-acpi once the system is running). Now, if it is causing a massive ruckus because of some widespread tool that looks in the kernel log for LOG_WARNING and scares the heck out of the users with warning sirens, that's a different deal. In that case I could be persuaded to lower the severity from LOG_WARN to LOG_NOTICE as a stopgap measure. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xen support on Squeeze
On Sun, 03 Jan 2010, William Pitcock wrote: > > That was opposed quite strongly by the kernel folks last time it was > > attempted. Were there any fundamental changes in the Xen dom0 patches > > since then? > > Only by the kernel folks which believe all of the crap that the KVM > guys say about Xen. There are plenty of kernel developers willing > to see the patches merged. Hmm, you have a problem there. Linus is very likely going to cheerfully tell the Xen and KVM developers to duke it out in a bloodbath, and to not forget to bring AlacrityVM into the fray either. He could care less for virtualization, and he is likely to refuse to merge anything non-trivial until the "virtualization crazy people" manage to reach a consensus on a sane API. Look for the AlacrityVM threads in LKML if you doubt me. Note: I am not defending KVM. I don't agree with their main ideology (that their hardware-emulating approach is the One True Way). But I can well see why Linus decided to take that instance. Xen's track record from hell on getting their act cleaned up for upstream merging is also going to get in the way. Some people have long memories. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521279: Bug#521280: acpid does support netlink, so the problem only affects thinkpad-acpi
On Thu, 21 May 2009, Michael Meskes wrote: > On Thu, Mar 26, 2009 at 12:44:32PM -0300, Henrique de Moraes Holschuh wrote: > > never had to look back at, before writing something. The non-hotkey events > > go over netlink, yes. But hotkeys go only over the input device, where they > > belong, and there is no driver switch to mess with that. > > Could anyone enlighten me please, where these events are to be found? acpid > does > not just read the netlink inteface but also the input layer and thus is > *supposed* to also get events coming over an input device. You can use > kacpimon > to try it out. I very much doubt it processes input events like KEY_FN_F1, or KEY_BLUETOOTH by default... and it shouldn't, either. No bugs on acpid here. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521279: acpid does support netlink, so the problem only affects thinkpad-acpi
Well, I just looked at the most up-to-date acpid, and it supports netlink. Therefore, the issue is just that thinkpad-acpi wants you to get hotkeys from the input layer since kernel 2.6.23, and now finally the borrowed time is over in Debian installs, with the procfs event delivery being shut off. What I wrote about a thinkpad-apci backwards compatibility mode was slightly incorrect... teaches me to trust memories over one year old about stuff I never had to look back at, before writing something. The non-hotkey events go over netlink, yes. But hotkeys go only over the input device, where they belong, and there is no driver switch to mess with that. This means that all configs that use acpid to process thinkpad-acpi hotkeys will break, and need to be ported over to HAL or something else that binds to input devices. I think these bugs can be tagged "wontfix", and we just deal with it as the usual perils of using "unstable" and "testing". It is probably a good idea to leave them open in the BTS for a while, in hopes that people will read them before filing more bugs. I don't think it affects any Debian standard config, but it will affect most of the local configs by end-users. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#485465: reboot(8) messes with Thinkpad brightness
On Fri, 08 Aug 2008, [EMAIL PROTECTED] wrote: > Dear HMH, I have continued my observations. It seems the only time I > have to still hit Fn End to bring the brightness back down is after a > reboot: using reboot(8) brings one to a super bright Lilo screen. > > And 'shutdown -h now' also will give a bright Lilo screen upon next > power up. (It is what I usually use, and each time the next day I have > to hit Fn End a few times there at the Lilo prompt before hitting RET > to enter GNU/Linux.) > > OK, as an experiment at the above Lilo screens, I did my usual Fn Ends > to bring the brightness down to the minimum, but then instead of > hitting RET to enter GNU/Linux (image=/boot/vmlinuz-2.6.25-2-686), I > hit ALT-CTRL-DEL to reboot without the "help" of the reboot(8) > command. I was back sitting at the Lilo prompt with no brightness > problems this time. At this point I hit the power off button. The next > day powering back on also saw no brightness problem sitting there at > the Lilo prompt. > > I conclude that my workaround, ># cat .bash_profile >case [EMAIL PROTECTED](hostname) in >[EMAIL PROTECTED]) >j=/tmp/.jidanni_thinkpad_brightness #/tmp gone at boot >! test -f $j && ! pidof xdm > /dev/null && >/sbin/rmmod thinkpad-acpi && >/sbin/modprobe thinkpad-acpi brightness_mode=2 && >touch $j;; [EMAIL PROTECTED] >esac > works great except that it does not cover the effects of reboot(8) and > shutdown(8). Therefore I would hope HMH would "neuter" them to not > mess with the brightness seen on the next boot! Thanks. I would, if I knew WHAT is screwing up with the brightness. I hope to have some time to hunt it down in Debconf 8. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485465: sometimes brightness OK (lowest) at boot
On Tue, 22 Jul 2008, [EMAIL PROTECTED] wrote: > Today I powered up and found brightness was already at its lowest. > > So sometimes brightness levels are remembered through boot for me, > but not always. > > Maybe a burglar alarm can be attached to the brightness, so that > whenever it is tampered with, a syslog entry will be made, so we can > tell what programs try to meddle with the brightness setting. If you are confortable recompiling the kernel, I can send you a patch with that "burgar alarm". Just tell me exactly which kernel you're using. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485465: battle for the brightness
On Fri, 18 Jul 2008, [EMAIL PROTECTED] wrote: > OK, some results: > Before shutdown -h I checked with Fn End that I was already in the > dimmest state. > > However, at the next power-up, sitting at the Lilo prompt, I could use > several Fn Ends to make the screen dimmer. Is the BIOS backlight control set to "normal"? It definately works on my T43... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485465: battle for the brightness
On Tue, 15 Jul 2008, [EMAIL PROTECTED] wrote: > H> Do I understand correctly, and now that you're using brightness_mode=2, you > H> see no weird brightness changes when you lauch xdm, and your brightness > keys > H> work just fine? > Yes, and yes. > > (I am still observing how well brightness settings last through boots. > I will mail back if they don't.) They will, no worries about that. The issue you can still have is that something might decide to change the brightness just before shutdown, and THAT changed brightness would be the one you'd get when you power up. But apparently, nobody broke things that much yet ;-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335814: udevd: get_netlink_msg: no ACTION in payload found
On Wed, 26 Oct 2005, Rogério Brito wrote: > On Oct 26 2005, Henrique de Moraes Holschuh wrote: > > I see it on mounts caused by automount. I don't see it on mounts > > caused by mount. So, we have one possible culprit. > > I see it with manual mounting of removable media (e.g., CDs). Hmm... come to think of it, that's what I use automout for. It could be removable media, then. Anyway, I can't reproduce it anymore, since 8 days ago: daemon.log.0:Oct 18 00:47:44 khazad-dum udevd[14729]: get_netlink_msg: no ACTION in payload found, skip event 'umount' It was not the kernel upgrade, that happened on Oct 11 (previously I was running stock 2.6.13.3 and warnings did show). It was not an udev upgrade on that day either, according to aptitude logs. Log shows that I did an init 1 approximately at that time, so it could have been a clean restart of automount or udev (I often kill udevd when I go to single-user mode). If it was a restart of udevd that fixed it, then the upgrade from 0.070-4 to 0.070-5 could be of significance. There are no automount upgrades in the logs. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Bug#301799: kernel-tree-2.6.11: new upstream source available: 2.6.11.6
On Mon, 04 Apr 2005, Sven Luther wrote: > No, the packages would still be kernel-*-2.6.11, but the version number would > be 2.6.11.6-, yiedling stuff like : > > kernel-source-2.6.11_2.6.11.6-1_all.deb > > Which is ok, and doesn't trigger NEW. I vote for that. Which is what I thought would happen. PLEASE accept this bug and number the kernel versions accordingly. We have two seconds now for this proposal, and no valid complains against it ;-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301799: kernel-tree-2.6.11: new upstream source available: 2.6.11.6
On Wed, 30 Mar 2005, Horms wrote: > > It is much more user-friendly, and it readly provides information on the > > most up-to-date tree it was synced with, in aptitude/dselect/synaptic... > > Yes, but the problem is that each time it changes backages > have to go through a NEW cycle. I assume you mean for the binary packages? I was only paying attention to the kernel-source, kernel-patch and kernel-tree packages... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301799: kernel-tree-2.6.11: new upstream source available: 2.6.11.6
On Wed, 30 Mar 2005, Horms wrote: > > with 2.6.11.X, including the numbering (i.e. next upload should be > > kernel-source-2.6.11, package version 2.6.11.6-1). > > I agree it would be good to sync up the patches, > but I don't think there is any need to include the > .6 in the debian version as we never did this for 2.6.8. It is much more user-friendly, and it readly provides information on the most up-to-date tree it was synced with, in aptitude/dselect/synaptic... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301799: kernel-tree-2.6.11: new upstream source available: 2.6.11.6
On Wed, 30 Mar 2005, Horms wrote: > With the exception of the load_elf_library problem, > which I will check on now, I believe I have patches for > the rest in SVN as neccessary for: I have checked 2.6.11 (looked it over, I am not running 2.6.11 here yet), and it looks OK. It would be a very good thing if we kept 2.6.11 in sync with 2.6.11.X, including the numbering (i.e. next upload should be kernel-source-2.6.11, package version 2.6.11.6-1). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301799: kernel-tree-2.6.11: new upstream source available: 2.6.11.6
Package: kernel-tree-2.6.11 Version: 2.6.11-1 Severity: grave Tags: security Justification: user security hole As usual. I feel weird filling what used to be a wishlist-level report as grave, but... Summary of changes from v2.6.11.5 to v2.6.11.6 == Chris Wright: o isofs: more defensive checks against corrupt isofs images o Linux 2.6.11.6 Herbert Xu: o Potential DOS in load_elf_library Linus Torvalds: o isofs: Handle corupted rock-ridge info slightly better o isofs: more "corrupted iso image" error cases Marcel Holtmann: o Fix signedness problem at socket creation Mathieu Lafon: o Suspected information leak (mem pages) in ext2 -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-debian6+libata9dev1+bluesmoke Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1) Versions of packages kernel-tree-2.6.11 depends on: ii kernel-patch-debian-2.6.112.6.11-1 Debian patches to Linux 2.6.11 ii kernel-source-2.6.11 2.6.11-1 Linux kernel source for version 2. -- no debconf information -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lvm2 crashes and burns with 2.6.10-4 (svn snapshot 2298)
On Sun, 16 Jan 2005, Henrique de Moraes Holschuh wrote: > Tracked down to 033-rlimit_memlock_check.dpatch. I did not check whether > 034-stack_resize_exploit.dpatch also causes problems, since it does not > apply without 033. Curiously enough, something IS setting a 32kbyte limit on locked memory even on the emergency shell (i.e. these limits are active during the early boot sequence). That caused the segfault, as the above patches were enforcing that limit. I am pretty sure I have not asked for such a draconian limit anywhere (and all greps I could think of seem to agree with me) -- and such a limit is cleary something we would be better off without at the early boot sequence. I will see if I can track down the culprit to make sure it is something stupid *I* did, as opposed to something higly stupid sysv-init or the kernel itself is doing, and file bugs accordingly depending on what I find. Anyway, apparently such limit enforcement is considered a bug (regardless of the fact that there should be no limit to be enforced in the first place), and Herbert Xu sent me a patch that fixes the issue. Thanks, Herbert! Maybe that patch should make it to the SVN tree? PS: Herbert, my provider seems to have screwed up again, and my static IP is being blacklisted by your server, so my replies to you were probably discarded. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lvm2 crashes and burns with 2.6.10-4 (svn snapshot 2298)
On Sun, 16 Jan 2005, Henrique de Moraes Holschuh wrote: > What happens is that vgchange -a y segfaults under 2.6.10-4, just after > mlockall(MLC_CURRENT|MLC_FUTURE) returns with a 0 state. At that point, > under 2.6.10-3, vgchange would brk(0). Under 2.6.10-4, it just segfaults. Tracked down to 033-rlimit_memlock_check.dpatch. I did not check whether 034-stack_resize_exploit.dpatch also causes problems, since it does not apply without 033. It may be my own fault (8MB limit on locked memory is active), in which case the kernel patch is OK and lvm2 has crappy code that goes bonkers when memalloc fails (what else is new...) instead of aborting with an error. I will test futher, and post back to this thread. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lvm2 crashes and burns with 2.6.10-4 (svn snapshot 2298)
On Sun, 16 Jan 2005, Henrique de Moraes Holschuh wrote: > This is apparently related to #281831, so I am directing it there. Well, it turns out it is not. vgscan is just being obnoxious as ever, but it has no bearing on the lvm crash with 2.6.10-4. I am cc'ing 281831 just to not leave a misleading note in there. What happens is that vgchange -a y segfaults under 2.6.10-4, just after mlockall(MLC_CURRENT|MLC_FUTURE) returns with a 0 state. At that point, under 2.6.10-3, vgchange would brk(0). Under 2.6.10-4, it just segfaults. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
lvm2 crashes and burns with 2.6.10-4 (svn snapshot 2298)
This is apparently related to #281831, so I am directing it there. The "opendir failed" messages might be "harmless" on 2.6.10-3 and before, but after I applied the patches in queue for 2.6.10-4, it causes lvm to fail completely (thus, I am Cc'ing debian-kernel as well, so that they are aware of the issue). Unfortunately, I can't easily debug why, since at that time, I don't have even strace working (because just about everything is on lvm...) If this is not an issue with 2.6.10-4 (e.g. it is actually caused by lvm2 doing something really braindead -- which IS likely since it is doing something stupid on the other kernels as well), then #281831 will have to be raised to grave or critical. vgscan --mknodes unlinks /dev/vg_raid1 (the VG where my LVM lvs live), but apparently it fails to create it back. /dev is udev-based (tmpfs). Manually poking around it (mkdir, etc) works just fine. This same setup, with the exact same .config worked in 2.6.10-3. Maybe one of the new security clamps is hosing something lvm2 is trying to do? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
