On Thu, Dec 6, 2012 at 11:54 AM, Matthew Garrett wrote:
> On Thu, Dec 06, 2012 at 10:26:01AM -0800, H. Peter Anvin wrote:
>
>> NAK on this bit:
>>
>> + if (boot_params.hdr.version < 0x0209)
>> + return 0;
>>
>> This field is kernel->bootloader documentation. If a nonmaching
On Thu, Dec 6, 2012 at 10:54 AM, Matthew Garrett wrote:
> On Thu, Dec 06, 2012 at 10:26:01AM -0800, H. Peter Anvin wrote:
>
>> NAK on this bit:
>>
>> + if (boot_params.hdr.version < 0x0209)
>> + return 0;
>>
>> This field is kernel->bootloader documentation. If a nonmaching
On Thu, Dec 06, 2012 at 10:26:01AM -0800, H. Peter Anvin wrote:
> NAK on this bit:
>
> + if (boot_params.hdr.version < 0x0209)
> + return 0;
>
> This field is kernel->bootloader documentation. If a nonmaching
> value somehow leaks into the kernel, the kernel could either
>
On 12/06/2012 10:19 AM, Bjorn Helgaas wrote:
On Wed, Dec 5, 2012 at 5:52 PM, Yinghai Lu wrote:
On Wed, Dec 5, 2012 at 4:51 PM, Yinghai Lu wrote:
On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin wrote:
On 12/05/2012 04:15 PM, Yinghai Lu wrote:
I don't see why that isn't the right fix. We
On Wed, Dec 5, 2012 at 5:52 PM, Yinghai Lu wrote:
> On Wed, Dec 5, 2012 at 4:51 PM, Yinghai Lu wrote:
>> On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin wrote:
>>> On 12/05/2012 04:15 PM, Yinghai Lu wrote:
>>>
>>> I don't see why that isn't the right fix. We copy the data into
>>>
On Wed, Dec 5, 2012 at 5:52 PM, Yinghai Lu ying...@kernel.org wrote:
On Wed, Dec 5, 2012 at 4:51 PM, Yinghai Lu ying...@kernel.org wrote:
On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/05/2012 04:15 PM, Yinghai Lu wrote:
I don't see why that isn't the right fix.
On 12/06/2012 10:19 AM, Bjorn Helgaas wrote:
On Wed, Dec 5, 2012 at 5:52 PM, Yinghai Lu ying...@kernel.org wrote:
On Wed, Dec 5, 2012 at 4:51 PM, Yinghai Lu ying...@kernel.org wrote:
On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/05/2012 04:15 PM, Yinghai Lu wrote:
On Thu, Dec 06, 2012 at 10:26:01AM -0800, H. Peter Anvin wrote:
NAK on this bit:
+ if (boot_params.hdr.version 0x0209)
+ return 0;
This field is kernel-bootloader documentation. If a nonmaching
value somehow leaks into the kernel, the kernel could either
On Thu, Dec 6, 2012 at 10:54 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, Dec 06, 2012 at 10:26:01AM -0800, H. Peter Anvin wrote:
NAK on this bit:
+ if (boot_params.hdr.version 0x0209)
+ return 0;
This field is kernel-bootloader documentation. If a
On Thu, Dec 6, 2012 at 11:54 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, Dec 06, 2012 at 10:26:01AM -0800, H. Peter Anvin wrote:
NAK on this bit:
+ if (boot_params.hdr.version 0x0209)
+ return 0;
This field is kernel-bootloader documentation. If a
On Wed, Dec 05, 2012 at 05:21:44PM -0800, H. Peter Anvin wrote:
> On 12/05/2012 05:13 PM, Matthew Garrett wrote:
> >Yeah, it needs to be hidden from root - but ideally we'd be passing it to
> >the second kernel if we kexec. Alternative would be for it to be capability
> >bounded to a trusted
On 12/05/2012 05:13 PM, Matthew Garrett wrote:
"H. Peter Anvin" wrote:
And that presumably would be something that cannot be exposed to root?
If so we may want to use one of the bits in the setup_data type field
as
a security flag, perhaps...
Yeah, it needs to be hidden from root - but
"H. Peter Anvin" wrote:
>And that presumably would be something that cannot be exposed to root?
>If so we may want to use one of the bits in the setup_data type field
>as
>a security flag, perhaps...
Yeah, it needs to be hidden from root - but ideally we'd be passing it to the
second kernel
On 12/05/2012 04:57 PM, Matthew Garrett wrote:
>
>
> "H. Peter Anvin" wrote:
>
>> I don't think there is anything security-sensitive about that
>> information, at least not to root. I could be wrong, of course; I
>> wouldn't mind security people telling me about that.
>
> I don't think
"H. Peter Anvin" wrote:
>Because it also needs to modify it. Right now kexec userspace
>synthesizes struct boot_params from scratch, and does so incorrectly to
>boot. I think we have setup_data exported via debugfs but IIRC we
>never
>got a strong enough use case for sysfs.
Kexec userspace
"H. Peter Anvin" wrote:
>I don't think there is anything security-sensitive about that
>information, at least not to root. I could be wrong, of course; I
>wouldn't mind security people telling me about that.
I don't think there's anything at present, but we'll want to pass the
hibernation
On 12/05/2012 04:51 PM, Yinghai Lu wrote:
>
> it moves boot_params from __initdata to data.
> and just for using pointer to setup_data.
>
> should add setup_data pointer instead. so will not waste (4096 - 8) bytes.
>
That is not the only bit. We already have covered how kexec could use
the
On Wed, Dec 5, 2012 at 4:51 PM, Yinghai Lu wrote:
> On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin wrote:
>> On 12/05/2012 04:15 PM, Yinghai Lu wrote:
>>>
>>
>> I don't see why that isn't the right fix. We copy the data into
>> boot_params early in the boot; that *is* the official copy as far
On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin wrote:
> On 12/05/2012 04:15 PM, Yinghai Lu wrote:
>>
>
> I don't see why that isn't the right fix. We copy the data into
> boot_params early in the boot; that *is* the official copy as far as the
> kernel is concerned.
>
> So this patch very much
On 12/05/2012 04:30 PM, Yinghai Lu wrote:
> On Wed, Dec 5, 2012 at 4:21 PM, H. Peter Anvin wrote:
>> On 12/05/2012 04:18 PM, Matthew Garrett wrote:
>
>> Because it also needs to modify it. Right now kexec userspace
>> synthesizes struct boot_params from scratch, and does so incorrectly to
>>
On 12/05/2012 04:15 PM, Yinghai Lu wrote:
>
> -#ifndef CONFIG_DEBUG_BOOT_PARAMS
> -struct boot_params __initdata boot_params;
> -#else
> struct boot_params boot_params;
> -#endif
>
> No, that is not a right fix
>
> We should only cache pointer to setup_data.
>
> at the same time we should
On Wed, Dec 5, 2012 at 4:21 PM, H. Peter Anvin wrote:
> On 12/05/2012 04:18 PM, Matthew Garrett wrote:
> Because it also needs to modify it. Right now kexec userspace
> synthesizes struct boot_params from scratch, and does so incorrectly to
> boot. I think we have setup_data exported via
Matthew Garrett writes:
> On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
>
>> at the same time we should export setup_data into /sys, so kexec could
>> append this pointer to command of
>> second kernel, just like kexec append acpi_rsdp.
>> That should address DavidW's concern.
>
>
On Wed, Dec 5, 2012 at 4:18 PM, Matthew Garrett wrote:
> On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
>
>> at the same time we should export setup_data into /sys, so kexec could
>> append this pointer to command of
>> second kernel, just like kexec append acpi_rsdp.
>> That should
On 12/05/2012 04:18 PM, Matthew Garrett wrote:
> On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
>
>> at the same time we should export setup_data into /sys, so kexec could
>> append this pointer to command of
>> second kernel, just like kexec append acpi_rsdp.
>> That should address
On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
> at the same time we should export setup_data into /sys, so kexec could
> append this pointer to command of
> second kernel, just like kexec append acpi_rsdp.
> That should address DavidW's concern.
Why should the kernel export data to
On Mon, Dec 3, 2012 at 12:02 PM, Seth Forshee
wrote:
> On Thu, Oct 25, 2012 at 11:35:57AM -0600, Bjorn Helgaas wrote:
>> On Thu, Aug 23, 2012 at 10:36 AM, Matthew Garrett wrote:
>> > V3 just fixes all the casting issues and incorporates David's change in
>> > search ordering.
>>
>> I think
On Wed, Dec 5, 2012 at 1:22 PM, Matthew Garrett wrote:
> On Wed, Dec 05, 2012 at 01:09:25PM -0700, Bjorn Helgaas wrote:
>
>> That's right; nobody stepped up to fix the section mismatch. I'm
>> happy to fold in your fix, especially if Matthew acks it.
>
> Yes, sorry, I've been way behind on
On Wed, 2012-12-05 at 13:09 -0700, Bjorn Helgaas wrote:
>
> David, Eric, what about the kexec question? It looks to me like this
> wouldn't make things worse than they are today. If I understand
> correctly, today we don't use ROM data from EFI on either an initial
> boot or a kexec. After
On Wed, Dec 05, 2012 at 01:09:25PM -0700, Bjorn Helgaas wrote:
> That's right; nobody stepped up to fix the section mismatch. I'm
> happy to fold in your fix, especially if Matthew acks it.
Yes, sorry, I've been way behind on pretty much everything for the past
few months. Please do add my
On Mon, Dec 3, 2012 at 1:02 PM, Seth Forshee wrote:
> On Thu, Oct 25, 2012 at 11:35:57AM -0600, Bjorn Helgaas wrote:
>> On Thu, Aug 23, 2012 at 10:36 AM, Matthew Garrett wrote:
>> > V3 just fixes all the casting issues and incorporates David's change in
>> > search ordering.
>>
>> I think
On Mon, Dec 3, 2012 at 1:02 PM, Seth Forshee seth.fors...@canonical.com wrote:
On Thu, Oct 25, 2012 at 11:35:57AM -0600, Bjorn Helgaas wrote:
On Thu, Aug 23, 2012 at 10:36 AM, Matthew Garrett m...@redhat.com wrote:
V3 just fixes all the casting issues and incorporates David's change in
On Wed, Dec 05, 2012 at 01:09:25PM -0700, Bjorn Helgaas wrote:
That's right; nobody stepped up to fix the section mismatch. I'm
happy to fold in your fix, especially if Matthew acks it.
Yes, sorry, I've been way behind on pretty much everything for the past
few months. Please do add my Ack.
On Wed, 2012-12-05 at 13:09 -0700, Bjorn Helgaas wrote:
David, Eric, what about the kexec question? It looks to me like this
wouldn't make things worse than they are today. If I understand
correctly, today we don't use ROM data from EFI on either an initial
boot or a kexec. After this
On Wed, Dec 5, 2012 at 1:22 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Wed, Dec 05, 2012 at 01:09:25PM -0700, Bjorn Helgaas wrote:
That's right; nobody stepped up to fix the section mismatch. I'm
happy to fold in your fix, especially if Matthew acks it.
Yes, sorry, I've been way
On Mon, Dec 3, 2012 at 12:02 PM, Seth Forshee
seth.fors...@canonical.com wrote:
On Thu, Oct 25, 2012 at 11:35:57AM -0600, Bjorn Helgaas wrote:
On Thu, Aug 23, 2012 at 10:36 AM, Matthew Garrett m...@redhat.com wrote:
V3 just fixes all the casting issues and incorporates David's change in
On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
at the same time we should export setup_data into /sys, so kexec could
append this pointer to command of
second kernel, just like kexec append acpi_rsdp.
That should address DavidW's concern.
Why should the kernel export data to
On 12/05/2012 04:18 PM, Matthew Garrett wrote:
On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
at the same time we should export setup_data into /sys, so kexec could
append this pointer to command of
second kernel, just like kexec append acpi_rsdp.
That should address DavidW's
On Wed, Dec 5, 2012 at 4:18 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
at the same time we should export setup_data into /sys, so kexec could
append this pointer to command of
second kernel, just like kexec append acpi_rsdp.
Matthew Garrett mj...@srcf.ucam.org writes:
On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
at the same time we should export setup_data into /sys, so kexec could
append this pointer to command of
second kernel, just like kexec append acpi_rsdp.
That should address DavidW's
On Wed, Dec 5, 2012 at 4:21 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/05/2012 04:18 PM, Matthew Garrett wrote:
Because it also needs to modify it. Right now kexec userspace
synthesizes struct boot_params from scratch, and does so incorrectly to
boot. I think we have setup_data exported
On 12/05/2012 04:15 PM, Yinghai Lu wrote:
-#ifndef CONFIG_DEBUG_BOOT_PARAMS
-struct boot_params __initdata boot_params;
-#else
struct boot_params boot_params;
-#endif
No, that is not a right fix
We should only cache pointer to setup_data.
at the same time we should export
On 12/05/2012 04:30 PM, Yinghai Lu wrote:
On Wed, Dec 5, 2012 at 4:21 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/05/2012 04:18 PM, Matthew Garrett wrote:
Because it also needs to modify it. Right now kexec userspace
synthesizes struct boot_params from scratch, and does so incorrectly to
On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/05/2012 04:15 PM, Yinghai Lu wrote:
I don't see why that isn't the right fix. We copy the data into
boot_params early in the boot; that *is* the official copy as far as the
kernel is concerned.
So this patch very
On Wed, Dec 5, 2012 at 4:51 PM, Yinghai Lu ying...@kernel.org wrote:
On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/05/2012 04:15 PM, Yinghai Lu wrote:
I don't see why that isn't the right fix. We copy the data into
boot_params early in the boot; that *is* the
On 12/05/2012 04:51 PM, Yinghai Lu wrote:
it moves boot_params from __initdata to data.
and just for using pointer to setup_data.
should add setup_data pointer instead. so will not waste (4096 - 8) bytes.
That is not the only bit. We already have covered how kexec could use
the whole
H. Peter Anvin h...@zytor.com wrote:
I don't think there is anything security-sensitive about that
information, at least not to root. I could be wrong, of course; I
wouldn't mind security people telling me about that.
I don't think there's anything at present, but we'll want to pass the
H. Peter Anvin h...@zytor.com wrote:
Because it also needs to modify it. Right now kexec userspace
synthesizes struct boot_params from scratch, and does so incorrectly to
boot. I think we have setup_data exported via debugfs but IIRC we
never
got a strong enough use case for sysfs.
Kexec
On 12/05/2012 04:57 PM, Matthew Garrett wrote:
H. Peter Anvin h...@zytor.com wrote:
I don't think there is anything security-sensitive about that
information, at least not to root. I could be wrong, of course; I
wouldn't mind security people telling me about that.
I don't think
H. Peter Anvin h...@zytor.com wrote:
And that presumably would be something that cannot be exposed to root?
If so we may want to use one of the bits in the setup_data type field
as
a security flag, perhaps...
Yeah, it needs to be hidden from root - but ideally we'd be passing it to the
second
On 12/05/2012 05:13 PM, Matthew Garrett wrote:
H. Peter Anvin h...@zytor.com wrote:
And that presumably would be something that cannot be exposed to root?
If so we may want to use one of the bits in the setup_data type field
as
a security flag, perhaps...
Yeah, it needs to be hidden from
On Wed, Dec 05, 2012 at 05:21:44PM -0800, H. Peter Anvin wrote:
On 12/05/2012 05:13 PM, Matthew Garrett wrote:
Yeah, it needs to be hidden from root - but ideally we'd be passing it to
the second kernel if we kexec. Alternative would be for it to be capability
bounded to a trusted signed
On Thu, Oct 25, 2012 at 11:35:57AM -0600, Bjorn Helgaas wrote:
> On Thu, Aug 23, 2012 at 10:36 AM, Matthew Garrett wrote:
> > V3 just fixes all the casting issues and incorporates David's change in
> > search ordering.
>
> I think there's still a section mismatch issue with these patches, so
> I
On Thu, Oct 25, 2012 at 11:35:57AM -0600, Bjorn Helgaas wrote:
On Thu, Aug 23, 2012 at 10:36 AM, Matthew Garrett m...@redhat.com wrote:
V3 just fixes all the casting issues and incorporates David's change in
search ordering.
I think there's still a section mismatch issue with these
On Thu, Aug 23, 2012 at 10:36 AM, Matthew Garrett wrote:
> V3 just fixes all the casting issues and incorporates David's change in
> search ordering.
I think there's still a section mismatch issue with these patches, so
I haven't merged them yet.
I rebased my pci/mjg-pci-roms-from-efi branch to
On Thu, Aug 23, 2012 at 10:36 AM, Matthew Garrett m...@redhat.com wrote:
V3 just fixes all the casting issues and incorporates David's change in
search ordering.
I think there's still a section mismatch issue with these patches, so
I haven't merged them yet.
I rebased my
On Fri, Aug 24, 2012 at 10:30:01AM +0100, David Woodhouse wrote:
> On Thu, 2012-08-23 at 12:36 -0400, Matthew Garrett wrote:
> > V3 just fixes all the casting issues and incorporates David's change in
> > search ordering.
>
> I appreciate there are other issues with kexec under EFI, but let's not
On Thu, 2012-08-23 at 12:36 -0400, Matthew Garrett wrote:
> V3 just fixes all the casting issues and incorporates David's change in
> search ordering.
I appreciate there are other issues with kexec under EFI, but let's not
make it worse. What is the plan for making this work *after* kexec? Do
On Thu, 2012-08-23 at 12:36 -0400, Matthew Garrett wrote:
V3 just fixes all the casting issues and incorporates David's change in
search ordering.
I appreciate there are other issues with kexec under EFI, but let's not
make it worse. What is the plan for making this work *after* kexec? Do
these
On Fri, Aug 24, 2012 at 10:30:01AM +0100, David Woodhouse wrote:
On Thu, 2012-08-23 at 12:36 -0400, Matthew Garrett wrote:
V3 just fixes all the casting issues and incorporates David's change in
search ordering.
I appreciate there are other issues with kexec under EFI, but let's not
make
V3 just fixes all the casting issues and incorporates David's change in
search ordering.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
V3 just fixes all the casting issues and incorporates David's change in
search ordering.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
62 matches
Mail list logo
