On Thu, Feb 07, 2013 at 09:02:38PM +, David Woodhouse wrote:
> Backtraces add visibility and have proven to be extremely useful in the
> past for getting people to actually *fix* broken BIOSes.
>
> When kerneloops.org was running, it also gave very good statistics which
> helped to apply
On Thu, 2013-02-07 at 18:27 +0100, Joerg Roedel wrote:
>
> Second, I think that it should be a pr_warn instead of a full WARN. When
> IRQ remapping could not be enabled it's most likely because of the BIOS
> or the hardware. So a message in the kernel log will do and the
> backtrace provides no
On Thu, Feb 07, 2013 at 09:53:45AM -0800, Andy Lutomirski wrote:
> On Thu, Feb 7, 2013 at 9:27 AM, Joerg Roedel wrote:
> > Hmm, looking into the intel_irq_remapping.c version in the tip tree
> > makes me wonder even more.
>
> Is this the version I'm based on (intel_irq_remapping: Clean up x2apic
On Thu, Feb 7, 2013 at 9:27 AM, Joerg Roedel wrote:
> On Thu, Feb 07, 2013 at 08:29:42AM -0800, Andy Lutomirski wrote:
>> On Thu, Feb 7, 2013 at 3:33 AM, Joerg Roedel wrote:
>> > On Wed, Feb 06, 2013 at 07:08:24PM -0800, Andy Lutomirski wrote:
>> >> - if (x2apic_present)
>> >> -
On Thu, Feb 07, 2013 at 08:29:42AM -0800, Andy Lutomirski wrote:
> On Thu, Feb 7, 2013 at 3:33 AM, Joerg Roedel wrote:
> > On Wed, Feb 06, 2013 at 07:08:24PM -0800, Andy Lutomirski wrote:
> >> - if (x2apic_present)
> >> - WARN(1, KERN_WARNING
> >> - "Failed to
On Thu, Feb 7, 2013 at 3:33 AM, Joerg Roedel wrote:
> On Wed, Feb 06, 2013 at 07:08:24PM -0800, Andy Lutomirski wrote:
>> - if (x2apic_present)
>> - WARN(1, KERN_WARNING
>> - "Failed to enable irq remapping. You are vulnerable
>> to irq-injection
On Wed, Feb 06, 2013 at 07:08:24PM -0800, Andy Lutomirski wrote:
> - if (x2apic_present)
> - WARN(1, KERN_WARNING
> - "Failed to enable irq remapping. You are vulnerable to
> irq-injection attacks.\n");
> -
> + irq_remapping_is_secure = 0;
> return
On Thu, Feb 7, 2013 at 9:27 AM, Joerg Roedel j...@8bytes.org wrote:
On Thu, Feb 07, 2013 at 08:29:42AM -0800, Andy Lutomirski wrote:
On Thu, Feb 7, 2013 at 3:33 AM, Joerg Roedel j...@8bytes.org wrote:
On Wed, Feb 06, 2013 at 07:08:24PM -0800, Andy Lutomirski wrote:
- if (x2apic_present)
On Thu, Feb 07, 2013 at 09:53:45AM -0800, Andy Lutomirski wrote:
On Thu, Feb 7, 2013 at 9:27 AM, Joerg Roedel j...@8bytes.org wrote:
Hmm, looking into the intel_irq_remapping.c version in the tip tree
makes me wonder even more.
Is this the version I'm based on (intel_irq_remapping: Clean
On Thu, 2013-02-07 at 18:27 +0100, Joerg Roedel wrote:
Second, I think that it should be a pr_warn instead of a full WARN. When
IRQ remapping could not be enabled it's most likely because of the BIOS
or the hardware. So a message in the kernel log will do and the
backtrace provides no
On Thu, Feb 07, 2013 at 09:02:38PM +, David Woodhouse wrote:
Backtraces add visibility and have proven to be extremely useful in the
past for getting people to actually *fix* broken BIOSes.
When kerneloops.org was running, it also gave very good statistics which
helped to apply pressure.
On Wed, Feb 06, 2013 at 07:08:24PM -0800, Andy Lutomirski wrote:
- if (x2apic_present)
- WARN(1, KERN_WARNING
- Failed to enable irq remapping. You are vulnerable to
irq-injection attacks.\n);
-
+ irq_remapping_is_secure = 0;
return -1;
}
On Thu, Feb 7, 2013 at 3:33 AM, Joerg Roedel j...@8bytes.org wrote:
On Wed, Feb 06, 2013 at 07:08:24PM -0800, Andy Lutomirski wrote:
- if (x2apic_present)
- WARN(1, KERN_WARNING
- Failed to enable irq remapping. You are vulnerable
to irq-injection
On Thu, Feb 07, 2013 at 08:29:42AM -0800, Andy Lutomirski wrote:
On Thu, Feb 7, 2013 at 3:33 AM, Joerg Roedel j...@8bytes.org wrote:
On Wed, Feb 06, 2013 at 07:08:24PM -0800, Andy Lutomirski wrote:
- if (x2apic_present)
- WARN(1, KERN_WARNING
- Failed
On Wed, Feb 6, 2013 at 7:08 PM, Andy Lutomirski wrote:
> We currently report IOMMU_CAP_INTR_REMAP whenever interrupt remapping
> is enabled. Users of that capability expect it to mean that remapping
> is secure (i.e. compatibility format interrupts are blocked). Explicitly
> check whether CFIs
We currently report IOMMU_CAP_INTR_REMAP whenever interrupt remapping
is enabled. Users of that capability expect it to mean that remapping
is secure (i.e. compatibility format interrupts are blocked). Explicitly
check whether CFIs are blocked and, if not, don't report the capability.
Cc: Alex
We currently report IOMMU_CAP_INTR_REMAP whenever interrupt remapping
is enabled. Users of that capability expect it to mean that remapping
is secure (i.e. compatibility format interrupts are blocked). Explicitly
check whether CFIs are blocked and, if not, don't report the capability.
Cc: Alex
On Wed, Feb 6, 2013 at 7:08 PM, Andy Lutomirski l...@amacapital.net wrote:
We currently report IOMMU_CAP_INTR_REMAP whenever interrupt remapping
is enabled. Users of that capability expect it to mean that remapping
is secure (i.e. compatibility format interrupts are blocked). Explicitly
18 matches
Mail list logo
