head -r538966 on OrangePi+ 2ed: boot loader crashes when USB drive is present at power-on/boot
Without a USB drive present at power-on or
boot, the OPi+2e boots fine. (The USB drives
involved have a partition holding a ufs file
system and a partition holding a swap/aging
space.)
In all cases below, /boot/ is from the microsd
card. But the intended configuration is for
vfs.root.mountfrom to be used to direct the
stages after kernel-booting to the USB drive.
The output sequence related to the crash when
the USB drive is present looks like:
QUOTE
U-Boot SPL 2019.07 (Aug 02 2019 - 11:19:36 +)
DRAM: 2048 MiB
Trying to boot from MMC1
U-Boot 2019.07 (Aug 02 2019 - 11:19:36 +) Allwinner Technology
CPU: Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM: 2 GiB
MMC: Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c1'
mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1
Loading Environment from FAT... Unable to use mmc 1:1...
In:serial
Out: serial
Err: serial
Net: phy interface7
eth0: ethernet@1c3
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
Bus usb@1c1b400: USB OHCI 1.0
Bus usb@1c1c000: USB EHCI 1.00
Bus usb@1c1c400: USB OHCI 1.0
Bus usb@1c1d000: USB EHCI 1.00
Bus usb@1c1d400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 1 USB Device(s) found
scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
scanning bus usb@1c1c000 for devices... 1 USB Device(s) found
scanning bus usb@1c1c400 for devices... 1 USB Device(s) found
scanning bus usb@1c1d000 for devices... 2 USB Device(s) found
scanning bus usb@1c1d400 for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
199 bytes read in 1 ms (194.3 KiB/s)
## Executing script at 4310
384312 bytes read in 19 ms (19.3 MiB/s)
## Starting application at 0x4200 ...
Consoles: U-Boot console
Compatible U-Boot API signature found @0xb9f6ea60FreeBSD/armv7 U-Boot loader,
Revision 1.3
DRAM: 2048MB
Number of U-Boot devices: 2
U-Boot env: loaderdev not set, will probe all devices.
Found U-Boot device: disk
Probing all devices...
Checking unit=0 slice= partition=...data abort
pc : [<42009068>] lr : [<420603f8>]
reloc pc : []lr : []
sp : b9f649f8 ip : 42062900 fp : b9f64a28
r10: b9f64a58 r9 : 42062640 r8 : 420623c0
r7 : 420626c0 r6 : r5 : 42062650 r4 : 420626c0
r3 : r2 : 0980 r1 : r0 : 00ee
Flags: nZCv IRQs off FIQs off Mode SVC_32
Code: e3500080 1afffefb e5d801c2 e35000ee (059821c6)
Resetting CPU ...
resetting ...
END QUOTE
Stopping it earlier and using:
setenv loaderdev mmc 0
boot
avoids the problem because it avoids "probing" the
USB drive at the stage indicated above. But the
boot then actually uses:
vfs.root.mountfrom="ufs:/dev/gpt/BPIM3root"
in the /boot/loader.conf on the microsd card.
ufs:/dev/gpt/BPIM3root is a reference to the ufs
partition on the USB media. (With the mountfrom
commented out the microsd card is bootable by
itself.) So later the USB drive is put to use
successfully when the initial probing is avoided.
Looking in the /usr/src/stand/uboot/common/main.c
code shows:
static int
probe_disks(int devidx, int load_type, int load_unit, int load_slice,
int load_partition)
{
. . .
if (load_unit == -1) {
printf(" Probing all %s devices...\n",
device_typename(load_type));
/* Try each disk of given type in succession until one works. */
for (unit = 0; unit < UB_MAX_DEV; unit++) {
currdev.dd.d_unit = uboot_diskgetunit(load_type, unit);
if (currdev.dd.d_unit == -1)
break;
print_disk_probe_info();
open_result = devsw[devidx]->dv_open(&f, &currdev);
if (open_result == 0) {
printf(" good.\n");
return (0);
}
printf("\n");
}
return (-1);
}
. . .
}
So it appears that the crash is during the code involved
for the line:
open_result = devsw[devidx]->dv_open(&f, &currdev);
Note that the boot attempt reported "Probing all
devices..." so device_typename(load_type) came up with
"". (I've no clue if that is significant to the
issue or not.)
It appeared that /usr/src/stand/usb/storage/umass_loader.c
and its umass_disk_open and umass_disk_open_sub might
be involved and then code from the likes of:
/usr/src/sys/dev/usb/ --such as from usb_msctest.c for
usb_msc_read_capacity. (I stopped looking around
there: well outside areas I know how to interpret.)
For reference, I used the OPi+2e u-boot material from
my
Re: TLS certificates for NFS-over-TLS floating client
Miroslav Lachman wrote: >Hiroki Sato wrote on 2020/03/04 05:35: > [...] > >> I do not think it is a good idea to use a certificate with an >> embedded secret for authentication and/or authorization. >> >> In the case that the client offers a certificate upon establishing a >> TLS connection for authentication purpose, the authenticity will be >> checked on the server usually by using the CA certificate which was >> used to issue the client certificate. The CA cert must be put to >> somewhere the NFS server can read. >> >> The CA cert is secret. So if the NFS server can check the client >> certificate by the CA certificate, it means the NFS server can >> trust the client. I think no additional information is required. > >NFS (or any other server) should check list of revoked certificates too. >Otherwise you will not be able to deny access to user which you no >longer want to have an access. Yes, good point. I won't claim to understand this stuff, but from what I can see, all that is done is the CRL is appended to the CAfile (the one with the CA certificates are in being used for certificate verification via SSL__CTX_load_verify_locations(). (https://raymii.org/s/articles/OpenSSL_manually_verify_a_certificate_against_a_CRL.html shows a CAfile and CRLfile being concatenated and then used to verify a certificate.) There is code in sendmail that loads a CRL file separately, but it seems to just put it in the X509 store returned by SSL_CTX_get_cert_store(), which is the one where the CAfile certificates are stored via SSL_CTX_load_verify_locations(), I think? (It just seems easier to append it to CAfile than do this. The sendmail code uses poorly documented functions where the man page says "SSL_CTX_load_verify_locations()" normally takes care of this.) Does this sound right? rick > Authorization such as which mount point can be mounted by using the > client cert can be implemented by using the CN field or other X.509 > attributes, of course. It can be just a clear text. > > I think this is one of the most reliable and straightforward ways > because in most cases both NFS servers and the clients are under the > sysadmin's control. > > rm> Now, I'm not sure, but I don't think this certificate can be created via > rm> a trust authority such that it would "verify". However, the server can > rm> look for the "secret" in the certificate and allow the mount based on > that. > > In the way described above, to use TLS client authentication, the NFS > server admin has to have a certificate which allows to sign another > certificate. This means that the admin must be a CA or trusted > authority. > > In practice, one can generate a self-signed certificate by using > openssl(1) and use it as its CA certificate. He can issue > certificates signed by it for the NFS clients, and put his CA > certificate to somewhere the NFS server can read. Take a look on easy-rsa https://www.freshports.org/security/easy-rsa/ It is used for example by OpenVPN to create private CA and sign certificates of clients. It is good starting point to understand what and how can work. > rm> Also, even if the NFS client/server have fixed IP addresses with well > known > rm> DNS names, it isn't obvious to me how signed certificates can be acquired > rm> for them? > rm> (Lets Encrypt expects the Acme protocol to work and that seems to be > rm> web site/http specific?) > > TLS certificates do not always have (or do not need to have) a domain > name as an attribute. Data in attributes are restricted depending on > the purpose, so certificates issued by Let's Encrypt can have only > domain names (CN or Subject Alternative Name), for example. An > example which is not supported by Let's Encrypt is a certificate for > S/MIME email encryption which has an email address. Kind regards Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
