On Tue, Apr 3, 2018 at 9:30 PM, Matthew Garrett <mjg59@xxxxxxxxxx> wrote:
>
> Bear in mind that I'm talking about defaults here
Mattyhew, I really want you to look yourself in the mirror.
Those defaults are really horrible defautls for real technical reasons.
You asked me why when I questioned this, but then when I replied, you
entirely ignored it.
So let me repeat: the defaults are *horrible*. They are horrible for a
very simple reason: kernel behavior changes that depend on some subtle
boot difference are truly nasty to debug, and nasty to get coverage
for.
And this "subtle boot difference" is really bad because it's a
difference that has a particularly bad pattern: pretty much not a
single mainline kernel developer will have secure boot enabled,
exactly because it's so inconvenient for testing.
So what does that mean?
It means that the default is *actively* bad for kernel development. It
means that the people who do kernel development will not be testing
the behavior that "normal" users will actually see.
If you do not see why that is a HORRIBLY BAD THING, I don't know what to say.
Seriously. It's a nasty nasty default behavior. It's absolutely
disastrously wrong.
And then when people call you out on this bad linkage of this feature
with secure boot, you spent a *LOT* of time being dishonest about it.
Instead of answeing a simple technical question, you did just about
everything you could to avoid answering it.
You initially turned the question back into a "Why would you want to?"
rather than just answering.
Then you spent a whole lot of time coming up with completely wrong
excuses that had no actual technical reason for them.
And even now, you're trying to ignore the question, and the REASON for
the question.
See above: the default is really horrendously bad, and is just about
the *worst* default you could ever pick from a kernel development
angle.
So when a kernel developer - both me and Andy - ask you about the
reason for that HORRIBLY BAD default, then you had better stop dancing
around the issue, and be honesy.
Instead, you bring up complete red herrings:
> If a user has a configuration where you're able to verify that userspace
> has some degree of protection (eg, disk encryption keys are in the TPM and
> won't unseal if someone's switched out the kernel) then it's reasonable for
> userland (or a kernel command line option) to enable the functionality.
This line of arguyment of yours ends up STILL being complete and utter garbage.
There is not a single shred of evidence that there is some kind of
"reasonable to enable the functionality" based on completely unrelated
matters.
See above on why such stupid linkages are a bad bad idea. Absolutely
*ANY* time you make that decision silently for a user, you will just
be doing the wrong thing.
You will do the wrong thing for security, but equally importantly, you
will be doing the wrong thing just for *development* and *test
coverage*.
> What I'm afraid of is this turning into a "security" feature that ends up
> being circumvented in most scenarios where it's currently deployed - eg,
> module signatures are mostly worthless in the non-lockdown case because you
> can just grab the sig_enforce symbol address and then kexec a preamble that
> flips it back to N regardless of the kernel config.
Honestyly, all of your arguments are made up shit.
This argument, for example, is just a complete red herring.
Do you want to protect against somebody flipping "sig_enforce"? Makes
perfect sense to me.
Then WHY is that not just a config option for extra hardening?
Seriously. I'd use it. I have never *ever* felt the need to switch
"sig_enforce" off, and I always build with MODULE_SIG_FORCE and
MODULE_SIG_ALL.
Getting rid of that switch entirely for security reasons sounds just
_fine_ to me.
So you use these *stupid* things as "arguments" for why you think you
want to do something. But you're putting the cart before the horse:
you have a particular end result you want to get to, and then you make
up arguments for why you want to get there.
Seriously, go back to that coverage and testing issue. Go back to the
*fundamental* technical issue that we want kernel developers to
actually *test* the code that users are running.
*Gasp*.
Yeah, I know, it's a completely radical idea, but it's true. Having
developers test and run the code actual real humans are using is a
truly revolutionary concept in security too.
> I'm making this argument from the perspective of "What should the kernel do
> when it has no additional information".
And I'm telling you that you're ignoring the fact that you picked a
truly horrendously shitty default.
And then you spent a *lot* of time giving misleading and bad
information about why you picked that shitty default, and instead just
questioning the people who asked you an actual and really simply
technical question.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
