Attacking the kernel via its command line

Posted Jun 22, 2017 19:53 UTC (Thu) by pjones (subscriber, #31722)
In reply to: Attacking the kernel via its command line by thestinger
Parent article: Attacking the kernel via its command line

> Not what secure boot means. You're trying to push a redefinition
> of a term into one being pushed to market a meaningless non-security
> feature. Other vendors understand what secure / verified boot
> actually means: <2016 qualcomm presentation url here>

I'm sorry that Qualcomm has tricked you, with this 2016 presentation, into thinking when others are talking about Secure Boot they mean some generic concept. I do not, and neither do others in the quoted article and thread that you seem to so vehemently believe are wrong about (apparently) everything.

The rest of us are having a discussion about the "Secure Boot" term that has been used by basically all the client and server system firmware and bootloader developers across many OSes and companies to refer to one single feature and the ecosystem around it, and that feature has been deployed and supported for *years* now. If you want there to be some generic version that has some more generalized or more hardcore feature set, be my guest, but call it something else if you want people to understand you. Likewise, others likely will not speak in your own personal argot to describe the world they're in.

You can feel free to keep saying otherwise, but it just makes communication with you more difficult. That plus a persistent tone of "no no you're all wrong and biased against me" makes for a quite convincing rhetorical style.

> If you read what I and other people had written about it, you already
> would have learned why your view on it isn't correct.

Not the case. Suffice it to say that as somebody who has spent much time working on these issues, in open source code where everyone can see, I do not agree with your point of view, and find your arguments against what we've done utterly uncompelling in light of a very simple fact: it prevents the actual exploits in the wild.

With that said, and since I see that Florian and Kurt already tried to explain this to you, and you simply refused to listen to anything they said, I think we're done talking. You're clearly not ready to have a civil discussion or try to understand anyone else's point of view, much less the actual technical details.

> Not sure why you're responding without reading first.

Same. Have a nice life.

to post comments

Attacking the kernel via its command line

Posted Jun 22, 2017 20:06 UTC (Thu) by thestinger (guest, #91827) [Link]

> I'm sorry that Qualcomm has tricked you, with this 2016 presentation, into thinking when others are talking about Secure Boot they mean some generic concept. I do not, and neither do others in the quoted article and thread that you seem to so vehemently believe are wrong about (apparently) everything.

If you want much older documentation with vendors using the term secure boot... you can have that.

> The rest of us are having a discussion about the "Secure Boot" term that has been used by basically all the client and server system firmware and bootloader developers across many OSes and companies to refer to one single feature and the ecosystem around it, and that feature has been deployed and supported for *years* now. If you want there to be some generic version that has some more generalized or more hardcore feature set, be my guest, but call it something else if you want people to understand you. Likewise, others likely will not speak in your own personal argot to describe the world they're in.

You're the one using a generic term in a niche way. How much market share does desktop Linux have? And by the way, not all desktop and server distributions are interested in an incomplete implementation of secure / verified boot or redefining the term that way.

> Not the case. Suffice it to say that as somebody who has spent much time working on these issues, in open source code where everyone can see, I do not agree with your point of view, and find your arguments against what we've done utterly uncompelling in light of a very simple fact: it prevents the actual exploits in the wild.

It is the case. You're stuck in the bubble of cargo cult security land with apparently no experience with systems using meaningful verified boot which are far more common than the entirety of desktop Linux.

It doesn't prevent actual exploits, and you've been unable to provide any example of that. You made a false claim that this level of incomplete secure / verified boot implementation prevented making a rootkit hiding itself from the rest of the OS.

> With that said, and since I see that Florian and Kurt already tried to explain this to you, and you simply refused to listen to anything they said, I think we're done talking. You're clearly not ready to have a civil discussion or try to understand anyone else's point of view, much less the actual technical details.

You're only interested in pushing marketing drivel and cargo cult security. They didn't try to explain anything. All of you have refused to engage in a technical discussion. You only make arguments from authority and inaccurate claims that you cannot defend.

> Same. Have a nice life.

Have a nice time keeping the information security industry dishonest.

Attacking the kernel via its command line

Posted Jun 22, 2017 20:15 UTC (Thu) by thestinger (guest, #91827) [Link]

Here's a data sheet talking about Qualcomm Secure Boot from 2007, if it makes you happier. If you'd like, I can give you documentation from multiple vendors from even earlier.

https://www.mobileread.com/forums/attachment.php?attachme...

I'm quite familiar with what desktop Linux distributions are doing, but I don't live in a bubble where those are the only secure / verified boot implementations and they don't get to define generic terms. Elsewhere, there are meaningful implementations that have been shipping for a long time and cover not only the firmware, bootloaders and kernel but also userspace. In the case of iOS, beyond that, but in a weaker way. You would have known that if you had read what I wrote.