Re: TLS certificates for NFS-over-TLS floating client
So ok, it's good to code to RFCs. OTOH, state actors are a thing now. Alice & Bob's protocols need to be perfect. State actors watch for mistakes. Here I commit heresy, by A) top posting, and B) by just saying, why not make it easy, first, to tunnel NFSv4 sessions through e.g. net/wireguard or sysutils/spiped? NFS is point to point. Security infrastructure that actually works understands the shared secret model. Not going to argue further. I'm a grateful letsencrypt consumer. Rick is a hero for his NFS work. I use his code every day. Best, Russell On 2020-03-19 16:41, Rick Macklem wrote: John-Mark Gurney wrote: Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 +: I am slowly trying to understand TLS certificates and am trying to figure out how to do the following: -> For an /etc/exports file with... /home -tls -network 192.168.1.0 -mask 255.255.255.0 /home -tlscert Are you looking at implementing draft-cel-nfsv4-rpc-tls? Yes. The 2 week out of date (I can only do commits once in a while these days) can be found in FreeBSD's subversion under base/projects/nfs-over-tls. This syntax isn't implemented yet, but the thinking is that clients on the 192.168.1 subnet would use TLS, but would not require a certificate. For access from anywhere else, the client(s) would be required to have a certificate. A typical client mounting from outside of the subnet might be my laptop, which is using wifi and has no fixed IP/DNS name. --> How do you create a certificate that the laptop can use, which the NFS server can trust enough to allow the mount? My thinking is that a "secret" value can be put in the certificate that the NFS server can check for. The simplest way would be a fairly long list of random characters in the organizationName and/or organizationUnitName field(s) of the subject name. Alternately, it could be a newly defined extension for X509v3, I think? Now, I'm not sure, but I don't think this certificate can be created via a trust authority such that it would "verify". However, the server can look for the "secret" in the certificate and allow the mount based on that. Does this sound reasonable? Without a problem statement or what you're trying to accomplish, it's hard to say if it is. The problem I was/am trying to solve was a way for NFS clients without a fixed IP/DNS name could have a certificate to allow access to the NFS server. As suggested by others, having a site local CA created by the NFS admin. seemed to be the best solution. The server can verify that the certificate was issued by the local CA. Unfortunately, if the client is compromised and the certificate is copied to another client, that client would gain access. --> I've thought of having the client keep the certificate encrypted in a file and require the "user" of the client type in a passphrase to unencrypt the certificate so that it can be used by the daemon in the client that handles the client side of the TLS handshake, but I have not implemented this. --> This would at least subvert the simple case of the certificate file being copied to a different client and being used to mount the NFS server, but if the client is compromised, then the passphrase could be captured and... Also, even if the NFS client/server have fixed IP addresses with well known DNS names, it isn't obvious to me how signed certificates can be acquired for them? (Lets Encrypt expects the Acme protocol to work and that seems to be web site/http specific?) There is DNS challenges that can be used. I use them to obtain certs for SMTP and SIP servers... using nsupdate, this is relatively easy to automate pushing the challenges to a DNS server, and I now use DNS challenges for everything, including https. Since my internet connection is a single dynamically assigned IP from the phone company, I doubt this would work for me (which I why I say I don't know how to do this). I suspect there are ways and it would be nice if you could document this, so I can put it in a howto document. - An actual example using the nsupdate command would be nice. Thanks, rick Thanks for any help with this, rick Let me know if you'd like to hop on a call about this. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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" ___ 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"
Re: VirtualBox segmentation fault, FreeBSD-CURRENT r359068
On Thu, Mar 19, 2020 at 12:11 PM Graham Perrin wrote: > > Is this maybe related to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244847 or should I > make a separate bug report? > Please throw a tentative "Me too" on that PR; I'm investigating it, then we'll see if they're related or requires yet another PR. ___ 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"
Re: TLS certificates for NFS-over-TLS floating client
John-Mark Gurney wrote: >Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 +: >> I am slowly trying to understand TLS certificates and am trying to figure >> out how to do the following: >> -> For an /etc/exports file with... >> /home -tls -network 192.168.1.0 -mask 255.255.255.0 >> /home -tlscert > >Are you looking at implementing draft-cel-nfsv4-rpc-tls? Yes. The 2 week out of date (I can only do commits once in a while these days) can be found in FreeBSD's subversion under base/projects/nfs-over-tls. >> This syntax isn't implemented yet, but the thinking is that clients on the >> 192.168.1 subnet would use TLS, but would not require a certificate. >> For access from anywhere else, the client(s) would be required to have a >> certificate. >> >> A typical client mounting from outside of the subnet might be my laptop, >> which is using wifi and has no fixed IP/DNS name. >> --> How do you create a certificate that the laptop can use, which the NFS >>server can trust enough to allow the mount? >> My thinking is that a "secret" value can be put in the certificate that the >> NFS >> server can check for. >> The simplest way would be a fairly long list of random characters in the >> organizationName and/or organizationUnitName field(s) of the subject name. >> Alternately, it could be a newly defined extension for X509v3, I think? >> >> Now, I'm not sure, but I don't think this certificate can be created via >> a trust authority such that it would "verify". However, the server can >> look for the "secret" in the certificate and allow the mount based on that. >> >> Does this sound reasonable? > >Without a problem statement or what you're trying to accomplish, it's >hard to say if it is. The problem I was/am trying to solve was a way for NFS clients without a fixed IP/DNS name could have a certificate to allow access to the NFS server. As suggested by others, having a site local CA created by the NFS admin. seemed to be the best solution. The server can verify that the certificate was issued by the local CA. Unfortunately, if the client is compromised and the certificate is copied to another client, that client would gain access. --> I've thought of having the client keep the certificate encrypted in a file and require the "user" of the client type in a passphrase to unencrypt the certificate so that it can be used by the daemon in the client that handles the client side of the TLS handshake, but I have not implemented this. --> This would at least subvert the simple case of the certificate file being copied to a different client and being used to mount the NFS server, but if the client is compromised, then the passphrase could be captured and... >> Also, even if the NFS client/server have fixed IP addresses with well known >> DNS names, it isn't obvious to me how signed certificates can be acquired >> for them? >> (Lets Encrypt expects the Acme protocol to work and that seems to be >> web site/http specific?) > >There is DNS challenges that can be used. I use them to obtain certs >for SMTP and SIP servers... using nsupdate, this is relatively easy to >automate pushing the challenges to a DNS server, and I now use DNS >challenges for everything, including https. Since my internet connection is a single dynamically assigned IP from the phone company, I doubt this would work for me (which I why I say I don't know how to do this). I suspect there are ways and it would be nice if you could document this, so I can put it in a howto document. - An actual example using the nsupdate command would be nice. Thanks, rick > Thanks for any help with this, rick Let me know if you'd like to hop on a call about this. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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"
Re: HOWTO donate CPU to the fight against the Corona-virus
Hi! On 3/19/20 11:04 PM, Mateusz Piotrowski wrote: On 3/19/20 8:57 AM, Alexander Leidinger via freebsd-stable wrote: if someone wants to donate some FreeBSD based CPU resources to the fight against the Corona-virus, here is a quick HOWTO in terms of installing the Folding@Home client on FreeBSD: https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-freebsd-foldinghome/ I tested this on a recent -current. If you are interested in how this helps in the fight against the virus, please refer to the https://foldingathome.org/ website. In short and over-simplified: they search for vaccines. I've got an almost finished port of this software. I'll post a patch soonish. The patch is now on Phabricator open to reviews & ready to be tested: https://reviews.freebsd.org/D24127 Cheers, Mateusz ___ 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"
Re: HOWTO donate CPU to the fight against the Corona-virus
Hi, On 3/19/20 8:57 AM, Alexander Leidinger via freebsd-stable wrote: Hi, if someone wants to donate some FreeBSD based CPU resources to the fight against the Corona-virus, here is a quick HOWTO in terms of installing the Folding@Home client on FreeBSD: https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-freebsd-foldinghome/ I tested this on a recent -current. If you are interested in how this helps in the fight against the virus, please refer to the https://foldingathome.org/ website. In short and over-simplified: they search for vaccines. Bye, Alexander. I've got an almost finished port of this software. I'll post a patch soonish. Thanks so much for your blog post! Cheers! Mateusz ___ 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"
Re: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 +: > I am slowly trying to understand TLS certificates and am trying to figure > out how to do the following: > -> For an /etc/exports file with... > /home -tls -network 192.168.1.0 -mask 255.255.255.0 > /home -tlscert Are you looking at implementing draft-cel-nfsv4-rpc-tls? > This syntax isn't implemented yet, but the thinking is that clients on the > 192.168.1 subnet would use TLS, but would not require a certificate. > For access from anywhere else, the client(s) would be required to have a > certificate. > > A typical client mounting from outside of the subnet might be my laptop, > which is using wifi and has no fixed IP/DNS name. > --> How do you create a certificate that the laptop can use, which the NFS >server can trust enough to allow the mount? > My thinking is that a "secret" value can be put in the certificate that the > NFS > server can check for. > The simplest way would be a fairly long list of random characters in the > organizationName and/or organizationUnitName field(s) of the subject name. > Alternately, it could be a newly defined extension for X509v3, I think? > > Now, I'm not sure, but I don't think this certificate can be created via > a trust authority such that it would "verify". However, the server can > look for the "secret" in the certificate and allow the mount based on that. > > Does this sound reasonable? Without a problem statement or what you're trying to accomplish, it's hard to say if it is. > Also, even if the NFS client/server have fixed IP addresses with well known > DNS names, it isn't obvious to me how signed certificates can be acquired > for them? > (Lets Encrypt expects the Acme protocol to work and that seems to be > web site/http specific?) There is DNS challenges that can be used. I use them to obtain certs for SMTP and SIP servers... using nsupdate, this is relatively easy to automate pushing the challenges to a DNS server, and I now use DNS challenges for everything, including https. > Thanks for any help with this, rick Let me know if you'd like to hop on a call about this. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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"
Re: head -r538966 on OrangePi+ 2ed: boot loader crashes when USB drive is present at power-on/boot: its a misaligned access by code from -r354746
On 2020-Mar-19, at 02:00, Toomas Soome wrote: > I think this should fix it. We need to create copy of dos partition array, so > we will get proper alignment. > > > tsoome@freebsd-2:/usr/src % svn diff stand/common/part.c > Index: stand/common/part.c > === > --- stand/common/part.c (revision 359099) > +++ stand/common/part.c (working copy) > @@ -654,6 +654,7 @@ > int has_ext; > #endif > table = NULL; > + dp = NULL; > buf = malloc(sectorsize); > if (buf == NULL) > return (NULL); > @@ -708,7 +709,11 @@ > goto out; > } > /* Check that we have PMBR. Also do some validation. */ > - dp = (struct dos_partition *)(buf + DOSPARTOFF); > + dp = malloc(NDOSPART * sizeof(struct dos_partition)); > + if (dp == NULL) > + goto out; > + bcopy(buf + DOSPARTOFF, dp, NDOSPART * sizeof(struct dos_partition)); > + > /* >* In mac we can have PMBR partition in hybrid MBR; >* that is, MBR partition which has DOSPTYP_PMBR entry defined as > @@ -770,6 +775,7 @@ > #endif /* LOADER_MBR_SUPPORT */ > #endif /* LOADER_MBR_SUPPORT || LOADER_GPT_SUPPORT */ > out: > + free(dp); > free(buf); > return (table); > } > tsoome@freebsd-2:/usr/src % That is working for me: the OPi+2e now boots with the USB drive plugged in ahead of time, without manual intervention to assign loaderdev : FreeBSD/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=... good. Booting from disk0p1: Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local Loading kernel... /boot/kernel/kernel text=0x90b3fc data=0xa85a8 data=0x0+0x20 syms=[0x4+0xa1660+0x4+0x113e7c] Loading configured modules... /boot/kernel/umodem.ko text=0x1520 text=0xf10 data=0x234+0x4 syms=[0x4+0xe70+0x4+0xa74] loading required module 'ucom' /boot/kernel/ucom.ko text=0x1714 text=0x2c7c data=0x484+0x838 syms=[0x4+0x13e0+0x4+0xbac] /boot/entropy size=0x1000 Hit [Enter] to boot immediately, or any other key for command prompt. . . . Thanks! > . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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"
Re: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote on 2020/03/19 03:09: Miroslav Lachman wrote: [...] 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 I think it would be better to have it in a separate file as Apache does https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcarevocationfile Seems more convenient to have CA file write protected (read only) and then separate file for list of revoked client certificates, maybe somewhere else than CA certificate. 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"
Re: head -r538966 on OrangePi+ 2ed: boot loader crashes when USB drive is present at power-on/boot: its a misaligned access by code from -r354746
I think this should fix it. We need to create copy of dos partition array, so
we will get proper alignment.
tsoome@freebsd-2:/usr/src % svn diff stand/common/part.c
Index: stand/common/part.c
===
--- stand/common/part.c (revision 359099)
+++ stand/common/part.c (working copy)
@@ -654,6 +654,7 @@
int has_ext;
#endif
table = NULL;
+ dp = NULL;
buf = malloc(sectorsize);
if (buf == NULL)
return (NULL);
@@ -708,7 +709,11 @@
goto out;
}
/* Check that we have PMBR. Also do some validation. */
- dp = (struct dos_partition *)(buf + DOSPARTOFF);
+ dp = malloc(NDOSPART * sizeof(struct dos_partition));
+ if (dp == NULL)
+ goto out;
+ bcopy(buf + DOSPARTOFF, dp, NDOSPART * sizeof(struct dos_partition));
+
/*
* In mac we can have PMBR partition in hybrid MBR;
* that is, MBR partition which has DOSPTYP_PMBR entry defined as
@@ -770,6 +775,7 @@
#endif /* LOADER_MBR_SUPPORT */
#endif /* LOADER_MBR_SUPPORT || LOADER_GPT_SUPPORT */
out:
+ free(dp);
free(buf);
return (table);
}
tsoome@freebsd-2:/usr/src %
> On 19. Mar 2020, at 10:20, Mark Millard wrote:
>
> [I built with -DDEBUG -DDISK_DEBUG -DPART_DEBUG and show
> with some extra output as well. It shows that a misaligned
> access causes the crash. The access in question is from
> head -r354746 code additions.]
>
> On 2020-Mar-18, at 13:36, Mark Millard wrote:
>
>> 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
>> . . .
>> END QUOTE
>
> I'm replacing the original quote with
> better information.
>
> First I quote the definition of dos_partition
> for reference:
>
> struct dos_partition {
>unsigned char dp_flag;/* bootstrap flags */
>unsigned char dp_shd; /* starting head */
>unsigned char dp_ssect; /* starting sector */
>unsigned char dp_scyl;/* starting cylinder */
>unsigned char dp_typ; /* partition type */
>unsigned char dp_ehd; /* end head */
>unsigned char dp_esect; /* end sector */
>unsigned char dp_ecyl;/* end cylinder */
>uint32_tdp_start; /* absolute starting sector number */
>uint32_tdp_size;/* partition size in sectors */
> };
>
> Note that access to dp_start or dp_size
> requires address%4==0 alignment but the
> other fields do not. This is important for
> [i].dp_start reported in the below (and
> then dp[i].dp_start is accessed in the code).
> I also had it report dp, which shows that
> dp has dp%4!=0 as well.
>
>
>
> Here is with -DDEBUG and -DDISK_DEBUG -DPART_DEBUG
> in place for the code (with some extra debug output
> added):
>
> FreeBSD/armv7 U-Boot loader, Revision 1.3
>
> signature:
> version = 1
> checksum = 0x98de198b
> sc entry = 0xbdf8cb01
>
> addresses info:
> _etext (sdata) = 0x4204fdb4
> _edata = 0x4205ebb8
> __sbss_start = 0x4205ec28
> __sbss_end = 0x4205ec28
> __sbss_start = 0x4205ec28
> _end = 0x42062aa0
> syscall entry = 0xbdf8cb01
> DRAM: 2048MB
> Number of U-Boot devices: 2
> U-Boot env: loaderdev not set, will probe all devices.
> stor_init(): storage devices found: 2
> Found U-Boot device: disk
> Probing all devices...
> Checking unit=0 slice= partition=...disk_open: disk0s0: unit 0,
> slice 0, partition -2 => 0x420631c0
> stor_readdev(): reading blk=0 size=1 @ 0x420633c0
> stor_readdev(): reading blk=64 size=1 @ 0x420636c0
> stor_readdev(): reading blk=1 size=1 @ 0x420636c0
> ptable_open: BEFORE NDOSPART loop #1
> ptable_open: dp=0x4206357e
> ptable_open: IN NDOSPART loop #1 after 1st if
> ptable_open: IN NDOSPART loop #1: [i].dp_start=0x42063586
> data abort
> pc : [<42009350>] lr : [<42009348>]
> reloc pc : []lr : []
> sp : b9f649e8 ip : 4205e200 fp : b9f64a18
> r10: 42063640 r9 : b9f64a50 r8 : 420633c0
> r7 : 420636c0 r6 : 4200818c r5 : 4205cd95 r4 : 42063586
> r3 : bdf8cdf7 r2 : 000a r1 : 01c28000 r0 : 00ee
> Flags: nZCv IRQs off FIQs off Mode SVC_32
> Code: e08f eb0114af e5d801c2 e35000ee (0594)
> Resetting CPU ...
>
> resetting ...
>
>
> My extra messages are from:
>
> # svnlite diff /usr/src/stand/common/part.c
> Index: /usr/src/stand/common/part.c
> ===
> ---
Re: head -r538966 on OrangePi+ 2ed: boot loader crashes when USB drive is present at power-on/boot: its a misaligned access by code from -r354746
[I built with -DDEBUG -DDISK_DEBUG -DPART_DEBUG and show
with some extra output as well. It shows that a misaligned
access causes the crash. The access in question is from
head -r354746 code additions.]
On 2020-Mar-18, at 13:36, Mark Millard wrote:
> 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
> . . .
> END QUOTE
I'm replacing the original quote with
better information.
First I quote the definition of dos_partition
for reference:
struct dos_partition {
unsigned char dp_flag;/* bootstrap flags */
unsigned char dp_shd; /* starting head */
unsigned char dp_ssect; /* starting sector */
unsigned char dp_scyl;/* starting cylinder */
unsigned char dp_typ; /* partition type */
unsigned char dp_ehd; /* end head */
unsigned char dp_esect; /* end sector */
unsigned char dp_ecyl;/* end cylinder */
uint32_tdp_start; /* absolute starting sector number */
uint32_tdp_size;/* partition size in sectors */
};
Note that access to dp_start or dp_size
requires address%4==0 alignment but the
other fields do not. This is important for
[i].dp_start reported in the below (and
then dp[i].dp_start is accessed in the code).
I also had it report dp, which shows that
dp has dp%4!=0 as well.
Here is with -DDEBUG and -DDISK_DEBUG -DPART_DEBUG
in place for the code (with some extra debug output
added):
FreeBSD/armv7 U-Boot loader, Revision 1.3
signature:
version = 1
checksum = 0x98de198b
sc entry = 0xbdf8cb01
addresses info:
_etext (sdata) = 0x4204fdb4
_edata = 0x4205ebb8
__sbss_start = 0x4205ec28
__sbss_end = 0x4205ec28
__sbss_start = 0x4205ec28
_end = 0x42062aa0
syscall entry = 0xbdf8cb01
DRAM: 2048MB
Number of U-Boot devices: 2
U-Boot env: loaderdev not set, will probe all devices.
stor_init(): storage devices found: 2
Found U-Boot device: disk
Probing all devices...
Checking unit=0 slice= partition=...disk_open: disk0s0: unit 0,
slice 0, partition -2 => 0x420631c0
stor_readdev(): reading blk=0 size=1 @ 0x420633c0
stor_readdev(): reading blk=64 size=1 @ 0x420636c0
stor_readdev(): reading blk=1 size=1 @ 0x420636c0
ptable_open: BEFORE NDOSPART loop #1
ptable_open: dp=0x4206357e
ptable_open: IN NDOSPART loop #1 after 1st if
ptable_open: IN NDOSPART loop #1: [i].dp_start=0x42063586
data abort
pc : [<42009350>] lr : [<42009348>]
reloc pc : []lr : []
sp : b9f649e8 ip : 4205e200 fp : b9f64a18
r10: 42063640 r9 : b9f64a50 r8 : 420633c0
r7 : 420636c0 r6 : 4200818c r5 : 4205cd95 r4 : 42063586
r3 : bdf8cdf7 r2 : 000a r1 : 01c28000 r0 : 00ee
Flags: nZCv IRQs off FIQs off Mode SVC_32
Code: e08f eb0114af e5d801c2 e35000ee (0594)
Resetting CPU ...
resetting ...
My extra messages are from:
# svnlite diff /usr/src/stand/common/part.c
Index: /usr/src/stand/common/part.c
===
--- /usr/src/stand/common/part.c(revision 358966)
+++ /usr/src/stand/common/part.c(working copy)
@@ -715,18 +715,26 @@
* start sector 1. After DOSPTYP_PMBR, there may be other partitions.
* UEFI compliant PMBR has no other partitions.
*/
+ DPRINTF("BEFORE NDOSPART loop #1");
+ DPRINTF("dp=%p", (void*)dp);
for (i = 0; i < NDOSPART; i++) {
if (dp[i].dp_flag != 0 && dp[i].dp_flag != 0x80) {
DPRINTF("invalid partition flag %x", dp[i].dp_flag);
goto out;
}
+ DPRINTF("IN NDOSPART loop #1 after 1st if");
+ DPRINTF("IN NDOSPART loop #1: [i].dp_start=%p",
(void*)[i].dp_start);
#ifdef LOADER_GPT_SUPPORT
if (dp[i].dp_typ == DOSPTYP_PMBR && dp[i].dp_start == 1) {
+ DPRINTF("BEFORE table->type assignment for PMBR
detected");
+ DPRINTF("table=%p for PMBR detected", (void*)table);
table->type = PTABLE_GPT;
DPRINTF("PMBR detected");
}
+ DPRINTF("IN NDOSPART loop #1 after 2nd if");
#endif
}
+ DPRINTF("AFTER NDOSPART loop #1");
#ifdef LOADER_GPT_SUPPORT
if (table->type == PTABLE_GPT) {
table = ptable_gptread(table, dev, dread);
Note that "IN NDOSPART loop #1 after 2nd if" is
never reported. Nor is "BEFORE table->type
assignment for PMBR
HOWTO donate CPU to the fight against the Corona-virus
Hi, if someone wants to donate some FreeBSD based CPU resources to the fight against the Corona-virus, here is a quick HOWTO in terms of installing the Folding@Home client on FreeBSD: https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-freebsd-foldinghome/ I tested this on a recent -current. If you are interested in how this helps in the fight against the virus, please refer to the https://foldingathome.org/ website. In short and over-simplified: they search for vaccines. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpegpTcV7V9M.pgp Description: Digitale PGP-Signatur
