Please remove bnx2-mips (firmware data in hexadecimal)

[theLOICofFRANCE]

Hi Mathias,

I suggest removing bnx2-mips-09-6.2.1b.fw and bnx2-mips-09-6.2.1b.fw as this will lighten the patch (-0.6 mo) and this is easier to read (no ihex).
Moreover it is written: "This file contains firmware data derived from proprietary unpublished source code" So considering the architecture and the license I do not see the interest to keep this.
Also I do not think there is a lot of user of this driver.

The user who needs it will always be able to add this one (I can attach the driver here if necessary).

Thanks.

[minipli]

Removing those firmware files may break the use case for some still existing users, I don't know. So I'd rather not. And I don't think the patch size does matter -- does it?

The architecture reference is misleading as "MIPS" here refers to the chip on the NIC -- not the host driving it, which could be very well your beloved x86-64 ;)

The license should be fine, as it states:

Permission is hereby granted for the distribution of this firmware data
in hexadecimal or equivalent format, provided this copyright notice is
accompanying it.

So, if you've no strong arguments for removing those files, I'd rather keep them.

[theLOICofFRANCE]

1] If it is really useful... Why is it not upstream?
2] This driver will never be controlled or corrected. Can you read it?
3] To be compatible with the "parabola" (GNU/Linux-libre operating system) :
http://mirror.fsf.org/parabola/other/grsecurity-libre/test/

[minipli]

Re: 1] Well... you could argue the same for the rest of the patch, no? ;)
Re: 2] No, I can't. But at least the firmware files are the same as in [1]. Those are shipped in Debian as "firmware-bnx2". So I think it might be possible to drop those.
Re: 3] I don't try to be "compatible with the "parabola"", so that's no issue for me ;) And, apparently, they've been able to strip those parts from the official grsec patches themselves in the past. So why wouldn't they be able to do so now?

[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

[theLOICofFRANCE]

Re: 1] Well... you could argue the same for the rest of the patch, no? ;)

How long have add driver is the goal of this project? ^^

So why wouldn't they be able to do so now?

I think they are still able but they will not need to wash your hands :)

What do you think if you release one version without this for seeing the comments?

Regards,

[pedrib]

I'm all for making the patch more lightweight, but then you it's a roller coaster. There are many other things that could be removed.

If it bothers you so much why don't you fork and branch it?

[theLOICofFRANCE]

I can very well apply this on my side (unnecessary because I do not use this drivers):
remove-bnx2-06-6.2.3-and-09-6.2.1b.patch

In the end I will have downloaded a driver for nothing but that's not what I want when I download the unofficial_grsec patch. I want only security patch :)

There are many other things that could be removed.

What else by example?

If it bothers you so much why don't you fork and branch it?

For save time and effort. In addition Mathias works very well ;)

[pedrib]

Ah I see what you mean. So it comes with the patch? I thought you were talking about removing it from the actual kernel tree. Sorry my bad.

On Tue, 15 Aug 2017 at 21:42, Loïc ***@***.***> wrote: I can very well apply this on my side (unnecessary because I do not use this drivers): remove-bnx2-06-6.2.3-and-09-6.2.1b.patch <https://github.com/minipli/linux-unofficial_grsec/files/1226343/remove-bnx2-06-6.2.3-and-09-6.2.1b.txt> In the end I will have downloaded a driver for nothing but that's not what I want when I download the unofficial_grsec patch. I want only security patch :) There are many other things that could be removed. What else by example? If it bothers you so much why don't you fork and branch it? For save time and effort. In addition Mathias works very well ;) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFEMqOZ_6ObwPJMbmZc_nZTLp7BX0p4vks5sYgLQgaJpZM4OvbId> .

-- Pedro Ribeiro Vulnerability and Reverse Engineer / Cyber Security Specialist pedrib@gmail.com PGP: 17EE 7884 06C9 DCA3 76A6 99E9 BC04 BAD1 DDF2 A2CE

[g4jc]

When official grsec was still going strong we were regularly running the following snippet to remove the non-free binary blob:

filterdiff -p1 -x firmware/bnx2/* -x firmware/Makefile -x firmware/WHENCE grsec.patch > grsec-libre.patch

As long as no one is dependant on it, I think it's safe to remove (possibly increases security since we don't know what's in the blob) and improves the ability to redistribute.

Anyways, thanks for the great project. I've only recently discovered it and look forward to using these patches to secure linux-libre. 👍

[minipli]

The problem is the in-tree bnx2.ko network driver that actually requests those firmware files, see drivers/net/ethernet/broadcom/bnx2.c:

         64 #define FW_MIPS_FILE_06     "bnx2/bnx2-mips-06-6.2.3.fw"
         …
         66 #define FW_MIPS_FILE_09     "bnx2/bnx2-mips-09-6.2.1b.fw"
         …
       3709 static int bnx2_request_uncached_firmware(struct bnx2 *bp)
       3710 {
       3711     const char *mips_fw_file, *rv2p_fw_file;
       3712     const struct bnx2_mips_fw_file *mips_fw;
       3713     const struct bnx2_rv2p_fw_file *rv2p_fw;
       3714     int rc;
       3715
       3716     if (BNX2_CHIP(bp) == BNX2_CHIP_5709) {
 >>>>  3717         mips_fw_file = FW_MIPS_FILE_09;
       3718         if ((BNX2_CHIP_ID(bp) == BNX2_CHIP_ID_5709_A0) ||
       3719             (BNX2_CHIP_ID(bp) == BNX2_CHIP_ID_5709_A1))
       3720             rv2p_fw_file = FW_RV2P_FILE_09_Ax;
       3721         else
       3722             rv2p_fw_file = FW_RV2P_FILE_09;
       3723     } else {
 >>>>  3724         mips_fw_file = FW_MIPS_FILE_06;
       3725         rv2p_fw_file = FW_RV2P_FILE_06;
       3726     }
       3727
 >>>>  3728     rc = request_firmware(&bp->mips_firmware, mips_fw_file, &bp->pdev->dev);

However, a vanilla kernel doesn't ship those, only older versions. What the grsec patch does, is providing these firmware files in-tree without the need to use an external firmware package.

But as this is neither a security enhancement for the kernel itself nor a grsec-specific issue, I'm willing to remove those. It's an upstream usability problem only, after all.

[minipli]

I've removed the firmware files with commit fb4fc17(" firmware: drop bnx2 firmware files added by grsec"). It'll be included in the next release, i.e. post v4.9.44-unofficial_grsec.