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
> p
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
>>> boot_para
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 sign
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 ide
"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 i
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 there'
"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 n
"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 en
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 wh
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 as
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 se
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
>> boo
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 exp
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 debugf
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.
>
> W
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 a
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 D
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 there'
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 pretty
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 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 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 there's
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, 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
28 matches
Mail list logo
