On Tue, Dec 05, 2017 at 11:27:58AM +0100, Pavel Machek wrote:
> Hi!
>
> > > Our ability to determine that userland hasn't been tampered with
> > > depends on the kernel being trustworthy. If userland can upload
> > > arbitrary firmware to DMA-capable devices then we can no longer trust
> > > the
> I am curious though, is the above notion of having hardware require signed
> firmware an implication brought down by UEFI? If so do you have any pointers
> to where this is stipulated? Or is it just a best practice we assume some
> manufacturers are implementing?
It's a mix of best practice and
Hi!
> > Our ability to determine that userland hasn't been tampered with
> > depends on the kernel being trustworthy. If userland can upload
> > arbitrary firmware to DMA-capable devices then we can no longer trust
> > the kernel. So yes, firmware is special.
>
> You're ignoring the whole
On Mon, Nov 13, 2017 at 09:08:48PM +, Alan Cox wrote:
> On Mon, 13 Nov 2017 18:42:50 +0100
> "Luis R. Rodriguez" wrote:
>
> > On Sat, Nov 11, 2017 at 02:32:40AM +, Alan Cox wrote:
> > > > My assumption here is:
> > > > 1) there are some less important and so
On Wed, 2017-11-15 at 21:46 +0100, Luis R. Rodriguez wrote:
> On Wed, Nov 15, 2017 at 02:56:57PM -0500, Mimi Zohar wrote:
> > On Wed, 2017-11-15 at 18:52 +0100, Luis R. Rodriguez wrote:
> > > On Wed, Nov 15, 2017 at 06:49:57AM -0500, Mimi Zohar wrote:
> > > > On Tue, 2017-11-14 at 21:50 +0100,
On Wed, Nov 15, 2017 at 02:56:57PM -0500, Mimi Zohar wrote:
> On Wed, 2017-11-15 at 18:52 +0100, Luis R. Rodriguez wrote:
> > On Wed, Nov 15, 2017 at 06:49:57AM -0500, Mimi Zohar wrote:
> > > On Tue, 2017-11-14 at 21:50 +0100, Luis R. Rodriguez wrote:
> > >
> > > > Johannes made cfg80211 recently
On Wed, 2017-11-15 at 18:52 +0100, Luis R. Rodriguez wrote:
> On Wed, Nov 15, 2017 at 06:49:57AM -0500, Mimi Zohar wrote:
> > On Tue, 2017-11-14 at 21:50 +0100, Luis R. Rodriguez wrote:
> >
> > > Johannes made cfg80211 recently just use request_firmware() now via
> > > commit on
> > > linux-next
On Wed, Nov 15, 2017 at 06:49:57AM -0500, Mimi Zohar wrote:
> On Tue, 2017-11-14 at 21:50 +0100, Luis R. Rodriguez wrote:
>
> > Johannes made cfg80211 recently just use request_firmware() now via commit
> > on
> > linux-next 90a53e4432 ("cfg80211: implement regdb signature checking") [0]
> > as
On Tue, 2017-11-14 at 21:50 +0100, Luis R. Rodriguez wrote:
> Johannes made cfg80211 recently just use request_firmware() now via commit on
> linux-next 90a53e4432 ("cfg80211: implement regdb signature checking") [0] as
> he got tired of waiting firmware signing, but note he implemented a
On Tue, Nov 14, 2017 at 2:31 PM, James Bottomley
wrote:
> On Tue, 2017-11-14 at 14:17 -0800, Matthew Garrett wrote:
>> Measured boot has a great deal of value in the sealing of private
>> material, even in the absence of attestation. The way Microsoft make
On Tue, 2017-11-14 at 14:17 -0800, Matthew Garrett wrote:
> On Tue, Nov 14, 2017 at 2:14 PM, James Bottomley
> wrote:
> >
> > On Tue, 2017-11-14 at 15:55 -0500, Matthew Garrett wrote:
> > >
> > > TPM-backed Trusted Boot means you don't /need/ to sign
On Tue, Nov 14, 2017 at 2:14 PM, James Bottomley
wrote:
> On Tue, 2017-11-14 at 15:55 -0500, Matthew Garrett wrote:
>> TPM-backed Trusted Boot means you don't /need/ to sign anything,
>> since the measurements of what you loaded will end up in the TPM. But
On Tue, 2017-11-14 at 15:55 -0500, Matthew Garrett wrote:
> On Tue, Nov 14, 2017 at 3:50 PM, Luis R. Rodriguez > wrote:
> >
> > On Tue, Nov 14, 2017 at 12:18:54PM -0800, Linus Torvalds wrote:
> > >
> > > This is all theoretical security masturbation. The _real_ attacks
> > >
On Tue, Nov 14, 2017 at 3:50 PM, Luis R. Rodriguez wrote:
> On Tue, Nov 14, 2017 at 12:18:54PM -0800, Linus Torvalds wrote:
>> This is all theoretical security masturbation. The _real_ attacks have
>> been elsewhere.
>
> In my research on this front I'll have to agree with
On Tue, Nov 14, 2017 at 12:18:54PM -0800, Linus Torvalds wrote:
> This is all theoretical security masturbation. The _real_ attacks have
> been elsewhere.
In my research on this front I'll have to agree with this, in terms of
justification and there are only *two* arguments which I've so far have
On Tue, Nov 14, 2017 at 3:35 PM, Linus Torvalds
wrote:
> On Tue, Nov 14, 2017 at 12:31 PM, Matthew Garrett wrote:
>>
>>> This is all theoretical security masturbation. The _real_ attacks have
>>> been elsewhere.
>>
>> People made the same argument
On Tue, Nov 14, 2017 at 12:31 PM, Matthew Garrett wrote:
>
>> This is all theoretical security masturbation. The _real_ attacks have
>> been elsewhere.
>
> People made the same argument about Secure Boot, and then we
> discovered that people *were* attacking the boot chain. As
On Tue, Nov 14, 2017 at 3:18 PM, Linus Torvalds
wrote:
> On Tue, Nov 14, 2017 at 11:58 AM, Matthew Garrett wrote:
>>
>> Our ability to determine that userland hasn't been tampered with
>> depends on the kernel being trustworthy. If userland can
On Tue, Nov 14, 2017 at 11:58 AM, Matthew Garrett wrote:
>
> Our ability to determine that userland hasn't been tampered with
> depends on the kernel being trustworthy. If userland can upload
> arbitrary firmware to DMA-capable devices then we can no longer trust
> the kernel.
On Tue, Nov 14, 2017 at 9:34 AM, Linus Torvalds
wrote:
> It's this insane "firmware is special" that I disagree with. It's not
> special at all.
Our ability to determine that userland hasn't been tampered with
depends on the kernel being trustworthy. If userland
On Tue, Nov 14, 2017 at 4:21 AM, Mimi Zohar wrote:
> On Mon, 2017-11-13 at 14:09 -0800, Linus Torvalds wrote:
>>
>> Seriously, if you have firmware in /lib/firmware, and you don't trust
>> it, what the hell are you doing?
>
> I might "trust" the files in /lib/firmware,
On Tue, 2017-11-14 at 13:38 +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 14, 2017 at 07:21:38AM -0500, Mimi Zohar wrote:
> > On Mon, 2017-11-13 at 14:09 -0800, Linus Torvalds wrote:
> > > On Mon, Nov 13, 2017 at 1:44 PM, David Howells
> > > wrote:
> > > >
> > > > Whilst
On Tue, Nov 14, 2017 at 07:21:38AM -0500, Mimi Zohar wrote:
> On Mon, 2017-11-13 at 14:09 -0800, Linus Torvalds wrote:
> > On Mon, Nov 13, 2017 at 1:44 PM, David Howells wrote:
> > >
> > > Whilst that may be true, we either have to check signatures on every bit
> > > of
> >
On Mon, 2017-11-13 at 14:09 -0800, Linus Torvalds wrote:
> On Mon, Nov 13, 2017 at 1:44 PM, David Howells wrote:
> >
> > Whilst that may be true, we either have to check signatures on every bit of
> > firmware that the appropriate driver doesn't say is meant to be signed or
On Mon, 13 Nov 2017 14:09:10 -0800
Linus Torvalds wrote:
> On Mon, Nov 13, 2017 at 1:44 PM, David Howells wrote:
> >
> > Whilst that may be true, we either have to check signatures on every bit of
> > firmware that the appropriate driver
On Mon, Nov 13, 2017 at 1:44 PM, David Howells wrote:
>
> Whilst that may be true, we either have to check signatures on every bit of
> firmware that the appropriate driver doesn't say is meant to be signed or not
> bother.
I vote for "not bother".
Seriously, if you have
Alan Cox wrote:
> So you don't actually need to sign a lot of PC class firmware because
> it's already signed.
Whilst that may be true, we either have to check signatures on every bit of
firmware that the appropriate driver doesn't say is meant to be signed or not
On Mon, 13 Nov 2017 18:42:50 +0100
"Luis R. Rodriguez" wrote:
> On Sat, Nov 11, 2017 at 02:32:40AM +, Alan Cox wrote:
> > > My assumption here is:
> > > 1) there are some less important and so security-insensitive firmwares,
> > >by which I mean that such firmwares
On Mon, Nov 13, 2017 at 07:50:35PM +0100, Luis R. Rodriguez wrote:
> On Fri, Nov 10, 2017 at 08:45:06AM -0500, Mimi Zohar wrote:
> It does not mean we don't have to support hashes from the start, we can,
> however that could require a driver change where its hash is specified or
> preferred, for
On Fri, Nov 10, 2017 at 08:45:06AM -0500, Mimi Zohar wrote:
> On Fri, 2017-11-10 at 02:46 +0100, Luis R. Rodriguez wrote:
> > On Thu, Nov 09, 2017 at 10:48:43AM +0900, AKASHI, Takahiro wrote:
> > > On Wed, Nov 08, 2017 at 08:46:26PM +0100, Luis R. Rodriguez wrote:
> > > > But perhaps I'm not
On Sat, Nov 11, 2017 at 02:32:40AM +, Alan Cox wrote:
> > My assumption here is:
> > 1) there are some less important and so security-insensitive firmwares,
> >by which I mean that such firmwares won't be expected to be signed in
> >terms of vulnerability or integrity.
> >(I can't
On Sat, 2017-11-11 at 02:32 +, Alan Cox wrote:
> > My assumption here is:
> > 1) there are some less important and so security-insensitive firmwares,
> >by which I mean that such firmwares won't be expected to be signed in
> >terms of vulnerability or integrity.
> >(I can't give
> My assumption here is:
> 1) there are some less important and so security-insensitive firmwares,
>by which I mean that such firmwares won't be expected to be signed in
>terms of vulnerability or integrity.
>(I can't give you examples though.)
> 2) firmware's signature will be
On Fri, 2017-11-10 at 02:46 +0100, Luis R. Rodriguez wrote:
> On Thu, Nov 09, 2017 at 10:48:43AM +0900, AKASHI, Takahiro wrote:
> > On Wed, Nov 08, 2017 at 08:46:26PM +0100, Luis R. Rodriguez wrote:
> > > But perhaps I'm not understanding the issue well, let me know.
> >
> > My point is quite
On Thu, 2017-11-09 at 13:46 +0900, AKASHI, Takahiro wrote:
> Mimi,
>
> On Wed, Nov 08, 2017 at 09:17:37PM -0500, Mimi Zohar wrote:
> > > > IMHO that should just fail then, ie, a "locked down" kernel should not
> > > > want to
> > > > *pass* a firmware signature if such thing could not be done.
>
On Thu, Nov 09, 2017 at 10:48:43AM +0900, AKASHI, Takahiro wrote:
> On Wed, Nov 08, 2017 at 08:46:26PM +0100, Luis R. Rodriguez wrote:
> > But perhaps I'm not understanding the issue well, let me know.
>
> My point is quite simple:
> my_deviceA_init() {
> err = request_firmware(,
Mimi,
On Wed, Nov 08, 2017 at 09:17:37PM -0500, Mimi Zohar wrote:
> > > IMHO that should just fail then, ie, a "locked down" kernel should not
> > > want to
> > > *pass* a firmware signature if such thing could not be done.
> > >
> > > Its no different than trying to verify a signed module on a
> > IMHO that should just fail then, ie, a "locked down" kernel should not want
> > to
> > *pass* a firmware signature if such thing could not be done.
> >
> > Its no different than trying to verify a signed module on a "locked down"
> > for
> > which it has no signature.
> >
> > But perhaps
On Wed, Nov 08, 2017 at 08:46:26PM +0100, Luis R. Rodriguez wrote:
> On Wed, Nov 08, 2017 at 03:15:54PM +0900, AKASHI, Takahiro wrote:
> > Luis,
> >
> > Thank you for this heads-up.
> >
> > On Wed, Nov 08, 2017 at 12:07:00AM +0100, Luis R. Rodriguez wrote:
> > > On Thu, Nov 02, 2017 at
On Wed, Nov 08, 2017 at 03:01:09PM -0500, Mimi Zohar wrote:
>
> > > Or reflect that IMA-appraisal, if enabled, will enforce firmware being
> > > validly signed.
> >
> > But FWICT lockdown is a built-in kernel thingy, unless lockdown implies IMA
> > it would not be the place to refer to it.
> >
> > Or reflect that IMA-appraisal, if enabled, will enforce firmware being
> > validly signed.
>
> But FWICT lockdown is a built-in kernel thingy, unless lockdown implies IMA
> it would not be the place to refer to it.
>
> It seems the documentation was proposed to help users if an error was
On Wed, Nov 08, 2017 at 03:15:54PM +0900, AKASHI, Takahiro wrote:
> Luis,
>
> Thank you for this heads-up.
>
> On Wed, Nov 08, 2017 at 12:07:00AM +0100, Luis R. Rodriguez wrote:
> > On Thu, Nov 02, 2017 at 06:10:41PM -0400, Mimi Zohar wrote:
> > > On Thu, 2017-11-02 at 22:04 +, David Howells
Luis,
Thank you for this heads-up.
On Wed, Nov 08, 2017 at 12:07:00AM +0100, Luis R. Rodriguez wrote:
> On Thu, Nov 02, 2017 at 06:10:41PM -0400, Mimi Zohar wrote:
> > On Thu, 2017-11-02 at 22:04 +, David Howells wrote:
> > > Mimi Zohar wrote:
> > >
> > > > > Only
On Thu, Nov 02, 2017 at 06:10:41PM -0400, Mimi Zohar wrote:
> On Thu, 2017-11-02 at 22:04 +, David Howells wrote:
> > Mimi Zohar wrote:
> >
> > > > Only validly signed device firmware may be loaded.
> > >
> > > fw_get_filesystem_firmware() calls
On Thu, 2017-11-02 at 22:04 +, David Howells wrote:
> Mimi Zohar wrote:
>
> > > Only validly signed device firmware may be loaded.
> >
> > fw_get_filesystem_firmware() calls kernel_read_file_from_path() to
> > read the firmware, which calls into the security hooks.
Mimi Zohar wrote:
> > Only validly signed device firmware may be loaded.
>
> fw_get_filesystem_firmware() calls kernel_read_file_from_path() to
> read the firmware, which calls into the security hooks. Is there
> another place that validates the firmware signatures.
46 matches
Mail list logo