linux-kernel - RE: [PATCH] HP iLO driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CF70AA892F109448AEA269483B3A983903B6F79D74@G1W1215.americas.hpqcorp.net>
Date:	Thu, 12 Jun 2008 20:16:02 +0000
From:	"Altobelli, David" <david.altobelli@...com>
To:	Heikki Orsila <shdl@...alwe.fi>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] HP iLO driver

Heikki Orsila wrote:
> On Thu, Jun 12, 2008 at 12:23:08PM -0600, David Altobelli wrote:
>> +    volatile u64 fifobar[1];
>> +};
>
> Why do you need a volatile? What you probably want is atomic ops.
> Spinlocks will create memory barriers implicitly.

This points to a queue that is shared with hardware, and could
be modified outside of kernel control.

>> +static int fifo_enqueue(struct ilo_hwinfo *hw, char *fifobar, int
>> entry) +{ +     struct fifo *Q = FIFOBARTOHANDLE(fifobar);
>> +     int ret = 0;
>> +
>> +     spin_lock(&hw->fifo_lock);
>> +     if (!(Q->fifobar[(Q->tail + 1) & Q->imask] & ENTRY_MASK_O)) {
>> +             Q->fifobar[Q->tail & Q->imask] |=
>> +                     ((entry & ENTRY_MASK_NOSTATE) | Q->merge); +
>> Q->tail += 1; +             ret = 1;
>> +     }
>> +     spin_unlock(&hw->fifo_lock);
>> +
>> +     return ret;
>> +}
>
> Is writing to Q->fifobar (u64 *) endian-safe?

No, this is not endian-safe. Good point.  I think converting these
to readl() operations would let me remove the volatile and fix the
endian issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/