On Wed, 25 Sep 2013, James Bottomley wrote:
> > I don't get this. Why is it important that current kernel can't
> > recreate the signature?
>
> The thread model is an attack on the saved information (i.e. the suspend
> image) between it being saved by the old kernel and used by the new one.
> The
於 四，2013-09-26 於 02:27 +0200，Pavel Machek 提到：
> On Wed 2013-09-25 15:16:54, James Bottomley wrote:
> > On Wed, 2013-09-25 at 17:25 -0400, Alan Stern wrote:
> > > On Wed, 25 Sep 2013, David Howells wrote:
> > >
> > > > I have pushed some keyrings patches that will likely affect this to:
> > > >
>
On 09/24/13 at 05:12pm, H. Peter Anvin wrote:
> On 09/24/2013 07:56 AM, Borislav Petkov wrote:
> > On Tue, September 24, 2013 2:45 pm, Dave Young wrote:
> >> Think again about this, how about 1:1 map them from a base address
> >> like -64G phy_addr -> (-64G + phy_addr), in this way we can avoid
> >
On Thu, 2013-09-26 at 02:27 +0200, Pavel Machek wrote:
> On Wed 2013-09-25 15:16:54, James Bottomley wrote:
> > On Wed, 2013-09-25 at 17:25 -0400, Alan Stern wrote:
> > > On Wed, 25 Sep 2013, David Howells wrote:
> > >
> > > > I have pushed some keyrings patches that will likely affect this to:
>
於 三，2013-09-25 於 17:25 -0400，Alan Stern 提到：
> On Wed, 25 Sep 2013, David Howells wrote:
>
> > I have pushed some keyrings patches that will likely affect this to:
> >
> >
> > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
> >
> > I intend to ask James to
於 三，2013-09-18 於 15:45 +0200，Pavel Machek 提到：
> On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote:
> > This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> > hash algorithm will be used during signature generation of snapshot.
>
> This series is big enough already... and who is g
於 三，2013-09-25 於 22:04 +0100，David Howells 提到：
> I have pushed some keyrings patches that will likely affect this to:
>
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
>
Thanks for your point out, I will respin my asymmetric keys patch base
on this
On Wed, 25 Sep 2013, James Bottomley wrote:
> > Why are asymmetric keys used for verifying the hibernation image? It
> > seems that a symmetric key would work just as well. And it would be a
> > lot quicker to generate, because it wouldn't need any high-precision
> > integer computations.
>
> T
On Wed 2013-09-25 15:16:54, James Bottomley wrote:
> On Wed, 2013-09-25 at 17:25 -0400, Alan Stern wrote:
> > On Wed, 25 Sep 2013, David Howells wrote:
> >
> > > I have pushed some keyrings patches that will likely affect this to:
> > >
> > >
> > > http://git.kernel.org/cgit/linux/kernel/git/d
On Wed, Sep 25, 2013 at 01:58:40PM +0100, Matt Fleming wrote:
> On Sun, 22 Sep, at 07:59:08PM, Linn Crosetto wrote:
> > This patch fixes a problem with EFI memory maps larger than 128 entries
> > when booting using the EFI stub, which results in overflowing e820_map
> > in boot_params and an eventu
On Wed, 2013-09-25 at 17:25 -0400, Alan Stern wrote:
> On Wed, 25 Sep 2013, David Howells wrote:
>
> > I have pushed some keyrings patches that will likely affect this to:
> >
> >
> > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
> >
> > I intend to ask
On Wed, 25 Sep 2013, David Howells wrote:
> I have pushed some keyrings patches that will likely affect this to:
>
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
>
> I intend to ask James to pull these into his next branch. If he's happy to do
> s
I have pushed some keyrings patches that will likely affect this to:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel
I intend to ask James to pull these into his next branch. If he's happy to do
so, I can look at pulling at least your asymmetric keys
On Wed, Sep 25, 2013 at 5:01 AM, Matt Fleming wrote:
> On Sun, 22 Sep, at 05:24:28PM, H. Peter Anvin wrote:
>> On 09/22/2013 04:07 PM, Roy Franz wrote:
>> > On Sun, Sep 22, 2013 at 3:54 PM, H. Peter Anvin wrote:
>> >> Sorry this version is broken and doesn't even compile due to remaining
>> >> o
On Mon, 23 Sep, at 11:45:28AM, Bart Kuivenhoven wrote:
> The problem in efi_main was that the idt was cleared before the
> interrupts were disabled.
>
> The UEFI spec states that interrupts aren't used so this shouldn't be
> too much of a problem. Peripherals however don't necessarily know about
>
On Sun, 22 Sep, at 07:59:08PM, Linn Crosetto wrote:
> This patch fixes a problem with EFI memory maps larger than 128 entries
> when booting using the EFI stub, which results in overflowing e820_map
> in boot_params and an eventual halt when checking the map size in
> sanitize_e820_map().
>
> If t
On Wed, 25 Sep, at 01:11:20PM, Matt Fleming wrote:
> At the request of Grant, the patches series from both Roy and Leif are
> available in a clean branch with a linear history at 'efi-arm', which is
> based on v3.11. Grant, feel free to pull that branch into wherever it is
> required.
... but ple
On Sun, 22 Sep, at 03:45:24PM, Roy Franz wrote:
> This patch is the common/x86 portion of the ARM EFI stub
> patchset broken out. These changes support the addition
> of EFI stub support for the ARM and ARM64 architectures.
> The common code that is now shared in efi-stub-helper.c
> is based on co
On Sun, 22 Sep, at 03:45:30PM, Roy Franz wrote:
> The efi_high_alloc() and efi_low_alloc() functions
> use the EFI_ALLOCATE_ADDRESS option to the EFI
> function allocate_pages(), which requires a minimum
> of page alignment, and rejects all other requests.
> The existing code could fail to allocate
On Sun, 22 Sep, at 03:45:33PM, Roy Franz wrote:
> Move the open-coded conversion to a shared function for
> use by all architectures. Change the allocation to prefer
> a high address for ARM, as this is required to avoid conflicts
> with reserved regions in low memory. We don't know the specifics
On Sun, 22 Sep, at 03:45:32PM, Roy Franz wrote:
> Rename relocate_kernel() to efi_relocate_kernel(), and take
> parameters rather than x86 specific structure. Add max_addr
> argument as for ARM we have some address constraints that we
> need to enforce when relocating the kernel. Add alloc_size
>
On Sun, 22 Sep, at 05:24:28PM, H. Peter Anvin wrote:
> On 09/22/2013 04:07 PM, Roy Franz wrote:
> > On Sun, Sep 22, 2013 at 3:54 PM, H. Peter Anvin wrote:
> >> Sorry this version is broken and doesn't even compile due to remaining
> >> options_size references.
> >
> > I compiled and tested this
On Sat, September 21, 2013 1:39 pm, Borislav Petkov wrote:
> diff --git a/arch/x86/platform/efi/efi_32.c
> b/arch/x86/platform/efi/efi_32.c
> index 40e446941dd7..661663b08eaf 100644
> --- a/arch/x86/platform/efi/efi_32.c
> +++ b/arch/x86/platform/efi/efi_32.c
> @@ -37,9 +37,36 @@
> * claim EFI ru
23 matches
Mail list logo
