> One is to get more and more folks reverse engineer firmware. This won't help
> if you can't deploy unsigned firmware though. But you have to also look at it
Oh I think it will. From the experience with things like games consoles
most firmware is such a complete pile of s**t that you'll be able t
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 k
> 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 "firmwa
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 security-insensitive firmwares
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, Luis
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 signatur
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
>> use of PCR7 is a good example of how s
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 anything,
> > > since the measurements of wha
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
>> signatures make it a lot easier, since
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
> > > have been elsewhere.
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 this, in terms of
> just
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 about Secure Boot, and then we
>> discovered that
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 we secure
> other co
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 upload
>> arbitrary firmware to DMA-capable devices
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. So yes, firmware is
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 can upload
arbitrary firmware to D
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, but I also want to make
> su
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 that may be true, we eit
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
> > > firmware that the ap
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
> > not
> > bother.
>
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 doesn't say is meant to be signed or
> > not
> > bother.
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 firmware in /lib/firmwar
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
bother.
David
--
To unsubscrib
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 won't be expected to be
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 in
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 unders
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 g
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 you
> 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 presente
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 simp
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(&fw, "devic
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 I'
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 06:10:41PM
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 cau
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 validly signed device firm
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 kernel_read_file_from_path() to
> > > read the
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. Is there
> > another place
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. I'm not seeing
> which patch
Hi David,
>From the man page:
> Only validly signed modules may be loaded.
> .P
> Only validly signed binaries may be kexec'd.
> .P
> 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 secu
I've pushed a new version to git that fixes bugs in patches 1 and 2.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Here's a set of patches to institute a "locked-down mode" in the kernel and
to trigger that mode if the kernel is booted in secure-boot mode or through
the command line.
Enabling CONFIG_LOCK_DOWN_KERNEL makes lockdown mode available.
Enabling CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ will allow a SysR
50 matches
Mail list logo