ly the device actively reporting command failure.
Ok, that makes sense. Is there any practical way for us to identify
why the device might be doing that? It seems to be limited to the LPM
case, but this is (theoretically) in the same configuration that the
firmware programmed, so it's a little surprising
accessible
[ 1896.932716] ata1.00: supports DRM functions and may not be fully accessible
[ 1896.942783] ata1.00: configured for UDMA/133
[ 1896.942815] ata1: EH complete
which seems to occur in batches. I'm a little confused - isn't it
legitimate for the phy to report comwake here?
--
Matthew
Any feedback on this?
--
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 the FAQ at http://www.tux.org/lkml/
actively reporting command failure.
Ok, that makes sense. Is there any practical way for us to identify
why the device might be doing that? It seems to be limited to the LPM
case, but this is (theoretically) in the same configuration that the
firmware programmed, so it's a little surprising.
--
Matthew
Any feedback on this?
--
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 the FAQ at http://www.tux.org/lkml/
not be fully accessible
[ 1896.932716] ata1.00: supports DRM functions and may not be fully accessible
[ 1896.942783] ata1.00: configured for UDMA/133
[ 1896.942815] ata1: EH complete
which seems to occur in batches. I'm a little confused - isn't it
legitimate for the phy to report comwake here?
--
Matthew
phys() isn't the worst thing to do here.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
thing to do here.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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 the FAQ at http://www.tux.org
adowed copy of a real underlying hardware ROM, but is
> fundamentally just a RAM image decompressed from some other source and
> then marked read-only.
If only - nvidias used to rewrite their image at runtime.
--
Matthew Garrett | matthew.garr...@coreos.com
--
To unsubscribe from this list: s
On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas wrote:
> Your i915 does not have a ROM BAR in hardware. If the default video
> device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
> even though the resource flags are zero because the BAR itself doesn't
> exist.
>
> If
On Thu, Apr 23, 2015 at 12:08:01PM +0200, Andreas Noever wrote:
> Hi Adam,
>
> On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
> controller both use 0x1547 and are only differentiated by
> subvendor/subdevice.
Do they have the same PCI class?
--
Matth
On Thu, Apr 23, 2015 at 12:08:01PM +0200, Andreas Noever wrote:
Hi Adam,
On my system (MacBookPro10,1 - 4 channel TB1) the bridges and the
controller both use 0x1547 and are only differentiated by
subvendor/subdevice.
Do they have the same PCI class?
--
Matthew Garrett | mj
On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas bhelg...@google.com wrote:
Your i915 does not have a ROM BAR in hardware. If the default video
device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
even though the resource flags are zero because the BAR itself doesn't
exist.
If
hardware ROM, but is
fundamentally just a RAM image decompressed from some other source and
then marked read-only.
If only - nvidias used to rewrite their image at runtime.
--
Matthew Garrett | matthew.garr...@coreos.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
anything. You added that in dc009d92435f99498cbc579ce76bf28e837e2c14 and
now the horse is long gone. Don't give CAP_SYS_BOOT to anything you
don't trust with full privileges.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
that in dc009d92435f99498cbc579ce76bf28e837e2c14 and
now the horse is long gone. Don't give CAP_SYS_BOOT to anything you
don't trust with full privileges.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
The initial configuration for power management settings may be a result of
the firmware using its knowledge of the installed hardware to program
reasonable defaults. Stash as much of it as possible for later use.
Signed-off-by: Matthew Garrett
---
drivers/ata/acard-ahci.c | 3
we
occasionally see with the min_power policy.
Signed-off-by: Matthew Garrett
---
drivers/ata/libahci.c | 1 +
drivers/ata/libata-core.c | 4
drivers/ata/libata-eh.c | 10 --
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/ata/libahci.c b/drivers/ata
System vendors may configure SATA link power management appropriately for
their systems in firmware, based on their knowledge of the hardware
installed. Add an additional LPM policy designed to inherit the
configuration provided by the firmware.
Signed-off-by: Matthew Garrett
---
.../scsi
This patchset tries to get us closer to having reasonable defaults for link
power management on AHCI. Recent Intel CPUs can't enter deep power saving
states unless the SATA link is in a low power state, appearing to be limited
to PC6 in PARTIAL and PC7 in SLUMBER, and PC2 otherwise. This amounts
This patchset tries to get us closer to having reasonable defaults for link
power management on AHCI. Recent Intel CPUs can't enter deep power saving
states unless the SATA link is in a low power state, appearing to be limited
to PC6 in PARTIAL and PC7 in SLUMBER, and PC2 otherwise. This amounts
The initial configuration for power management settings may be a result of
the firmware using its knowledge of the installed hardware to program
reasonable defaults. Stash as much of it as possible for later use.
Signed-off-by: Matthew Garrett mj...@srcf.ucam.org
---
drivers/ata/acard-ahci.c
we
occasionally see with the min_power policy.
Signed-off-by: Matthew Garrett mj...@coreos.com
---
drivers/ata/libahci.c | 1 +
drivers/ata/libata-core.c | 4
drivers/ata/libata-eh.c | 10 --
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/ata/libahci.c
System vendors may configure SATA link power management appropriately for
their systems in firmware, based on their knowledge of the hardware
installed. Add an additional LPM policy designed to inherit the
configuration provided by the firmware.
Signed-off-by: Matthew Garrett mj...@coreos.com
On Mon, Apr 13, 2015 at 7:32 AM, Tejun Heo wrote:
> On Fri, Apr 10, 2015 at 01:15:29PM -0700, Matthew Garrett wrote:
>> Intel publish a document on designing energy efficient SATA devices at
>> http://www.intel.com/content/dam/doc/reference-guide/sata-devices-implementation-reco
On Mon, Apr 13, 2015 at 7:32 AM, Tejun Heo t...@kernel.org wrote:
On Fri, Apr 10, 2015 at 01:15:29PM -0700, Matthew Garrett wrote:
Intel publish a document on designing energy efficient SATA devices at
http://www.intel.com/content/dam/doc/reference-guide/sata-devices-implementation
breakages we occasionally see with
the min_power policy.
Signed-off-by: Matthew Garrett
---
Documentation/scsi/link_power_management_policy.txt | 14 --
drivers/ata/libahci.c | 3 +--
drivers/ata/libata-core.c | 1 +
drivers/ata
breakages we occasionally see with
the min_power policy.
Signed-off-by: Matthew Garrett mj...@coreos.com
---
Documentation/scsi/link_power_management_policy.txt | 14 --
drivers/ata/libahci.c | 3 +--
drivers/ata/libata-core.c | 1
From: Matthew Garrett
The kernel supports having a command line built into it. Unfortunately this
doesn't work in all cases - the built-in command line is only appended
after we've jumped to the kernel proper, but various parts of the early
boot process also pay attention to the command line
ion (ie, did the hardware vendor bother
setting the hub flags), so...
--
Matthew Garrett | matthew.garr...@coreos.com
--
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.o
On Wed, Apr 8, 2015 at 10:20 PM, Takashi Iwai wrote:
>
> At Wed, 8 Apr 2015 18:53:48 -0700,
> Matthew Garrett wrote:
> >
> > Modern hardware will often have multiple HDA devices, and the desired
> > power saving configuration may vary depending on the codecs attache
On Wed, Apr 8, 2015 at 10:20 PM, Takashi Iwai ti...@suse.de wrote:
At Wed, 8 Apr 2015 18:53:48 -0700,
Matthew Garrett wrote:
Modern hardware will often have multiple HDA devices, and the desired
power saving configuration may vary depending on the codecs attached to
each of them. Push
information (ie, did the hardware vendor bother
setting the hub flags), so...
--
Matthew Garrett | matthew.garr...@coreos.com
--
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
From: Matthew Garrett mj...@coreos.com
The kernel supports having a command line built into it. Unfortunately this
doesn't work in all cases - the built-in command line is only appended
after we've jumped to the kernel proper, but various parts of the early
boot process also pay attention
for compatibility purposes.
Signed-off-by: Matthew Garrett
---
Documentation/sound/alsa/HD-Audio.txt | 5 +++--
sound/pci/hda/hda_codec.c | 28
sound/pci/hda/hda_codec.h | 19 ---
sound/pci/hda/hda_controller.c| 6 +++---
sound/pci
Windows appears to pay more attention to the ACPI values than any hub
configuration, so prefer the firmware's opinion on whether a port is
fixed or removable before falling back to the hub values.
Signed-off-by: Matthew Garrett
---
drivers/usb/core/hub.c | 32 +---
1
The Microsoft document "Using ACPI to Configure USB Ports on a Computer"
makes it clear that the removable flag will be cleared on ports that are
marked as unused by the firmware. Handle this case to match.
Signed-off-by: Matthew Garrett
---
drivers/usb/core/hub.c | 3 +++
1 file
shouldn't
be added once more.
Signed-off-by: Matthew Garrett
---
Documentation/x86/boot.txt | 4 +++
arch/x86/boot/boot.h | 10 ++
arch/x86/boot/cmdline.c| 37 +++
arch/x86/boot/compressed/cmdline.c
shouldn't
be added once more.
Signed-off-by: Matthew Garrett mj...@coreos.com
---
Documentation/x86/boot.txt | 4 +++
arch/x86/boot/boot.h | 10 ++
arch/x86/boot/cmdline.c| 37 +++
arch/x86/boot/compressed/cmdline.c
Windows appears to pay more attention to the ACPI values than any hub
configuration, so prefer the firmware's opinion on whether a port is
fixed or removable before falling back to the hub values.
Signed-off-by: Matthew Garrett mj...@coreos.com
---
drivers/usb/core/hub.c | 32
The Microsoft document Using ACPI to Configure USB Ports on a Computer
makes it clear that the removable flag will be cleared on ports that are
marked as unused by the firmware. Handle this case to match.
Signed-off-by: Matthew Garrett mj...@coreos.com
---
drivers/usb/core/hub.c | 3 +++
1 file
for compatibility purposes.
Signed-off-by: Matthew Garrett mj...@coreos.com
---
Documentation/sound/alsa/HD-Audio.txt | 5 +++--
sound/pci/hda/hda_codec.c | 28
sound/pci/hda/hda_codec.h | 19 ---
sound/pci/hda/hda_controller.c| 6
-by: Matthew Garrett
---
drivers/acpi/pci_root.c | 19 ---
drivers/pci/pcie/aspm.c | 18 --
include/linux/pci-aspm.h | 4
3 files changed, 8 insertions(+), 33 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 68a5f71..1b5569c
-by: Matthew Garrett mj...@coreos.com
---
drivers/acpi/pci_root.c | 19 ---
drivers/pci/pcie/aspm.c | 18 --
include/linux/pci-aspm.h | 4
3 files changed, 8 insertions(+), 33 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index
stem Information
> Manufacturer: Intel Corporation
> Product Name: S1200RP_SE
>
> Signed-off-by: Ross Lagerwall
ACKed-by: Matthew Garrett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
Corporation
Product Name: S1200RP_SE
Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com
ACKed-by: Matthew Garrett mj...@coreos.com
--
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
On Tue, Mar 24, 2015 at 02:53:24PM -0500, Mario Limonciello wrote:
> On 03/24/2015 01:01 PM, Matthew Garrett wrote:
> >Will it? You haven't shipped the firmware that changes this behaviour
> >yet.
> >
> This was posted a few days ago. BIOS A02, it resolves the broken behav
t; hardware in the field. If this isn't an appropriate criteria for
> avoiding to backport a patch to stable, what is?
Will it? You haven't shipped the firmware that changes this behaviour
yet.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsub
an appropriate criteria for
avoiding to backport a patch to stable, what is?
Will it? You haven't shipped the firmware that changes this behaviour
yet.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On Tue, Mar 24, 2015 at 02:53:24PM -0500, Mario Limonciello wrote:
On 03/24/2015 01:01 PM, Matthew Garrett wrote:
Will it? You haven't shipped the firmware that changes this behaviour
yet.
This was posted a few days ago. BIOS A02, it resolves the broken behavior
introduced in A01
On Tue, 2015-03-17 at 20:22 +, Simon McVittie wrote:
> Is the intention instead that it will make privileged bits of userland
> more careful to avoid breaking the trust chain in ways that would "fail
> safe" by refusing to boot?
Not really. It's intended to avoid the situation where
On Tue, 2015-03-17 at 20:22 +, Simon McVittie wrote:
Is the intention instead that it will make privileged bits of userland
more careful to avoid breaking the trust chain in ways that would fail
safe by refusing to boot?
Not really. It's intended to avoid the situation where privileged
On Mon, 2015-03-16 at 13:35 -0700, David Lang wrote:
> On Mon, 16 Mar 2015, Matthew Garrett wrote:
> > That's one implementation. Another is the kernel being stored on
> > non-volatile media.
>
> Anything that encourages deploying systems that can't be upgraded to fix bugs
On Mon, 2015-03-16 at 14:36 -0700, Kees Cook wrote:
> Perhaps this should be folded into the hibernation_available check
> instead of added as an "||" check here?
That would end up covering in-kernel hibernation as well, which was more
than I was aiming to do. But it's plausibly a justifiable
nfortunately probably
not an option.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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 the FAQ at http://www.tux.org/lkml/
On Mon, 2015-03-16 at 14:45 +, One Thousand Gnomes wrote:
> On Fri, 13 Mar 2015 11:38:16 -1000
> Matthew Garrett wrote:
>
> > 4) Used the word "measured"
> >
> > Nothing is being measured.
>
> Nothing is being trusted either. It's simple
On Mon, 2015-03-16 at 14:45 +, One Thousand Gnomes wrote:
On Fri, 13 Mar 2015 11:38:16 -1000
Matthew Garrett matthew.garr...@nebula.com wrote:
4) Used the word measured
Nothing is being measured.
Nothing is being trusted either. It's simple ensuring you probably have
the same
On Mon, 2015-03-16 at 14:36 -0700, Kees Cook wrote:
Perhaps this should be folded into the hibernation_available check
instead of added as an || check here?
That would end up covering in-kernel hibernation as well, which was more
than I was aiming to do. But it's plausibly a justifiable
.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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 the FAQ at http://www.tux.org/lkml/
On Mon, 2015-03-16 at 13:35 -0700, David Lang wrote:
On Mon, 16 Mar 2015, Matthew Garrett wrote:
That's one implementation. Another is the kernel being stored on
non-volatile media.
Anything that encourages deploying systems that can't be upgraded to fix bugs
that are discovered
I've had some feedback on a couple of these, so I'll repost a new
version within the next couple of days. Please hold off review until
then.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
I've had some feedback on a couple of these, so I'll repost a new
version within the next couple of days. Please hold off review until
then.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
enabled.
Signed-off-by: Matthew Garrett
---
Documentation/x86/zero-page.txt | 2 ++
arch/x86/Kconfig | 13 +
arch/x86/boot/compressed/eboot.c | 33 +
arch/x86/include/uapi/asm/bootparam.h | 3 ++-
arch/x86/kernel
Permitting write access to MSRs allows userspace to modify the running
kernel. Prevent this if trusted_kernel is true. Based on a patch by Kees
Cook.
Cc: Kees Cook
Signed-off-by: Matthew Garrett
---
arch/x86/kernel/msr.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86
We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
be manipulated in such a way that arbitrary code can be executed in the
kernel. Prevent that if trusted_kernel is true.
Signed-off-by: Matthew Garrett
.
In future we can potentially relax this for sufficiently IOMMU-isolated
devices.
Signed-off-by: Matthew Garrett
---
drivers/pci/pci-sysfs.c | 9 +
drivers/pci/proc.c | 9 -
drivers/pci/syscall.c | 3 ++-
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/pci
uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel. Disable this if
trusted_kernel is true.
Signed-off-by: Matthew Garrett
---
kernel/power/user.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel
From: Josh Boyer
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to execute arbitrary code in the kernel.
Disable this when trusted_kernel is true.
Signed-off-by: Josh Boyer
---
drivers/acpi/osl.c | 3 ++-
1 file changed, 2
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to modify the kernel at runtime. Prevent this
if trusted_kernel is true.
Signed-off-by: Matthew Garrett
---
drivers/acpi/custom_method.c | 4
1 file changed, 4 insertions(+)
diff --git
kexec permits the loading and execution of arbitrary code in ring 0, which
permits the modification of the running kernel. Restrict it such that only
images which have been verified may be loaded when trusted_kernel is true.
Signed-off-by: Matthew Garrett
---
kernel/kexec.c | 18
Allowing users to write to address space provides mechanisms that may permit
modification of the kernel at runtime. Prevent this if trusted_kernel is
true.
Signed-off-by: Matthew Garrett
---
drivers/char/mem.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/char/mem.c b
If trusted_kernel is true, require that all modules have valid signatures.
Signed-off-by: Matthew Garrett
---
include/linux/module.h| 6 ++
kernel/module.c | 6 ++
security/trusted_kernel.c | 6 +-
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/include
Provide a boolean runtime configuration option for restricting userspace's
ability to modify the running kernel. This can be used when some external
validation of the kernel's state has been performed.
Signed-off-by: Matthew Garrett
---
Documentation/kernel-parameters.txt | 6
) Used the word "measured"
Nothing is being measured.
A patchset basically equivalent to this is already used by most major Linux
distributions, so it would be nice to either get this merged or have feedback
from a relevant maintainer as to how they'd like it to be implemented instead.
-
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO register
space. This would potentially permit root to trigger arbitrary DMA, so lock
it down when trusted_kernel is true
Signed-off-by: Matthew Garrett
Permitting write access to MSRs allows userspace to modify the running
kernel. Prevent this if trusted_kernel is true. Based on a patch by Kees
Cook.
Cc: Kees Cook keesc...@chromium.org
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
arch/x86/kernel/msr.c | 8
1 file
We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
be manipulated in such a way that arbitrary code can be executed in the
kernel. Prevent that if trusted_kernel is true.
Signed-off-by: Matthew Garrett
If trusted_kernel is true, require that all modules have valid signatures.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
include/linux/module.h| 6 ++
kernel/module.c | 6 ++
security/trusted_kernel.c | 6 +-
3 files changed, 17 insertions(+), 1 deletion
enabled.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
Documentation/x86/zero-page.txt | 2 ++
arch/x86/Kconfig | 13 +
arch/x86/boot/compressed/eboot.c | 33 +
arch/x86/include/uapi/asm/bootparam.h | 3
kexec permits the loading and execution of arbitrary code in ring 0, which
permits the modification of the running kernel. Restrict it such that only
images which have been verified may be loaded when trusted_kernel is true.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
kernel
Allowing users to write to address space provides mechanisms that may permit
modification of the kernel at runtime. Prevent this if trusted_kernel is
true.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/char/mem.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to modify the kernel at runtime. Prevent this
if trusted_kernel is true.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/acpi/custom_method.c | 4
1 file changed, 4
uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel. Disable this if
trusted_kernel is true.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
kernel/power/user.c | 3 ++-
1 file changed, 2 insertions(+), 1
From: Josh Boyer jwbo...@redhat.com
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to execute arbitrary code in the kernel.
Disable this when trusted_kernel is true.
Signed-off-by: Josh Boyer jwbo...@redhat.com
---
drivers/acpi/osl.c | 3
.
In future we can potentially relax this for sufficiently IOMMU-isolated
devices.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/pci/pci-sysfs.c | 9 +
drivers/pci/proc.c | 9 -
drivers/pci/syscall.c | 3 ++-
3 files changed, 19 insertions(+), 2 deletions
) Used the word measured
Nothing is being measured.
A patchset basically equivalent to this is already used by most major Linux
distributions, so it would be nice to either get this merged or have feedback
from a relevant maintainer as to how they'd like it to be implemented instead.
--
Matthew
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO register
space. This would potentially permit root to trigger arbitrary DMA, so lock
it down when trusted_kernel is true
Signed-off-by: Matthew Garrett
Provide a boolean runtime configuration option for restricting userspace's
ability to modify the running kernel. This can be used when some external
validation of the kernel's state has been performed.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
Documentation/kernel
aviour, but Windows responds to _REV with 2 even before that
and so vendors might simply change the order of queries in order to continue
IDing Linux. The easiest thing for us to do is just to change the value on
X86 and leave a comment describing why everything is so awful.
Signed-off-by: Matthew G
even before that
and so vendors might simply change the order of queries in order to continue
IDing Linux. The easiest thing for us to do is just to change the value on
X86 and leave a comment describing why everything is so awful.
Signed-off-by: Matthew Garrett mj...@srcf.ucam.org
---
include/acpi
s any way to create a generic
interface for it. In this case, I suspect not and that this is fine.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majo
a generic
interface for it. In this case, I suspect not and that this is fine.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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
On Mon, 2015-01-05 at 14:41 -0800, Andrew Morton wrote:
> On Mon, 22 Dec 2014 19:19:39 +0000 Matthew Garrett
> wrote:
>
> > Some platform firmware may interfere with the RTC alarm over suspend,
> > resulting in the kernel and hardware having different ideas about system
&
On Mon, 2015-01-05 at 14:41 -0800, Andrew Morton wrote:
On Mon, 22 Dec 2014 19:19:39 + Matthew Garrett
matthew.garr...@nebula.com wrote:
Some platform firmware may interfere with the RTC alarm over suspend,
resulting in the kernel and hardware having different ideas about system
On Tue, 2014-12-30 at 10:16 +, Carlos R. Mafra wrote:
> On Tue, 30 Dec 2014 at 1:28:21 +0000, Matthew Garrett wrote:
> > What is CONFIG_ACPI_SBS set to?
>
> CONFIG_ACPI_SBS is not set
There's your problem. The Darwin call results in the firmware exposing
the battery via SBS,
On Tue, 2014-12-30 at 10:16 +, Carlos R. Mafra wrote:
On Tue, 30 Dec 2014 at 1:28:21 +, Matthew Garrett wrote:
What is CONFIG_ACPI_SBS set to?
CONFIG_ACPI_SBS is not set
There's your problem. The Darwin call results in the firmware exposing
the battery via SBS, not as an ACPI
; remaining etc).
>
> With the kernel v3.17 the battery information stopped working and it
> still does not work in the latest v3.19-rc1.
What is CONFIG_ACPI_SBS set to?
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
v3.17 the battery information stopped working and it
still does not work in the latest v3.19-rc1.
What is CONFIG_ACPI_SBS set to?
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m
and will
restore it on resume if the alarm has not yet fired - if it has, it will clear
the RTC alarm.
Signed-off-by: Matthew Garrett
Tested-by: Gabriele Mazzotta
---
drivers/rtc/class.c | 24
include/linux/rtc.h | 4
2 files changed, 28 insertions(+)
diff --git
rtc_device
/* Some hardware can't support UIE mode */
int uie_unsupported;
+#ifdef CONFIG_PM_SLEEP
+ struct rtc_wkalrm alarm;
+ bool valid_alarm;
+#endif
#ifdef CONFIG_RTC_INTF_DEV_UIE_EMUL
struct work_struct uie_task;
struct timer_list u
701 - 800 of 3200 matches
Mail list logo
