Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

[Russell King - ARM Linux]

Do you think that the appropriate patches could be copied to the
appropriate people please?

On Thu, Jan 11, 2018 at 04:46:24PM -0800, Dan Williams wrote:
> Changes since v1 [1]:
> * fixup the ifence definition to use alternative_2 per recent AMD
>   changes in tip/x86/pti (Tom)
> 
> * drop 'nospec_ptr' (Linus, Mark)
> 
> * rename 'nospec_array_ptr' to 'array_ptr' (Alexei)
> 
> * rename 'nospec_barrier' to 'ifence' (Peter, Ingo)
> 
> * clean up occasions of 'variable assignment in if()' (Sergei, Stephen)
> 
> * make 'array_ptr' use a mask instead of an architectural ifence by
>   default (Linus, Alexei)
> 
> * provide a command line and compile-time opt-in to the ifence
>   mechanism, if an architecture provides 'ifence_array_ptr'.
> 
> * provide an optimized mask generation helper, 'array_ptr_mask', for
>   x86 (Linus)
> 
> * move 'get_user' hardening from '__range_not_ok' to '__uaccess_begin'
>   (Linus)
> 
> * drop "Thermal/int340x: prevent bounds-check..." since userspace does
>   not have arbitrary control over the 'trip' index (Srinivas)
> 
> * update the changelog of "net: mpls: prevent bounds-check..." and keep
>   it in the series to continue the debate about Spectre hygiene patches.
>   (Eric).
> 
> * record a reviewed-by from Laurent on "[media] uvcvideo: prevent
>   bounds-check..."
> 
> * update the cover letter
> 
> [1]: https://lwn.net/Articles/743376/
> 
> ---
> 
> Quoting Mark's original RFC:
> 
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed under speculation, providing an
> arbitrary read gadget. Further details can be found on the GPZ blog [2]
> and the Documentation patch in this series."
> 
> This series incorporates Mark Rutland's latest ARM changes and adds
> the x86 specific implementation of 'ifence_array_ptr'. That ifence
> based approach is provided as an opt-in fallback, but the default
> mitigation, '__array_ptr', uses a 'mask' approach that removes
> conditional branches instructions, and otherwise aims to redirect
> speculation to use a NULL pointer rather than a user controlled value.
> 
> The mask is generated by the following from Alexei, and Linus:
> 
> mask = ~(long)(_i | (_s - 1 - _i)) >> (BITS_PER_LONG - 1);
> 
> ...and Linus provided an optimized mask generation helper for x86:
> 
> asm ("cmpq %1,%2; sbbq %0,%0;"
>   :"=r" (mask)
>   :"r"(sz),"r" (idx)
>   :"cc");
> 
> The 'array_ptr' mechanism can be switched between 'mask' and 'ifence'
> via the spectre_v1={mask,ifence} command line option, and the
> compile-time default is set by selecting either CONFIG_SPECTRE1_MASK or
> CONFIG_SPECTRE1_IFENCE.
> 
> The 'array_ptr' infrastructure is the primary focus this patch set. The
> individual patches that perform 'array_ptr' conversions are a point in
> time (i.e. earlier kernel, early analysis tooling, x86 only etc...)
> start at finding some of these gadgets.
> 
> Another consideration for reviewing these patches is the 'hygiene'
> argument. When a patch refers to hygiene it is concerned with stopping
> speculation on an unconstrained or insufficiently constrained pointer
> value under userspace control. That by itself is not sufficient for
> attack (per current understanding) [3], but it is a necessary
> pre-condition.  So 'hygiene' refers to cleaning up those suspect
> pointers regardless of whether they are usable as a gadget.
> 
> These patches are also be available via the 'nospec-v2' git branch
> here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v2
> 
> Note that the BPF fix for Spectre variant1 is merged in the bpf.git
> tree [4], and is not included in this branch.
> 
> [2]: 
> https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
> [3]: https://spectreattack.com/spectre.pdf
> [4]: 
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=b2157399cc98
> 
> ---
> 
> Dan Williams (16):
>   x86: implement ifence()
>   x86: implement ifence_array_ptr() and array_ptr_mask()
>   asm-generic/barrier: mask speculative execution flows
>   x86: introduce __uaccess_begin_nospec and ASM_IFENCE
>   x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths
>   ipv6: prevent bounds-check bypass via speculative execution
>   ipv4: prevent bounds-check bypass via speculative execution
>   vfs, fdtable: prevent bounds-check bypass via speculative execution
>   userns: prevent bounds-check bypass via speculative execution
>   udf: prevent bounds-check bypass via speculative execution
>   [media] uvcvideo: prevent bounds-check bypass via speculative execution
>   carl9170: prevent bounds-check bypass via speculative execution
>   p54: prevent bounds-check bypass via speculative execution
>   qla2xxx: prevent bounds-check bypass via speculative execution
>   cw1

[PATCH] mptfusion: use strlcpy() instead of strncpy()

[Xiongfeng Wang]

From: Xiongfeng Wang 

drivers/message/fusion/mptctl.c: In function '__mptctl_ioctl.isra.3':
./include/linux/string.h:245:9: warning: '__builtin_strncpy' specified
bound 12 equals destination size [-Wstringop-truncation]

The compiler requires that the destination size should be greater than
the length we copy to make sure the dest string is nul-terminated. We
can just use strlcpy() to avoid this warning.

Signed-off-by: Xiongfeng Wang 
---
 drivers/message/fusion/mptctl.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/message/fusion/mptctl.c b/drivers/message/fusion/mptctl.c
index 7b3b413..15f2aca 100644
--- a/drivers/message/fusion/mptctl.c
+++ b/drivers/message/fusion/mptctl.c
@@ -1353,8 +1353,7 @@ static int mptctl_do_reset(unsigned long arg)
 
/* Set the Version Strings.
 */
-   strncpy (karg->driverVersion, MPT_LINUX_PACKAGE_NAME, 
MPT_IOCTL_VERSION_LENGTH);
-   karg->driverVersion[MPT_IOCTL_VERSION_LENGTH-1]='\0';
+   strlcpy (karg->driverVersion, MPT_LINUX_PACKAGE_NAME, 
MPT_IOCTL_VERSION_LENGTH);
 
karg->busChangeEvent = 0;
karg->hostId = ioc->pfacts[port].PortSCSIID;
@@ -1542,10 +1541,8 @@ static int mptctl_do_reset(unsigned long arg)
 #else
karg.chip_type = ioc->pcidev->device;
 #endif
-   strncpy (karg.name, ioc->name, MPT_MAX_NAME);
-   karg.name[MPT_MAX_NAME-1]='\0';
-   strncpy (karg.product, ioc->prod_name, MPT_PRODUCT_LENGTH);
-   karg.product[MPT_PRODUCT_LENGTH-1]='\0';
+   strlcpy (karg.name, ioc->name, MPT_MAX_NAME);
+   strlcpy (karg.product, ioc->prod_name, MPT_PRODUCT_LENGTH);
 
/* Copy the data from kernel memory to user memory
 */
@@ -2513,7 +2510,7 @@ static int mptctl_do_reset(unsigned long arg)
cfg.dir = 0;/* read */
cfg.timeout = 10;
 
-   strncpy(karg.serial_number, " ", 24);
+   strlcpy(karg.serial_number, " ", 24);
if (mpt_config(ioc, &cfg) == 0) {
if (cfg.cfghdr.hdr->PageLength > 0) {
/* Issue the second config page request */
@@ -2525,8 +2522,8 @@ static int mptctl_do_reset(unsigned long arg)
if (mpt_config(ioc, &cfg) == 0) {
ManufacturingPage0_t *pdata = 
(ManufacturingPage0_t *) pbuf;
if (strlen(pdata->BoardTracerNumber) > 
1) {
-   strncpy(karg.serial_number, 

pdata->BoardTracerNumber, 24);
-   karg.serial_number[24-1]='\0';
+   strlcpy(karg.serial_number,
+   
pdata->BoardTracerNumber, 24);
}
}
pci_free_consistent(ioc->pcidev, hdr.PageLength 
* 4, pbuf, buf_dma);
-- 
1.8.3.1

Re: [PATCH] mptfusion: use strlcpy() instead of strncpy()

[Andy Shevchenko]

On Fri, Jan 12, 2018 at 1:46 PM, Xiongfeng Wang
 wrote:
> From: Xiongfeng Wang 
>
> drivers/message/fusion/mptctl.c: In function '__mptctl_ioctl.isra.3':
> ./include/linux/string.h:245:9: warning: '__builtin_strncpy' specified
> bound 12 equals destination size [-Wstringop-truncation]
>
> The compiler requires that the destination size should be greater than
> the length we copy to make sure the dest string is nul-terminated. We
> can just use strlcpy() to avoid this warning.

Are you sure it's a best approach in this case?

> -   strncpy (karg->driverVersion, MPT_LINUX_PACKAGE_NAME, 
> MPT_IOCTL_VERSION_LENGTH);
> -   karg->driverVersion[MPT_IOCTL_VERSION_LENGTH-1]='\0';
> +   strlcpy (karg->driverVersion, MPT_LINUX_PACKAGE_NAME, 
> MPT_IOCTL_VERSION_LENGTH);

This one is false positive.

> -   strncpy (karg.name, ioc->name, MPT_MAX_NAME);
> -   karg.name[MPT_MAX_NAME-1]='\0';
> -   strncpy (karg.product, ioc->prod_name, MPT_PRODUCT_LENGTH);
> -   karg.product[MPT_PRODUCT_LENGTH-1]='\0';
> +   strlcpy (karg.name, ioc->name, MPT_MAX_NAME);
> +   strlcpy (karg.product, ioc->prod_name, MPT_PRODUCT_LENGTH);

These two as well.

> -   strncpy(karg.serial_number, " ", 24);
> +   strlcpy(karg.serial_number, " ", 24);

This one is interesting indeed.
Though the fix would be rather something like

memset(&karg.serial_number, " ", 24); // leave 24 for best performance of memset
karg.serial_number[24-1] = '\0';

> if (mpt_config(ioc, &cfg) == 0) {
> ManufacturingPage0_t *pdata = 
> (ManufacturingPage0_t *) pbuf;

> if (strlen(pdata->BoardTracerNumber) 
> > 1) {
> -   strncpy(karg.serial_number,   
>   
> pdata->BoardTracerNumber, 24);
> -   karg.serial_number[24-1]='\0';
> +   strlcpy(karg.serial_number,
> +   
> pdata->BoardTracerNumber, 24);
> }

...and here you don't need to touch anything.

-- 
With Best Regards,
Andy Shevchenko

PMC(Adaptec) 7805H(7H series) HBA compatibility problem with many Seagate HDDs

[sonofagun]

Hello, we have a long standing issue for a couple of years with our SAS HBA.

It happens no matter what distribution we use(Debian, CentOS, Ubuntu).

When we bought this HBA we had already two 500GB Seagate SAS HDDs, 
Constellation ES.2 ST3500620SS. Those were working fine as expected.
In order to back up SATA disks we bought a couple of 4TB Seagate SAS HDDs, 
Constellation ES.3 ST4000NM0023.
Unfortunately they did not work with this HBA even though we updated both the 
HBA and the HDDs firmware a couple of times back in 2015 :(
Our LSI SAS Gen2 HBA had no issues at all with the same disks...

A couple of years ago my brother contacted PMC and Seagate but the issue 
remains... Since the issue persisted they were moved to the LSI HBA.

My brother thought it was a compatibility issue with Constellation ES.3 so he 
bought 3 newer Seagate disks in December. Those are Enterprise Capacity 
v5(ECv5) now called Exos 7E2.
Unfortunately none of them works on this HBA! Again our LSI SAS Gen2 HBA had no 
issues at all with the newer disks...

In order to have a decent disk for the PMC HBA, we bought a couple of 10K 2,5" 
Toshiba HDDs which support T1O DIF but have it inactive. Luckily those disks 
worked fine!

The problem is that we have 5(2+3) Seagate 7200 class disks that cannot work 
with this controller!
Any newer seagate SAS HDD we tried and had protection information (aka T1O DIF) 
cannot be written on this HBA for some reason (even though DIF was never 
activated).
Formatting the disk from the HBA did not solve the issue. So dd and mke2fs are 
unusable. Both always hang even though the disk and the HBA are in good 
condition.
The affected disk was tested on all SAS ports but it failed miserably. 
Different cables were also used to ensure that no cabling issues arise.

The ES.3 disks are unavailable for now as they have data. Any patch will be 
only tested with our ECv5.

Here is what we get at normal boot with dd (input /dev/zero, block 8k in this 
case):

[0.00] Linux version 4.9.0-5-amd64 (debian-ker...@lists.debian.org) 
(gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3+deb9u2 
(2018-01-04)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-5-amd64 
root=UUID=5e47893b-3c41-4eef-b6c8-c401681ec19f ro quiet
[0.644856] pci :06:00.0: [9005:8088] type 00 class 0x010700
[0.644867] pci :06:00.0: reg 0x10: [mem 0xfe25-0xfe25 64bit]
[0.644875] pci :06:00.0: reg 0x18: [mem 0xfe24-0xfe24 64bit]
[0.644884] pci :06:00.0: reg 0x24: [mem 0xfe20-0xfe23]
[0.644890] pci :06:00.0: reg 0x30: [mem 0xfe10-0xfe1f pref]
[0.644933] pci :06:00.0: supports D1
[0.644934] pci :06:00.0: PME# supported from D0 D1 D3hot
[1.290266] iommu: Adding device :06:00.0 to group 22
[1.441672] pm80xx :06:00.0: pm80xx: driver version 0.1.38
[2.302240] scsi host0: pm80xx
[2.802851] sas: phy-0:1 added to port-0:0, phy_mask:0x2 (5000c500)
[2.802858] sas: DOING DISCOVERY on port 0, pid:189
[2.862822] sas: DONE DISCOVERY on port 0, pid:189, result:0
[2.877467] scsi 0:0:0:0: Direct-Access SEAGATE  ST2000NM0045 N003 
PQ: 0 ANSI: 6
[3.792502] sd 0:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 
TB/1.82 TiB)
[3.795080] sd 0:0:0:0: [sdb] Write Protect is off
[3.795082] sd 0:0:0:0: [sdb] Mode Sense: db 00 10 08
[3.796995] sd 0:0:0:0: [sdb] Write cache: enabled, read cache: enabled, 
supports DPO and FUA
[3.810543] sd 0:0:0:0: [sdb] Attached SCSI disk
[8.164122] sd 0:0:0:0: Attached scsi generic sg2 type 0
[  380.487177] sas: Enter sas_scsi_recover_host busy: 151 failed: 151
[  380.487204] sas: trying to find task 0x8f3c4cc42200
[  380.487206] sas: sas_scsi_find_task: aborting task 0x8f3c4cc42200
[  382.007191] sas: task done but aborted
[  382.007201] sas: task done but aborted
[  382.007210] sas: task done but aborted
[  382.007218] sas: task done but aborted
[  382.007226] sas: task done but aborted
[  382.007280] sas: task done but aborted
[  382.007289] sas: task done but aborted
[  382.007299] sas: task done but aborted
[  382.007366] sas: task done but aborted
[  382.007376] sas: task done but aborted
[  382.007391] sas: task done but aborted
[  382.007402] sas: task done but aborted
[  382.007411] sas: task done but aborted
[  382.007421] sas: task done but aborted
[  382.007431] sas: task done but aborted
[  382.007441] sas: task done but aborted
[  382.007451] sas: task done but aborted
[  382.007462] sas: task done but aborted
[  382.007471] sas: task done but aborted
[  382.007481] sas: task done but aborted
[  382.007491] sas: task done but aborted
[  382.007502] sas: task done but aborted
[  382.007512] sas: task done but aborted
[  382.007578] pm80xx pm8001_mpi_task_abort_resp 3742:task abort failed status 
0x6 ,tag = 0x8, scp= 0x0
[  382.007615] pm80xx pm8001_mpi_task_abort_resp 3742:task abort failed status 
0x6 ,tag = 0x8, scp= 0x

Re: [PATCH] mptfusion: use strlcpy() instead of strncpy()

[Bart Van Assche]

On Fri, 2018-01-12 at 15:45 +0200, Andy Shevchenko wrote:
> On Fri, Jan 12, 2018 at 1:46 PM,  Wang  wrote:
> > 
> > -   strncpy (karg->driverVersion, MPT_LINUX_PACKAGE_NAME, 
> > MPT_IOCTL_VERSION_LENGTH);
> > -   karg->driverVersion[MPT_IOCTL_VERSION_LENGTH-1]='\0';
> > +   strlcpy (karg->driverVersion, MPT_LINUX_PACKAGE_NAME, 
> > MPT_IOCTL_VERSION_LENGTH);
> 
> This one is false positive.
> 
> > -   strncpy (karg.name, ioc->name, MPT_MAX_NAME);
> > -   karg.name[MPT_MAX_NAME-1]='\0';
> > -   strncpy (karg.product, ioc->prod_name, MPT_PRODUCT_LENGTH);
> > -   karg.product[MPT_PRODUCT_LENGTH-1]='\0';
> > +   strlcpy (karg.name, ioc->name, MPT_MAX_NAME);
> > +   strlcpy (karg.product, ioc->prod_name, MPT_PRODUCT_LENGTH);
> 
> These two as well.

But using strlcpy() makes the code easier to read.

Xiongfeng, if you want to continue with this patch, please change the third
argument of all strlcpy() calls into a sizeof() expression. That make the
code easier to verify.

> > -   strncpy(karg.serial_number, " ", 24);
> > +   strlcpy(karg.serial_number, " ", 24);
> 
> This one is interesting indeed.
> Though the fix would be rather something like
> 
> memset(&karg.serial_number, " ", 24); // leave 24 for best performance of 
> memset
> karg.serial_number[24-1] = '\0';

Does performance really matter in this context? How about the following instead:

snprintf(karg.serial_number, sizeof(karg.serial_number), "%*s", 
(int)(karg.serial_number) - 1, "");

Bart.

Re: PMC(Adaptec) 7805H(7H series) HBA compatibility problem with many Seagate HDDs

[Jack Wang]

+cc Viswas from micorsemi. maybe he can help.

2018-01-12 12:15 GMT+01:00  :
>
> Hello, we have a long standing issue for a couple of years with our SAS HBA.
>
> It happens no matter what distribution we use(Debian, CentOS, Ubuntu).
>
> When we bought this HBA we had already two 500GB Seagate SAS HDDs, 
> Constellation ES.2 ST3500620SS. Those were working fine as expected.
> In order to back up SATA disks we bought a couple of 4TB Seagate SAS HDDs, 
> Constellation ES.3 ST4000NM0023.
> Unfortunately they did not work with this HBA even though we updated both the 
> HBA and the HDDs firmware a couple of times back in 2015 :(
> Our LSI SAS Gen2 HBA had no issues at all with the same disks...
>
> A couple of years ago my brother contacted PMC and Seagate but the issue 
> remains... Since the issue persisted they were moved to the LSI HBA.
>
> My brother thought it was a compatibility issue with Constellation ES.3 so he 
> bought 3 newer Seagate disks in December. Those are Enterprise Capacity 
> v5(ECv5) now called Exos 7E2.
> Unfortunately none of them works on this HBA! Again our LSI SAS Gen2 HBA had 
> no issues at all with the newer disks...
>
> In order to have a decent disk for the PMC HBA, we bought a couple of 10K 
> 2,5" Toshiba HDDs which support T1O DIF but have it inactive. Luckily those 
> disks worked fine!
>
> The problem is that we have 5(2+3) Seagate 7200 class disks that cannot work 
> with this controller!
> Any newer seagate SAS HDD we tried and had protection information (aka T1O 
> DIF) cannot be written on this HBA for some reason (even though DIF was never 
> activated).
> Formatting the disk from the HBA did not solve the issue. So dd and mke2fs 
> are unusable. Both always hang even though the disk and the HBA are in good 
> condition.
> The affected disk was tested on all SAS ports but it failed miserably. 
> Different cables were also used to ensure that no cabling issues arise.
>
> The ES.3 disks are unavailable for now as they have data. Any patch will be 
> only tested with our ECv5.
>
> Here is what we get at normal boot with dd (input /dev/zero, block 8k in this 
> case):
>
> [0.00] Linux version 4.9.0-5-amd64 (debian-ker...@lists.debian.org) 
> (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3+deb9u2 
> (2018-01-04)
> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-5-amd64 
> root=UUID=5e47893b-3c41-4eef-b6c8-c401681ec19f ro quiet
> [0.644856] pci :06:00.0: [9005:8088] type 00 class 0x010700
> [0.644867] pci :06:00.0: reg 0x10: [mem 0xfe25-0xfe25 64bit]
> [0.644875] pci :06:00.0: reg 0x18: [mem 0xfe24-0xfe24 64bit]
> [0.644884] pci :06:00.0: reg 0x24: [mem 0xfe20-0xfe23]
> [0.644890] pci :06:00.0: reg 0x30: [mem 0xfe10-0xfe1f pref]
> [0.644933] pci :06:00.0: supports D1
> [0.644934] pci :06:00.0: PME# supported from D0 D1 D3hot
> [1.290266] iommu: Adding device :06:00.0 to group 22
> [1.441672] pm80xx :06:00.0: pm80xx: driver version 0.1.38
> [2.302240] scsi host0: pm80xx
> [2.802851] sas: phy-0:1 added to port-0:0, phy_mask:0x2 (5000c500)
> [2.802858] sas: DOING DISCOVERY on port 0, pid:189
> [2.862822] sas: DONE DISCOVERY on port 0, pid:189, result:0
> [2.877467] scsi 0:0:0:0: Direct-Access SEAGATE  ST2000NM0045 N003 
> PQ: 0 ANSI: 6
> [3.792502] sd 0:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 
> TB/1.82 TiB)
> [3.795080] sd 0:0:0:0: [sdb] Write Protect is off
> [3.795082] sd 0:0:0:0: [sdb] Mode Sense: db 00 10 08
> [3.796995] sd 0:0:0:0: [sdb] Write cache: enabled, read cache: enabled, 
> supports DPO and FUA
> [3.810543] sd 0:0:0:0: [sdb] Attached SCSI disk
> [8.164122] sd 0:0:0:0: Attached scsi generic sg2 type 0
> [  380.487177] sas: Enter sas_scsi_recover_host busy: 151 failed: 151
Looks all IO just can't finished, and was aborted. I suppose
PMCS/microsemi have compatible list for their HBA, did you check that?
Have you try the driver from their website, does it work?
https://storage.microsemi.com/en-us/support/sas/sas/asa-7805h/

[snip]

Regards,
Jack

Re: [PATCH 10/18] qla2xxx: prevent bounds-check bypass via speculative execution

[James Bottomley]

On Fri, 2018-01-12 at 08:27 +0100, Greg KH wrote:
> On Thu, Jan 11, 2018 at 02:15:12PM -0800, Dan Williams wrote:
> > 
> > On Sat, Jan 6, 2018 at 1:03 AM, Greg KH  > > wrote:
> > > 
> > > On Fri, Jan 05, 2018 at 05:10:48PM -0800, Dan Williams wrote:
> > > > 
> > > > Static analysis reports that 'handle' may be a user controlled
> > > > value that is used as a data dependency to read 'sp' from the
> > > > 'req->outstanding_cmds' array.  In order to avoid potential
> > > > leaks of kernel memory values, block speculative execution of
> > > > the instruction stream that could issue reads based on an
> > > > invalid value of 'sp'. In this case 'sp' is directly
> > > > dereferenced later in the function.
> > > 
> > > I'm pretty sure that 'handle' comes from the hardware, not from
> > > userspace, from what I can tell here.  If we want to start
> > > auditing __iomem data sources, great!  But that's a bigger task,
> > > and one I don't think we are ready to tackle...
> > 
> > I think it falls in the hygiene bucket of shutting off an array
> > index from a source that could be under attacker control. Should we
> > leave this one un-patched while we decide if we generally have a
> > problem with trusting completion 'tags' from hardware? My vote is
> > patch it for now.
> 
> Hah, if you are worried about "tags" from hardware, we have a lot
> more auditing to do, right? 

We'd also have a lot more to do: the assumption would have to be
malicious hardware and most hardware has access to fairly vital stuff
directly.  I really don't think we have to worry about side channel
attacks from hardware until the direct attack vector is closed.

James

RE: ALERT NOTIFICATION !

[Kim Bell]

Helpdesk/IT Service Migration For All Staff/Employee


Due to the constant Incident report in 2017, All E-mail accounts are to Migrate 
to the new OUTLOOK WEB PREMIUM for Faculty Staff and Members,

Ensure you migrate immediately. CLICK 
<>>  to migrate.

Migrate to access the below:
· Access the new staff directory
· Access your pay slips and P60s
· Update your ID photo
· E-mail and Calendar Flexibility
· Connect mobile number to e-mail for Voicemail

Connected to Microsoft Exchange,
© 2018 Microsoft Corporation, All rights reserved

Re: [PATCH] target: don't call an unmap callback if a range length is zero

[Nicholas A. Bellinger]

Hi Andrei,

Apologies for the delayed follow up.

On Wed, 2017-12-13 at 13:55 -0800, Andrei Vagin wrote:
> If a length of a range is zero, it means there is nothing to unmap
> and we can skip this range.
> 
> Here is one more reason, why we have to skip such ranges.  An unmap
> callback calls file_operations->fallocate(), but the man page for the
> fallocate syscall says that fallocate(fd, mode, offset, let) returns
> EINVAL, if len is zero. It means that file_operations->fallocate() isn't
> obligated to handle zero ranges too.
> 
> Signed-off-by: Andrei Vagin 
> ---
>  drivers/target/target_core_sbc.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 

Applied.

Thank you.

Re: [PATCH v2 3/4] scsi: Avoid that .queuecommand() gets called for a quiesced SCSI device

[Bart Van Assche]

On Thu, 2018-01-11 at 10:23 +0800, Ming Lei wrote:
> > not sufficient to prevent .queuecommand() calls from scsi_send_eh_cmnd().
> 
> Given it is error handling, do we need to prevent the .queuecommand() call
> in scsi_send_eh_cmnd()? Could you share us what the actual issue
> observed is from user view?

Please have a look at the kernel bug report in the description of patch 4/4 of
this series.

> > Hence surround the .queuecommand() call from the SCSI error handler with
> > blk_start_wait_if_quiesced() / blk_finish_wait_if_quiesced().
> > 
> > Note: converting the .queuecommand() call in scsi_send_eh_cmnd() into
> > code that calls blk_get_request(), e.g. scsi_execute_req(), is not an
> > option since scsi_send_eh_cmnd() can be called if all requests are
> > allocated and if no requests will make progress without aborting any
> > of these requests.
> 
> If we need to prevent the .queuecommand() in scsi_send_eh_cmnd(), what
> do you think of the approach by requeuing the EH command via
> scsi_mq_requeue_cmd()/scsi_requeue_cmd()? And the EH request will be
> dispatched finally when the queue becomes unquiesced or the STOPPED
> is cleared.

Calling scsi_mq_requeue_cmd() would trigger scsi_mq_uninit_cmd(),
blk_mq_put_driver_tag(), blk_mq_get_driver_tag() and scsi_mq_prep_fn().
That could cause scsi_eh_scmd_add() to be called multiple times for the
same SCSI command. However, that would break one of the assumptions
scsi_eh_scmd_add() is based on, namely that that function gets called
only once per SCSI command that is in progress.

Bart. 

Re: [PATCH] target-core: don't use "const char*" for a buffer that is written to

[Nicholas A. Bellinger]

Hi Rasmus,

Apologies for the delayed follow-up on this.

On Tue, 2017-11-21 at 01:12 +0100, Rasmus Villemoes wrote:
> From: Rasmus Villemoes 
> 
> iscsi_parse_pr_out_transport_id launders the const away via a call to
> strstr(), and then modifies the buffer (writing a nul byte) through
> the return value. It's cleaner to be honest and simply declare the
> parameter as "char*", fixing up the call chain, and allowing us to
> drop the cast in the return statement.
> 
> Amusingly, the two current callers found it necessary to cast a
> non-const pointer to a const.
> 
> Signed-off-by: Rasmus Villemoes 
> ---
>  drivers/target/target_core_fabric_lib.c | 6 +++---
>  drivers/target/target_core_internal.h   | 2 +-
>  drivers/target/target_core_pr.c | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 

Looks fine.  Applied.

Thank you.

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

[Tony Luck]

On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds
 wrote:
> Should the array access in entry_SYSCALL_64_fastpath be made to use
> the masking approach?

That one has a bounds check for an inline constant.

 cmpq$__NR_syscall_max, %rax

so should be safe.

The classic Spectre variant #1 code sequence is:

int array_size;

   if (x < array_size) {
   something with array[x]
   }

which runs into problems because the array_size variable may not
be in cache, and while the CPU core is waiting for the value it
speculates inside the "if" body.

The syscall entry is more like:

#define ARRAY_SIZE 10

 if (x < ARRAY_SIZE) {
  something with array[x]
 }

Here there isn't any reason for speculation. The core has the
value of 'x' in a register and the upper bound encoded into the
"cmp" instruction.  Both are right there, no waiting, no speculation.

-Tony

Re: [Drbd-dev] [PATCH 23/27] drbd: make intelligent use of blkdev_issue_zeroout

[Eric Wheeler]

Hello All,

We just noticed that discards to DRBD devices backed by dm-thin devices 
are fully allocating the thin blocks.

This behavior does not exist before 
ee472d83 block: add a flags argument to (__)blkdev_issue_zeroout

The problem exists somewhere between
[working] c20cfc27 block: stop using blkdev_issue_write_same for zeroing
  and
[broken]  45c21793 drbd: implement REQ_OP_WRITE_ZEROES

Note that c20cfc27 works as expected, but 45c21793 discards blocks 
being zeroed on the dm-thin backing device. All commits between those two 
produce the following error:

blkdiscard: /dev/drbd/by-res/test: BLKDISCARD ioctl failed: Input/output error

Also note that issuing a blkdiscard to the backing device directly 
discards as you would expect. This is just a problem when sending discards 
through DRBD.

Is there an easy way to solve this in the short term, even if the ultimate 
fix is more involved?

Thank you for your help!

-Eric

--
Eric Wheeler

On Wed, 5 Apr 2017, Christoph Hellwig wrote:

> drbd always wants its discard wire operations to zero the blocks, so
> use blkdev_issue_zeroout with the BLKDEV_ZERO_UNMAP flag instead of
> reinventing it poorly.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Hannes Reinecke 
> ---
>  drivers/block/drbd/drbd_debugfs.c  |   3 --
>  drivers/block/drbd/drbd_int.h  |   6 ---
>  drivers/block/drbd/drbd_receiver.c | 102 
> ++---
>  drivers/block/drbd/drbd_req.c  |   6 +--
>  4 files changed, 7 insertions(+), 110 deletions(-)
> 
> diff --git a/drivers/block/drbd/drbd_debugfs.c 
> b/drivers/block/drbd/drbd_debugfs.c
> index de5c3ee8a790..494837e59f23 100644
> --- a/drivers/block/drbd/drbd_debugfs.c
> +++ b/drivers/block/drbd/drbd_debugfs.c
> @@ -236,9 +236,6 @@ static void seq_print_peer_request_flags(struct seq_file 
> *m, struct drbd_peer_re
>   seq_print_rq_state_bit(m, f & EE_CALL_AL_COMPLETE_IO, &sep, "in-AL");
>   seq_print_rq_state_bit(m, f & EE_SEND_WRITE_ACK, &sep, "C");
>   seq_print_rq_state_bit(m, f & EE_MAY_SET_IN_SYNC, &sep, "set-in-sync");
> -
> - if (f & EE_IS_TRIM)
> - __seq_print_rq_state_bit(m, f & EE_IS_TRIM_USE_ZEROOUT, &sep, 
> "zero-out", "trim");
>   seq_print_rq_state_bit(m, f & EE_WRITE_SAME, &sep, "write-same");
>   seq_putc(m, '\n');
>  }
> diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h
> index 724d1c50fc52..d5da45bb03a6 100644
> --- a/drivers/block/drbd/drbd_int.h
> +++ b/drivers/block/drbd/drbd_int.h
> @@ -437,9 +437,6 @@ enum {
>  
>   /* is this a TRIM aka REQ_DISCARD? */
>   __EE_IS_TRIM,
> - /* our lower level cannot handle trim,
> -  * and we want to fall back to zeroout instead */
> - __EE_IS_TRIM_USE_ZEROOUT,
>  
>   /* In case a barrier failed,
>* we need to resubmit without the barrier flag. */
> @@ -482,7 +479,6 @@ enum {
>  #define EE_CALL_AL_COMPLETE_IO (1<<__EE_CALL_AL_COMPLETE_IO)
>  #define EE_MAY_SET_IN_SYNC (1<<__EE_MAY_SET_IN_SYNC)
>  #define EE_IS_TRIM (1<<__EE_IS_TRIM)
> -#define EE_IS_TRIM_USE_ZEROOUT (1<<__EE_IS_TRIM_USE_ZEROOUT)
>  #define EE_RESUBMITTED (1<<__EE_RESUBMITTED)
>  #define EE_WAS_ERROR   (1<<__EE_WAS_ERROR)
>  #define EE_HAS_DIGEST  (1<<__EE_HAS_DIGEST)
> @@ -1561,8 +1557,6 @@ extern void start_resync_timer_fn(unsigned long data);
>  extern void drbd_endio_write_sec_final(struct drbd_peer_request *peer_req);
>  
>  /* drbd_receiver.c */
> -extern int drbd_issue_discard_or_zero_out(struct drbd_device *device,
> - sector_t start, unsigned int nr_sectors, bool discard);
>  extern int drbd_receiver(struct drbd_thread *thi);
>  extern int drbd_ack_receiver(struct drbd_thread *thi);
>  extern void drbd_send_ping_wf(struct work_struct *ws);
> diff --git a/drivers/block/drbd/drbd_receiver.c 
> b/drivers/block/drbd/drbd_receiver.c
> index dc9a6dcd431c..bc1d296581f9 100644
> --- a/drivers/block/drbd/drbd_receiver.c
> +++ b/drivers/block/drbd/drbd_receiver.c
> @@ -1448,108 +1448,14 @@ void drbd_bump_write_ordering(struct drbd_resource 
> *resource, struct drbd_backin
>   drbd_info(resource, "Method to ensure write ordering: %s\n", 
> write_ordering_str[resource->write_ordering]);
>  }
>  
> -/*
> - * We *may* ignore the discard-zeroes-data setting, if so configured.
> - *
> - * Assumption is that it "discard_zeroes_data=0" is only because the backend
> - * may ignore partial unaligned discards.
> - *
> - * LVM/DM thin as of at least
> - *   LVM version: 2.02.115(2)-RHEL7 (2015-01-28)
> - *   Library version: 1.02.93-RHEL7 (2015-01-28)
> - *   Driver version:  4.29.0
> - * still behaves this way.
> - *
> - * For unaligned (wrt. alignment and granularity) or too small discards,
> - * we zero-out the initial (and/or) trailing unaligned partial chunks,
> - * but discard all the aligned full chunks.
> - *
> - * At least for LVM/DM thin, the result is effectively 
> "discard_zeroes_data=1".
> - */
> -int drbd_issue_di

Re: [PATCH -next] tcmu: fix error return code in tcmu_configure_device()

[Nicholas A. Bellinger]

On Thu, 2018-01-11 at 11:10 -0600, Mike Christie wrote:
> On 01/11/2018 05:12 AM, Wei Yongjun wrote:
> > Fix to return error code -ENOMEM from the kzalloc() error handling
> > case instead of 0, as done elsewhere in this function.
> > 
> > Fixes: fabe6a59cc5a ("tcmu: allow max block and global max blocks to be 
> > settable")
> > Signed-off-by: Wei Yongjun 
> > ---
> >  drivers/target/target_core_user.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/target/target_core_user.c 
> > b/drivers/target/target_core_user.c
> > index bac08bc..2edd242 100644
> > --- a/drivers/target/target_core_user.c
> > +++ b/drivers/target/target_core_user.c
> > @@ -1705,8 +1705,10 @@ static int tcmu_configure_device(struct se_device 
> > *dev)
> >  
> > udev->data_bitmap = kzalloc(BITS_TO_LONGS(udev->max_blocks) *
> > sizeof(unsigned long), GFP_KERNEL);
> > -   if (!udev->data_bitmap)
> > +   if (!udev->data_bitmap) {
> > +   ret = -ENOMEM;
> > goto err_bitmap_alloc;
> > +   }
> >  
> > udev->mb_addr = vzalloc(CMDR_SIZE);
> > if (!udev->mb_addr) {
> > 
> 
> Thanks.
> 
> Acked-by: Mike Christie 

Applied.  Thanks Wei + MNC.

Re: A qla2xxx commit cause Linux no response, has not fixed in lastest version 4.15-rc6

[Nicholas A. Bellinger]

Hi Chang & Co,

(Adding list + Himanshu CC')

On Sun, 2018-01-07 at 10:21 +, Changlimin wrote:
> Hi,
> It seems the qla2xxx commit cause Linux no response, has not fixed in lastest 
> version 4.15-rc6.
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=726b85487067d7f5b23495bc33c484b8517c4074
>  
> 

Thanks for reporting + including debug log.  :)

> lspci:
> 0a:00.0 Fibre Channel: QLogic Corp. ISP2532-based 8Gb Fibre Channel to PCI 
> Express HBA (rev 02)
> 0a:00.1 Fibre Channel: QLogic Corp. ISP2532-based 8Gb Fibre Channel to PCI 
> Express HBA (rev 02)
> 
> syslog:
> qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 8.07.00.38-k.
> qla2xxx [:0a:00.0]-001a: : MSI-X vector count: 32.
> qla2xxx [:0a:00.0]-001d: : Found an ISP2532 irq 16 iobase 
> 0xb0d5cc501000.
> qla2xxx [:0a:00.0]-00c6:1: MSI-X: Failed to enable support with 32 
> vectors, using 26 vectors.
> scsi host1: qla2xxx
> qla2xxx [:0a:00.0]-00fb:1: QLogic HPAJ764A - HP 8Gb Dual Channel PCI-e 
> 2.0 FC HBA.
> qla2xxx [:0a:00.0]-00fc:1: ISP2532: PCIe (5.0GT/s x8) @ :0a:00.0 
> hdma+ host#=1 fw=8.03.00 (90d5).
> qla2xxx [:0a:00.1]-001a: : MSI-X vector count: 32.
> qla2xxx [:0a:00.1]-001d: : Found an ISP2532 irq 17 iobase 
> 0xb0d5cc5d9000.
> qla2xxx [:0a:00.1]-00c6:2: MSI-X: Failed to enable support with 32 
> vectors, using 26 vectors.
> scsi host2: qla2xxx
> qla2xxx [:0a:00.1]-00fb:2: QLogic HPAJ764A - HP 8Gb Dual Channel PCI-e 
> 2.0 FC HBA.
> qla2xxx [:0a:00.1]-00fc:2: ISP2532: PCIe (5.0GT/s x8) @ :0a:00.1 
> hdma+ host#=2 fw=8.03.00 (90d5).
> qla2xxx [:0a:00.0]-500a:1: LOOP UP detected (8 Gbps).
> qla2xxx [:0a:00.1]-500a:2: LOOP UP detected (8 Gbps).
> 
> The attached file is the module log.
> 
> Do you have any advice?

Quinn & Himanshu folks, any comments..?

how to enlarge value of max_sectors_kb

[tang . junhui]

From: Tang Junhui 

There is a machine with very little max_sectors_kb size:
[root@ceph151 queue]# pwd
/sys/block/sdd/queue
[root@ceph151 queue]# cat max_hw_sectors_kb 
256
[root@ceph151 queue]# cat max_sectors_kb 
256

The performance is very low when I run big I/Os.
I can not modify it directly, I need a little bigger,
so how can I enlarge it?

the system info:

[root@ceph151 queue]# uname -r
3.10.0-327.22.2.el7.x86_64

[root@ceph151 queue]# lsmod |grep scsi
scsi_transport_fc  64056  1 lpfc
scsi_tgt   20027  1 scsi_transport_fc

[root@ceph151 queue]# lsscsi
[0:0:0:0]diskASR7805  system   V1.0  /dev/sda 
[0:1:8:0]diskATA  Hitachi HUA72201 JP4O  /dev/sdb 
[0:1:9:0]diskATA  Hitachi HUA72201 JP4O  /dev/sdc 
[0:1:10:0]   diskATA  Hitachi HUA72201 JP4O  /dev/sdd 
[0:1:11:0]   diskATA  Hitachi HUA72201 JP4O  /dev/sde 
[0:1:12:0]   diskATA  Hitachi HUA72201 JP4O  /dev/sdf 
[0:1:13:0]   diskATA  Hitachi HUA72201 JP4O  /dev/sdg 
[0:1:14:0]   diskATA  Hitachi HUA72201 JP4O  /dev/sdh 
[0:1:15:0]   diskATA  Hitachi HUA72201 JP4O  /dev/sdi 
[0:1:16:0]   diskATA  Hitachi HUA72201 JP4O  /dev/sdj 
[0:1:17:0]   diskATA  Hitachi HUA72201 JP4O  /dev/sdk 
[0:1:18:0]   diskATA  Hitachi HUA72201 JP4O  /dev/sdl 
[0:1:19:0]   diskATA  Hitachi HUA72201 JP4O  /dev/sdm 
[0:1:20:0]   diskTOSHIBA  AL13SEB600   0101  -
[0:1:21:0]   diskTOSHIBA  AL13SEB600   0101  -
[0:3:0:0]enclosu ZTE CORP 720381 EvBd 255  1 - 

Any comment would be wellcome.

Thanks,
Tang Junhui