於 三，2012-10-31 於 19:53 +0100，Takashi Iwai 提到：
> At Wed, 31 Oct 2012 17:37:28 +,
> Matthew Garrett wrote:
> >
> > On Wed, Oct 31, 2012 at 06:28:16PM +0100, Takashi Iwai wrote:
> >
> > > request_firmware() is used for microcode loading, too, so it's fairly
> > > a core part to cover, I'm afraid
On Wednesday 31 October 2012 15:58:05 Chris Friesen wrote:
> On 10/31/2012 02:14 PM, Oliver Neukum wrote:
> > That would do it on my system.
> > Maybe in theory you could solve this by the kernel invalidating images
> > it hasn't written itself and forbidding to change the resume partition from
>
On 10/31/2012 02:14 PM, Oliver Neukum wrote:
On Wednesday 31 October 2012 17:39:19 Alan Cox wrote:
On Wed, 31 Oct 2012 17:17:43 +
Matthew Garrett wrote:
On Wed, Oct 31, 2012 at 05:21:21PM +, Alan Cox wrote:
On Wed, 31 Oct 2012 17:10:48 +
Matthew Garrett wrote:
The kernel is sig
On Wed, 31 Oct 2012, Chris Friesen wrote:
> > That would do it on my system.
> > Maybe in theory you could solve this by the kernel invalidating images
> > it hasn't written itself and forbidding to change the resume partition from
> > the
> > kernel command line, but that would break user space h
On Wednesday 31 October 2012 17:39:19 Alan Cox wrote:
> On Wed, 31 Oct 2012 17:17:43 +
> Matthew Garrett wrote:
>
> > On Wed, Oct 31, 2012 at 05:21:21PM +, Alan Cox wrote:
> > > On Wed, 31 Oct 2012 17:10:48 +
> > > Matthew Garrett wrote:
> > > > The kernel is signed. The kernel doesn
At Wed, 31 Oct 2012 17:37:28 +,
Matthew Garrett wrote:
>
> On Wed, Oct 31, 2012 at 06:28:16PM +0100, Takashi Iwai wrote:
>
> > request_firmware() is used for microcode loading, too, so it's fairly
> > a core part to cover, I'm afraid.
> >
> > I played a bit about this yesterday. The patch b
On Wed, Oct 31, 2012 at 05:49:19PM +, Alan Cox wrote:
> On Wed, 31 Oct 2012 17:37:50 +
> Matthew Garrett wrote:
> > What S4 resume check?
>
> One you would add .. but no I'm wrong there - its a problem at the
> suspend point so you do need a signature for it. Oh well yet another
> reason
On Wed, Oct 31, 2012 at 05:44:40PM +, Alan Cox wrote:
> > That does still leave me a little uneasy as far as the microcode
> > licenses go. I don't know that we can distribute signed copies of some
> > of them, and we obviously can't sign at the user end.
>
> You seem to put them in signed r
On Wed, 31 Oct 2012 17:37:50 +
Matthew Garrett wrote:
> On Wed, Oct 31, 2012 at 05:39:19PM +, Alan Cox wrote:
> > On Wed, 31 Oct 2012 17:17:43 +
> > Matthew Garrett wrote:
> > > By booting a signed kernel, not turning on swap and writing directly to
> > > the swap partition.
> >
>
> That does still leave me a little uneasy as far as the microcode
> licenses go. I don't know that we can distribute signed copies of some
> of them, and we obviously can't sign at the user end.
You seem to put them in signed rpm packages ?
--
To unsubscribe from this list: send the line "uns
On Wed, Oct 31, 2012 at 05:39:19PM +, Alan Cox wrote:
> On Wed, 31 Oct 2012 17:17:43 +
> Matthew Garrett wrote:
> > By booting a signed kernel, not turning on swap and writing directly to
> > the swap partition.
>
> Ok so the actual problem is that you are signing kernels that allow the
On Wed, Oct 31, 2012 at 06:28:16PM +0100, Takashi Iwai wrote:
> request_firmware() is used for microcode loading, too, so it's fairly
> a core part to cover, I'm afraid.
>
> I played a bit about this yesterday. The patch below is a proof of
> concept to (ab)use the module signing mechanism for f
On Wed, 31 Oct 2012 17:17:43 +
Matthew Garrett wrote:
> On Wed, Oct 31, 2012 at 05:21:21PM +, Alan Cox wrote:
> > On Wed, 31 Oct 2012 17:10:48 +
> > Matthew Garrett wrote:
> > > The kernel is signed. The kernel doesn't check the signature on the
> > > suspend image.
> >
> > Which d
At Mon, 29 Oct 2012 17:41:31 +,
Matthew Garrett wrote:
>
> On Mon, Oct 29, 2012 at 08:49:41AM +0100, Jiri Kosina wrote:
> > On Thu, 20 Sep 2012, Matthew Garrett wrote:
> >
> > > This is pretty much identical to the first patchset, but with the
> > > capability
> > > renamed (CAP_COMPROMISE_K
On Wed, 31 Oct 2012, Alan Cox wrote:
> > > > Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
> > > > from that artificial image.
> > >
> > > It's not signed. It won't reboot from that image.
> >
> > The kernel is signed. The kernel doesn't check the signature on the
> >
On Wed, Oct 31, 2012 at 05:21:21PM +, Alan Cox wrote:
> On Wed, 31 Oct 2012 17:10:48 +
> Matthew Garrett wrote:
> > The kernel is signed. The kernel doesn't check the signature on the
> > suspend image.
>
> Which doesn't matter. How are you going to create the tampered image in
> the fir
On Wed, 31 Oct 2012 17:10:48 +
Matthew Garrett wrote:
> On Wed, Oct 31, 2012 at 05:03:34PM +, Alan Cox wrote:
> > On Wed, 31 Oct 2012 16:55:04 +0100 (CET)
> > Jiri Kosina wrote:
> > > Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
> > > from that artificial imag
> >> Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
> >> from that artificial image.
> > It's not signed. It won't reboot from that image.
>
> So then to hibernate the kernel must have a signing key?
No.
If you break the kernel so you can patch swap we already lost.
If
On Wed, Oct 31, 2012 at 05:03:34PM +, Alan Cox wrote:
> On Wed, 31 Oct 2012 16:55:04 +0100 (CET)
> Jiri Kosina wrote:
> > Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
> > from that artificial image.
>
> It's not signed. It won't reboot from that image.
The kernel
On 10/31/2012 01:08 PM, Alan Cox wrote:
On Wed, 31 Oct 2012 15:56:35 +
Matthew Garrett wrote:
1) Gain root.
2) Modify swap partition directly.
3) Force reboot.
4) Win.
Root should not have the ability to elevate themselves to running
arbitrary kernel code. Therefore, the above attack need
On Wed, 31 Oct 2012 15:56:35 +
Matthew Garrett wrote:
> 1) Gain root.
> 2) Modify swap partition directly.
> 3) Force reboot.
> 4) Win.
>
> Root should not have the ability to elevate themselves to running
> arbitrary kernel code. Therefore, the above attack needs to be
> impossible.
To p
On 10/31/2012 01:03 PM, Alan Cox wrote:
On Wed, 31 Oct 2012 16:55:04 +0100 (CET)
Jiri Kosina wrote:
On Wed, 31 Oct 2012, Alan Cox wrote:
All this depends on your threat model. If I have physical access to
suspend/resume your machine then you already lost. If I don't have
physical access then
On Wed, 31 Oct 2012 16:55:04 +0100 (CET)
Jiri Kosina wrote:
> On Wed, 31 Oct 2012, Alan Cox wrote:
>
> > All this depends on your threat model. If I have physical access to
> > suspend/resume your machine then you already lost. If I don't have
> > physical access then I can't boot my unsigned OS
On Wed, Oct 31, 2012 at 12:04 PM, Jiri Kosina wrote:
> On Wed, 31 Oct 2012, Josh Boyer wrote:
>
>> I have a patch that disables that. I imagine it will be included in the
>> next submission of the patchset.
>>
>> You can find it here in the meantime:
>>
>> http://jwboyer.fedorapeople.org/pub/0001
On Wed, 31 Oct 2012, Josh Boyer wrote:
> I have a patch that disables that. I imagine it will be included in the
> next submission of the patchset.
>
> You can find it here in the meantime:
>
> http://jwboyer.fedorapeople.org/pub/0001-hibernate-Disable-in-a-Secure-Boot-environment.patch
I don'
1) Gain root.
2) Modify swap partition directly.
3) Force reboot.
4) Win.
Root should not have the ability to elevate themselves to running
arbitrary kernel code. Therefore, the above attack needs to be
impossible.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send
On Wed, 31 Oct 2012, Alan Cox wrote:
> All this depends on your threat model. If I have physical access to
> suspend/resume your machine then you already lost. If I don't have
> physical access then I can't boot my unsigned OS to patch your S4 image
> so it doesn't matter.
Prepare (as a root) a h
> > is basically DMA-ing arbitrary data over the whole RAM. I am currently not
> > able to imagine a scenario how this could be made "secure" (without
> > storing private keys to sign the hibernation image on the machine itself
> > which, well, doesn't sound secure either).
That's what the TPM is
On Wed, Oct 31, 2012 at 11:05:08AM -0400, Shea Levy wrote:
> Or the boot variable where you stored the key, but in that case I'd
> say the attacker has won too.
Right, in that case they can compromise MOK.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "
On 10/31/2012 11:02 AM, Matthew Garrett wrote:
On Wed, Oct 31, 2012 at 03:50:00PM +0100, Jiri Kosina wrote:
Reading stored memory image (potentially tampered before reboot) from disk
is basically DMA-ing arbitrary data over the whole RAM. I am currently not
able to imagine a scenario how this c
On Wed, Oct 31, 2012 at 03:50:00PM +0100, Jiri Kosina wrote:
> Reading stored memory image (potentially tampered before reboot) from disk
> is basically DMA-ing arbitrary data over the whole RAM. I am currently not
> able to imagine a scenario how this could be made "secure" (without
> storing
On 10/31/2012 10:54 AM, Josh Boyer wrote:
On Wed, Oct 31, 2012 at 10:50 AM, Jiri Kosina wrote:
On Mon, 29 Oct 2012, Matthew Garrett wrote:
This is pretty much identical to the first patchset, but with the capability
renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants
On Wed, Oct 31, 2012 at 10:50 AM, Jiri Kosina wrote:
> On Mon, 29 Oct 2012, Matthew Garrett wrote:
>
>> > > This is pretty much identical to the first patchset, but with the
>> > > capability
>> > > renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone
>> > > wants
>> > > to dep
On Mon, 29 Oct 2012, Matthew Garrett wrote:
> > > This is pretty much identical to the first patchset, but with the
> > > capability
> > > renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone
> > > wants
> > > to deploy these then they should disable kexec until support for sig
On Mon, 2012-10-29 at 10:21 +0800, joeyli wrote:
> I tested this patch on my UEFI notebook with latest EFI kernel git tree,
> the efivarfs mounted normally after system boot and I can delete/add EFI
> variable through /sys/firmware/efi/efivars.
This causes systemd to output a warning if the kerne
On Wed, Oct 31, 2012 at 2:04 PM, Colin Walters wrote:
> On Mon, 2012-10-29 at 10:21 +0800, joeyli wrote:
>
>> I tested this patch on my UEFI notebook with latest EFI kernel git tree,
>> the efivarfs mounted normally after system boot and I can delete/add EFI
>> variable through /sys/firmware/efi/e
36 matches
Mail list logo
