Re: [GNU-linux-libre] linux ppc micropatch.c: why keep it?

[Jeff Moe via gnu-linux-libre]

On 8/22/21 3:27 AM, Alexandre Oliva wrote:

When I got involved with Linux-libre back in 2008, a file named
micropatch.c already existed in the Linux source tree, in
arch/powerpc/sysdev/micropatch.c.  It's now in
arch/powerpc/platforms/8xx/micropatch.c.

The initial version, added back in 2007, had two sets of binary
"patches".  Comments stated:

   /* Microcode patches for the CPM as supplied by Motorola.

(CPM stands Communication Processor Module)

Despite the appearance that these "patches" could be code rather than
configuration data, gNewSense (and then BLAG) appear to have decided
that it could be left in, for reasons unknown to me.  I assumed there
were good reasons for that, even though I didn't know them, so the
binary "patches" have remained in Linux-libre releases since then.

For most of the time, they've remained unchanged, except for
reformatting of the arrays containing them.  Back in Jun 14, 2019, a new
set of binary "patches" were added.  It was quite similar in appearance
and spirit, so I also retained it, assuming the same reasons applied.
Part of the commit message that introduced the new bits states:

 This microcode is provided by Freescale/NXP in Engineering Bulletin
 EB662 ("MPC8xx I2C/SPI and SMC Relocation Microcode Packages")
 dated 2006. The binary code is public. The source is not available.

Recently, someone asked in the GNU Linux-libre discussion list why we
didn't remove these bits.  I don't know the answer.  I wish I did.  I
find myself wondering whether it should really have been left alone.

Does anyone have any insights to share as to why this might have been
left in?  Absent more information, if I were to come across it today,
I'd most certainly have removed it from Linux-libre, so I'm leaning
towards doing so in the git history rewrite project I've been slowly
working on.

thanks in advance for any information you may provide,



It appears gNewsense categorized it as a false positive, back in the 
day. I don't know why.


You can see a snapshot of it from their subversion here (ctrl-f 
micropatch.c):


https://web.archive.org/web/20090106133329/http://svn.gnewsense.svnhopper.net/gnewsense/builder/tags/deltad-2008-03-24/firmware/firmware-false-positive

I haven't found any reference to micropatch.c in my old LinuxLibre files.

FYI,

-Jeff

Re: [GNU-linux-libre] linux ppc micropatch.c: why keep it?

[Alexandre Oliva]

On Aug 31, 2021, Jeff Moe  wrote:

> In the end, I didn't use gNewsense's tools, nor review their work.

Thanks, that's useful information, that makes it clear I misplaced trust
on the double-checking I had assumed.

> I *started* to go thru their kernel, but it was false positive after
> false positive, since they had been using the Ubuntu kernel, not the
> Linus kernel.

Well...  AFAIK Ubuntu backports drivers and stuff, but I don't know that
they integrate stuff that isn't going to eventually get merged, so
recognizing false positives present in their kernel versions may not be
useful for corresponding upstream release, but it's likely that it would
be useful for subsequent upstream releases, so it wouldn't be wasted
work if automated.

IIUC you did that mostly manually (an heroic job IMHO; I can't ever
thank enough you and others who went through it), though, so...  Yeah,
frustrating and pointless.

> I should also point out, I'm a sysadmin, not a kernel programmer or
> gcc maintainer or anything like that. I'd never state a kernel "ground
> truth"!

Fair enough.  I hope you don't mind that I trusted your review though.
Trust and verify, as they say.  What I saw when I took up Linux-libre
was so solid that after enough double- (triple-, I thought then)
checking, I came to believe it was correct.  And, despite this one
mistake, and your clarification, I still place a great deal of trust in
it, and would face a hard time challenging analyses from back then.


>> I'm now inclined to believe that leaving this file alone was one
>> of very few mistakes (perhaps the only one) made in the initial
>> cleaning-up,

> If I only made one mistake in the initial release, I was lucky!

... and modest, after doing such a superb job ;-D

Thank you very much!

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [GNU-linux-libre] linux ppc micropatch.c: why keep it?

[Jeff Moe via gnu-linux-libre]

On 8/26/21 11:00 PM, Alexandre Oliva wrote:

Though I used to take gNewSense's review double-checked by you as ground
truth,


Some incorrect assumptions in your message. To correct just for the history:

In the end, I didn't use gNewsense's tools, nor review their work. I 
*started* to go thru their kernel, but it was false positive after false 
positive, since they had been using the Ubuntu kernel, not the Linus 
kernel. I just stopped even looking at the gNewsense kernel because it 
was annoying me each time I found non-free bits that were in Ubuntu's 
but not in Linus' kernel. I had no interest in cleaning up the Ubuntu 
kernel, so it was a waste of time. I was interested in cleaning up the 
mainline Linus kernel. So very early on in Linux Libre, I stopped 
looking at gNewsense. I have never double-checked gNewsense's work--not 
back then, not since then.


I should also point out, I'm a sysadmin, not a kernel programmer or gcc 
maintainer or anything like that. I'd never state a kernel "ground truth"!



I'm now inclined to believe that leaving this file alone was one
of very few mistakes (perhaps the only one) made in the initial
cleaning-up,


If I only made one mistake in the initial release, I was lucky!

-Jeff

Re: [GNU-linux-libre] linux ppc micropatch.c: why keep it?

[Alexandre Oliva]

On Aug 24, 2021, Jeff Moe  wrote:

> Hi Alexandre, it looks like you BCC'd me to a list post.

Indeed.  Sorry I didn't say so explicitly.

> https://lists.autistici.org/message/20080221.002845.467ba592.en.html

> It does not mention the CPM code.

Exactly.  It mentions bits that were removed.  The ppc microcode was
retained, so it wasn't mentioned.  It must have been flagged by
find-firmware, though.  The important question for me was why it was
retained.  I figured there was a good reason for that.

Though I used to take gNewSense's review double-checked by you as ground
truth, I'm now inclined to believe that leaving this file alone was one
of very few mistakes (perhaps the only one) made in the initial
cleaning-up, and that we've been carrying over under the assumption
there had been good reason to keep it.

vs6624_p1 in vs6624.c seems to have been another such mistake, tough
this one I made myself, and I'm about to correct it.

I'm also asking for broader opinions on arch/parisc/kernel/perf_images.h
and on cx11646_fw1 in drivers/media/video/gspca/conex.c.  The former
looks like data rather than code, so it could be fine, but though the
file states GPL, it also states it was borrowed from HP-UX.  The latter
amounts to 64 bytes of firmware that could very well be code (though it
might as well be pure data), and it's so small that it is believable
that there's no other source form.

Both have been retained over several releases, but since I've made
mistakes myself, and I'm respinning releases, and working on the git
history rewrite, I thought it would be a good time to revisit these if
needed.

Thanks,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [GNU-linux-libre] linux ppc micropatch.c: why keep it?

[Jeff Moe via gnu-linux-libre]

On 8/22/21 3:27 AM, Alexandre Oliva wrote:

When I got involved with Linux-libre back in 2008, a file named
micropatch.c already existed in the Linux source tree, in
arch/powerpc/sysdev/micropatch.c.  It's now in
arch/powerpc/platforms/8xx/micropatch.c.

The initial version, added back in 2007, had two sets of binary
"patches".  Comments stated:

   /* Microcode patches for the CPM as supplied by Motorola.

(CPM stands Communication Processor Module)

Despite the appearance that these "patches" could be code rather than
configuration data, gNewSense (and then BLAG) appear to have decided
that it could be left in, for reasons unknown to me.  I assumed there
were good reasons for that, even though I didn't know them, so the
binary "patches" have remained in Linux-libre releases since then.

For most of the time, they've remained unchanged, except for
reformatting of the arrays containing them.  Back in Jun 14, 2019, a new
set of binary "patches" were added.  It was quite similar in appearance
and spirit, so I also retained it, assuming the same reasons applied.
Part of the commit message that introduced the new bits states:

 This microcode is provided by Freescale/NXP in Engineering Bulletin
 EB662 ("MPC8xx I2C/SPI and SMC Relocation Microcode Packages")
 dated 2006. The binary code is public. The source is not available.

Recently, someone asked in the GNU Linux-libre discussion list why we
didn't remove these bits.  I don't know the answer.  I wish I did.  I
find myself wondering whether it should really have been left alone.

Does anyone have any insights to share as to why this might have been
left in?  Absent more information, if I were to come across it today,
I'd most certainly have removed it from Linux-libre, so I'm leaning
towards doing so in the git history rewrite project I've been slowly
working on.

thanks in advance for any information you may provide,



Hi Alexandre, it looks like you BCC'd me to a list post.

There's a few incorrect assumptions above. I'll just state what I know. 
Here is the original Linux Libre announcement:


https://lists.autistici.org/message/20080221.002845.467ba592.en.html

It does not mention the CPM code. Doing some quick searches for that 
micropatch code and "Linux Libre" the only reference to it that I found 
was your apparent whitelisting of it and the present discussion. I don't 
see anywhere where BLAG/Linux Libre "appear to have decided
that it could be left in". I think the safer assumption is that it was 
missed if it was there at all. That said, that was forever ago and I 
don't really see why it would matter. If it is non-free, yank it, who 
cares what I thought a decade+ ago about it or not? :)


-Jeff

Re: [GNU-linux-libre] linux ppc micropatch.c: why keep it?

[Jason Self]

I have been unable to locate this engineering bulletin myself. I opened
a support ticket with NXP asking for a copy. Just in case being able to
see the actual engineering bulletin is helpful in some way.


pgpwYuAlknGen.pgp
Description: OpenPGP digital signature

[GNU-linux-libre] linux ppc micropatch.c: why keep it?

[Alexandre Oliva]

When I got involved with Linux-libre back in 2008, a file named
micropatch.c already existed in the Linux source tree, in
arch/powerpc/sysdev/micropatch.c.  It's now in
arch/powerpc/platforms/8xx/micropatch.c.

The initial version, added back in 2007, had two sets of binary
"patches".  Comments stated:

  /* Microcode patches for the CPM as supplied by Motorola.

(CPM stands Communication Processor Module)

Despite the appearance that these "patches" could be code rather than
configuration data, gNewSense (and then BLAG) appear to have decided
that it could be left in, for reasons unknown to me.  I assumed there
were good reasons for that, even though I didn't know them, so the
binary "patches" have remained in Linux-libre releases since then.

For most of the time, they've remained unchanged, except for
reformatting of the arrays containing them.  Back in Jun 14, 2019, a new
set of binary "patches" were added.  It was quite similar in appearance
and spirit, so I also retained it, assuming the same reasons applied.
Part of the commit message that introduced the new bits states:

This microcode is provided by Freescale/NXP in Engineering Bulletin
EB662 ("MPC8xx I2C/SPI and SMC Relocation Microcode Packages")
dated 2006. The binary code is public. The source is not available.

Recently, someone asked in the GNU Linux-libre discussion list why we
didn't remove these bits.  I don't know the answer.  I wish I did.  I
find myself wondering whether it should really have been left alone.

Does anyone have any insights to share as to why this might have been
left in?  Absent more information, if I were to come across it today,
I'd most certainly have removed it from Linux-libre, so I'm leaning
towards doing so in the git history rewrite project I've been slowly
working on.

thanks in advance for any information you may provide,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about