# freebsd kernel crashes while trying to mount write protected usbkey



## petrl (Nov 25, 2017)

Hi, 

I am not sure if this is a "KERNEL" bug, but every time when I just plug the write protected USB key ( for example genuine Windows 10 installation key - I am trying to install Windows 10 into VirtualBos )  my systems crashes and reboots itself.

```
FreeBSD m4700 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017   [email]root@releng2.nyi.freebsd.org[/email]:/usr/obj/usr/src/sys/GENERIC  amd64
```

Mate Desktop with Polkit settings to auto-mount usb keys.

The only way how to avoid the immediate system crash/reboot is to force mount usb key with ReadOnly option plus auto-mount Polkit policy disabled. Therefore is there any kernel-level-method, to detect correctly write protected keys and mount them read-only automatically? 

Or it's just a bug and it should be "reported" to devs instead ?

Thank you for your help.

PetrL

System log:

```
ugen2.4: <KDI-MSFT Windows 10> at usbus2
umass1 on uhub4
umass1: <KDI-MSFT Windows 10, class 0/0, rev 2.10/1.10, addr 4> on usbus2
umass1:  SCSI over Bulk-Only; quirks = 0x8100
umass1:4:1: Attached to scbus4
da1 at umass-sim1 bus 1 scbus4 target 0 lun 0
da1: <KDI-MSFT Windows 10 PMAP> Removable Direct Access SPC-4 SCSI device
da1: Serial Number 001A92053F4DB0B0B27403F8
da1: 40.000MB/s transfers
da1: 14784MB (30277632 512 byte sectors)
da1: quirks=0x2<NO_6_BYTE>
(da1:umass-sim1:1:0:0): WRITE(10). CDB: 2a 00 00 00 14 a0 00 00 08 00
(da1:umass-sim1:1:0:0): CAM status: SCSI Status Error
(da1:umass-sim1:1:0:0): SCSI status: Check Condition
[B](da1:umass-sim1:1:0:0): SCSI sense: DATA PROTECT asc:27,0 (Write protected)[/B]
(da1:umass-sim1:1:0:0): Error 13, Unretryable error
g_vfs_done():da1s1[WRITE(offset=1654784, length=4096)]error = 13
(da1:umass-sim1:1:0:0): WRITE(10). CDB: 2a 00 00 00 14 a0 00 00 08 00
(da1:umass-sim1:1:0:0): CAM status: SCSI Status Error
(da1:umass-sim1:1:0:0): SCSI status: Check Condition
(da1:umass-sim1:1:0:0): SCSI sense: DATA PROTECT asc:27,0 (Write protected)
(da1:umass-sim1:1:0:0): Error 13, Unretryable error
g_vfs_done():da1s1[WRITE(offset=1654784, length=4096)]error = 13
(da1:umass-sim1:1:0:0): WRITE(10). CDB: 2a 00 00 00 14 a0 00 00 08 00
(da1:umass-sim1:1:0:0): CAM status: SCSI Status Error
(da1:umass-sim1:1:0:0): SCSI status: Check Condition
(da1:umass-sim1:1:0:0): SCSI sense: DATA PROTECT asc:27,0 (Write protected)
(da1:umass-sim1:1:0:0): Error 13, Unretryable error
g_vfs_done():da1s1[WRITE(offset=1654784, length=4096)]error = 13
fsync: giving up on dirty 0xfffff8005152fb10: tag devfs, type VCHR
    usecount 1, writecount 0, refcount 1850 mountedhere 0xfffff8005170ae00
    flags (VI_ACTIVE)
    v_object 0xfffff8000d03a2d0 ref 0 pages 1848 cleanbuf 1847 dirtybuf 1
    lock type devfs: UNLOCKED
        dev da1s1

[B]Fatal trap 9: general protection fault while in kernel mode[/B]
cpuid = 0; apic id = 00
instruction pointer     = 0x20:0xffffffff809c0c2b
stack pointer           = 0x28:0xfffffe04648448e0
frame pointer           = 0x28:0xfffffe0464844910
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 27 (syncer)
trap number             = 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff80aada97 at kdb_backtrace+0x67
#1 0xffffffff80a6bb76 at vpanic+0x186
#2 0xffffffff80a6b9e3 at panic+0x43
#3 0xffffffff80edf832 at trap_fatal+0x322
#4 0xffffffff80edee9e at trap+0x5e
#5 0xffffffff80ec3641 at calltrap+0x8
#6 0xffffffff80b07086 at bufwrite+0x256
#7 0xffffffff80b1889e at vop_stdfsync+0x19e
#8 0xffffffff8104cc59 at VOP_FSYNC_APV+0x89
#9 0xffffffff80b2e28a at sched_sync+0x4fa
#10 0xffffffff80a2f815 at fork_exit+0x85
#11 0xffffffff80ec3b7e at fork_trampoline+0xe
```


----------



## k.jacker (Nov 28, 2017)

Hei PetrL,

I don't know of any way to writeprotect a filesystem in general.
There are hardware switches and of course the possibility to mount a filesystem read-only.

Only thing I can imagine is that MS uses some none-standard changes in the usb key's MBR to make it impossible to write to it ...and crash FreeBSD.

<oops just my opinion>MS has allways been ignoring standards, so as long as crashing only occurs with that device that holds some MS cooked none-standard MBR-like partition table, don't blame FreeBSD 
</oops just my opinion>

If you're able to mount that usb key read-only, just install Windows in VirtualBox and you're good.
Or maybe just mount a .iso file in VirtualBox, I think they can be downloaded from MS as long as you have a legit serial-number.
Not sure though, not using Windows.

Greetings,
Matthias


----------



## ralphbsz (Nov 29, 2017)

Please report this as a kernel bug.  Posting it here does not make sure that kernel developers will see this.


----------

