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
>> mentio
8543.bin
Is the amd_pmf driver functional without that symlink ?
--
Henrique de Moraes Holschuh
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
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 'a
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
gt;
> > > 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
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 w
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
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 cau
--
"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
ing
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? Contac
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 y
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 a
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 rdra
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
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-k
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
>
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 f
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-too
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
> &
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 test
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 tha
o 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,
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
> > > &
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 th
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
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, si
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 reco
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 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-too
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
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 wr
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 appr
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
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
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), an
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 actio
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. firmwa
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
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:
> >
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 nobo
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.
>
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 usin
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-micr
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 usersp
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 reca
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 defaul
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 wh
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
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 kernel
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
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 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 re
ind 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
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 otherwis
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/p
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
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.
>
> Y
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 Xe
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
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.
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
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 tampere
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 con
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 set
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 removab
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 ha
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
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
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
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
==
Ch
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 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.
Tra
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
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 t
75 matches
Mail list logo
