On Mon, Aug 28, 2017 at 05:10:33PM -0700, Kees Cook wrote:
> On Wed, Aug 23, 2017 at 7:56 AM, Luck, Tony wrote:
> >>> Should this not also have a capability check. Assuming file permissions
> >>> are sufficient for grabbing a chunk of system memory holding error
> >>> info
On Mon, Aug 28, 2017 at 05:10:33PM -0700, Kees Cook wrote:
> On Wed, Aug 23, 2017 at 7:56 AM, Luck, Tony wrote:
> >>> Should this not also have a capability check. Assuming file permissions
> >>> are sufficient for grabbing a chunk of system memory holding error
> >>> info doesn't seem too scary
On Wed, Aug 23, 2017 at 7:56 AM, Luck, Tony wrote:
>>> Should this not also have a capability check. Assuming file permissions
>>> are sufficient for grabbing a chunk of system memory holding error
>>> info doesn't seem too scary but it's at odds with a lot of other cases ?
On Wed, Aug 23, 2017 at 7:56 AM, Luck, Tony wrote:
>>> Should this not also have a capability check. Assuming file permissions
>>> are sufficient for grabbing a chunk of system memory holding error
>>> info doesn't seem too scary but it's at odds with a lot of other cases ?
>>
>> At least one of
>> Should this not also have a capability check. Assuming file permissions
>> are sufficient for grabbing a chunk of system memory holding error
>> info doesn't seem too scary but it's at odds with a lot of other cases ?
>
> At least one of those other cases (pstore) added a capability check and
>> Should this not also have a capability check. Assuming file permissions
>> are sufficient for grabbing a chunk of system memory holding error
>> info doesn't seem too scary but it's at odds with a lot of other cases ?
>
> At least one of those other cases (pstore) added a capability check and
"Luck, Tony" writes:
> From: Tony Luck
>
> The ACPI sysfs interface provides a way to read each ACPI table from
> userspace via entries in /sys/firmware/acpi/tables/
>
> The BERT table simply provides the size and address of the error
> record in BIOS
"Luck, Tony" writes:
> From: Tony Luck
>
> The ACPI sysfs interface provides a way to read each ACPI table from
> userspace via entries in /sys/firmware/acpi/tables/
>
> The BERT table simply provides the size and address of the error
> record in BIOS reserved memory and users may want access
> Should this not also have a capability check. Assuming file permissions
> are sufficient for grabbing a chunk of system memory holding error
> info doesn't seem too scary but it's at odds with a lot of other cases ?
At least one of those other cases (pstore) added a capability check and now
> Should this not also have a capability check. Assuming file permissions
> are sufficient for grabbing a chunk of system memory holding error
> info doesn't seem too scary but it's at odds with a lot of other cases ?
At least one of those other cases (pstore) added a capability check and now
On Thu, 17 Aug 2017 14:39:46 -0700
"Luck, Tony" wrote:
> From: Tony Luck
>
> The ACPI sysfs interface provides a way to read each ACPI table from
> userspace via entries in /sys/firmware/acpi/tables/
>
> The BERT table simply provides the size and
On Thu, 17 Aug 2017 14:39:46 -0700
"Luck, Tony" wrote:
> From: Tony Luck
>
> The ACPI sysfs interface provides a way to read each ACPI table from
> userspace via entries in /sys/firmware/acpi/tables/
>
> The BERT table simply provides the size and address of the error
> record in BIOS
From: Tony Luck
The ACPI sysfs interface provides a way to read each ACPI table from
userspace via entries in /sys/firmware/acpi/tables/
The BERT table simply provides the size and address of the error
record in BIOS reserved memory and users may want access to this
record.
From: Tony Luck
The ACPI sysfs interface provides a way to read each ACPI table from
userspace via entries in /sys/firmware/acpi/tables/
The BERT table simply provides the size and address of the error
record in BIOS reserved memory and users may want access to this
record.
In an earlier age
14 matches
Mail list logo