grsecurity forums

Hi,

I found a binary code section in grsecurity-3.1-4.0.4-201505222222.patch under "diff --git a/firmware/bnx2/bnx2-mips-09-6.2.1b.fw.ihex b/firmware/bnx2/bnx2-mips-09-6.2.1b.fw.ihex"
I can't remember a binary blob being shipped in previous diffs from a month ago.
Whats the rationale for shipping this proprietary Broadcom firmware in the grsec patch?

Thanks, and keep up the amazing work!

Okay, seems someone else asked the same a bit later on twitter: https://twitter.com/grsecurity/status/6 ... 2233437184
Now I also know, that grsec has a changelog ... https://grsecurity.net/changelog-test.txt,
which states:

Include the required BNX2 firmware from Broadcom for usability
purposes. Performed whitespace changes on the WHENCE file to
ensure Broadcom's license for the file is not only contained in
the resulting compilation but also in the patch itself. It is
being distributed in hex format as permitted by their license.

To be honest, I do not welcome that change as it breaks patching linux-libre, which worked without manual intervention before.
Since it brings no security benefit, in fact no benefit to anybody, apart from people running that particular piece of hardware (requiring closed firmware), I highly question that change, but I can live with it, just makes my life harder.

I use the linux-libre kernel too because I am a free software enthusiast. In spite of admiring the effectiveness of Grsecurity and the great work whose developers have done, it ist not acceptable for me to use proprietary non-free software. I don't understand why Grsecurity is starting to go that way.

It's only included if you have CONFIG_BNX2 enabled. It could probably just be submitted upstream and then linux-libre would remove it with the rest, but it's already optional.

Sim: you do not have to accept the blob in grsec, simply deblob the patch using the following command:

Code: Select all

filterdiff -p1 -x firmware/bnx2/* -x firmware/Makefile -x firmware/WHENCE $PATCHFILE  > $PATCHFILE.new

where $PATCHFILE is the name of the grsec patch file.

Thanks alan.d for showing me how to deblob grsecurity.
Are there any other blobs in grsecurity I am not aware of?

Yes, on every processor released in the past decade there's a big encrypted blob called the microcode -- you should use an opensparc to be truly libre!
Also, every BIOS comes packaged with microcode updates -- you should wipe your BIOS to be truly libre!
The bike-shed is made with some proprietary bits, you should replace them as well to be truly libre!

-Brad

Sim, in the grsec patch not really. You can check this yourself by opening the patch in a text editor.

Of course spender is right with his post, a truly open system that is modern does not really exist and your hardware has blobs embedded you can't change.
As a security expert he knows all the ways your system could still be compromised, even if you only run perfect, bug-free/backdoor-free open source software.
I am really happy spender is still motivated and awesome, he doesn't have to be a free software religionist and if he wants a fix a blob in his patch, he is right to do so.
spender, PaX Team, kudos for all your work, you are awesome!

Personally I am of the opinion you have to start somewhere, even if your hardware is still a blackbox with all it's hidden blobs.
Even if everything would be open source, one could't audit everything, I know the world is too bad. We can only live with ideals in mind.
I guess, to spender this sounds like the statements of the SELinux people: "In the absence of other bugs".

Unfortunately, sometimes I have to accept to use binary blobs because otherwise I would greatly limiting the quality of my life.
If the consequence of using free software is a bit inconvenience, I will decide to bear the inconvenience.
Concerning the proprietary bios: I bought a freedom-friendly laptop (http://shop.gluglug.org.uk), which is certified by the Free Software Foundation and runs with libreboot. So at least I don't have to wipe my bios.

do you have microcode updates or not? their website says that the machines can work without one but doesn't actually state that they ship them that way. FYI, microcode updates fix bugs with security and reliability impact.

Thanks for the information.

As I said I have to accept non-free software if there is no satisfying alternative. Deblob Grsecurity is a good alternative. To wipe my bios is not a good alternative - at least for me. To accept non-free software to a certain degree in my life does not change my wish to use as little non-free software as possible.

I'm not a security expert, so I have to trust some people. I trust the judgement of the Free Software Foundation in deciding which computer to use is best in terms of free software.

I don't understand why you decided to use proprietary Broadcom firmware in Grsecurity. Is it possible to know that it isn't a backdoor?

i don't follow your logic. you're saying that a blob is fine as long as it satisfies *your* needs but let everyone else be damned if they have a need for another blob (why else do you think they exist in the kernel tree?). as for deblobbing grsec or linux itself: i don't see what purpose it serves. if you want to use the hw the blob is for then by definition you can't remove the blob. and if you don't have or want to use the hw then just don't configure in the corresponding driver and blob and you'll get a deblobbed vmlinux without having to burden yourself with even more out-of-tree patches.

PS: grsec doesn't use the blob, the network card driven by the bnx2 driver does (same for all the other blobs under firmware/bnx2). and if you worry about it having a backdoor, then i have bad news for you: even if it was open source, it could still be backdoored (it'd even be easier with source code at hand in fact) and uploaded to the network card and noone would be the wiser.

PaX Team wrote:i don't follow your logic. you're saying that a blob is fine as long as it satisfies *your* needs but let everyone else be damned if they have a need for another blob (why else do you think they exist in the kernel tree?). as for deblobbing grsec or linux itself: i don't see what purpose it serves. if you want to use the hw the blob is for then by definition you can't remove the blob. and if you don't have or want to use the hw then just don't configure in the corresponding driver and blob and you'll get a deblobbed vmlinux without having to burden yourself with even more out-of-tree patches.

I understand now. My logic was flawed.
But I think it would be good if the proprietary driver would be marked as such, so that someone can decide if it really fits his/her needs. Maybe he/she doesn't really need that part of the hw (e.g. a webcam).

PaX Team wrote:PS: grsec doesn't use the blob, the network card driven by the bnx2 driver does (same for all the other blobs under firmware/bnx2). and if you worry about it having a backdoor, then i have bad news for you: even if it was open source, it could still be backdoored (it'd even be easier with source code at hand in fact) and uploaded to the network card and noone would be the wiser.

But with open source you have the chance to find the backdoor. Wasn't that the case with the heartbleed bug, which would otherwise be undetected until now?

Sim wrote:But I think it would be good if the proprietary driver would be marked as such, so that someone can decide if it really fits his/her needs. Maybe he/she doesn't really need that part of the hw (e.g. a webcam).

you're asking for a kernel config system facility on the wrong forum . this is material for the linux kernel list, you should raise your concerns there and if any solution comes out of it, we'll make use of it (for the bnx2 blob case the situation would sort itself out in fact since grsec doesn't add a new driver, just a newer version of the blobs that already exist for this device).

But with open source you have the chance to find the backdoor.

finding a backdoor doesn't require source code access. in fact the best backdoors are disguised as some security bug (say subtle memory corruption and other kinds of undefined behaviour in C) for plausible deniability and finding them in binary code may be the only way (think of CVE-2009-1897 for example).

another aspect is that there're two ways a backdoor gets into your system: you install it unknowingly or someone else does it for you. while in the former case availability of source code may help find the backdoor, in the latter case you won't have the source code at all nor see the attempt of installing the backdoor so you'll be left with analyzing binary code.

Wasn't that the case with the heartbleed bug, which would otherwise be undetected until now?

we don't (and will probably never) know if the bug was found before its public disclosure last year but we do know how it could have been found without the source code: http://www.dwheeler.com/essays/heartbleed.html .