What is kernel option DDB and KDB good for?

PMc

PMc

There appears to be a manpage for ddb(4), but it rather talks about KDB. And in GENERIC there is KDB, but no DDB.

From my archives, KDB has appeared somehow (already way back), but DDB was always there, back as far as Rel. 2.2.1.

How come: I found these options troublesome. Specifically, for more than two years I was fighting the most weird instability problems, i.e. crashes every 2-3 weeks with random errors.
Then finally I removed DDB and KDB from KERNCONF, and the issues are gone, it now runs under severe load without failure for 2 months.

From what I undestand, these options seem to only be used for live analyzing inside the kernel - and one needs a lot of skill to do that, and it is in most cases much easier (and less intrusive) to work with dtrace(1). Having these options removed seems not to limit the ability to obtain a crashdump either, even sysctl debug.kdb.panic still works as expected.

So, what are these good for on an operative system?
 
KDB is not enabled on GENERIC for RELEASE versions. It's enabled on STABLE and on CURRENT.
 
SirDice said:
KDB is not enabled on GENERIC for RELEASE versions. It's enabled on STABLE and on CURRENT.
Click to expand...

You sure?
Code: 
admin@disp:755:1/usr/src/sys/amd64/conf$ grep KDB GENERIC
options         KDB                     # Enable kernel debugger support.
options         KDB_TRACE               # Print a stack trace for a panic.
admin@disp:756:1/usr/src/sys/amd64/conf$ svn stat GENERIC
admin@disp:757:1/usr/src/sys/amd64/conf$ svn info GENERIC
Path: GENERIC
Name: GENERIC
Working Copy Root Path: /usr/src
URL: https://svn0.us-east.freebsd.org/base/releng/11.2/sys/amd64/conf/GENERIC
Relative URL: ^/releng/11.2/sys/amd64/conf/GENERIC
Repository Root: https://svn0.us-east.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 343946
Node Kind: file
Schedule: normal
Last Changed Author: sbruno
Last Changed Rev: 333417
Last Changed Date: 2018-05-09 18:14:12 +0200 (Wed, 09 May 2018)
Text Last Updated: 2019-02-05 21:28:16 +0100 (Tue, 05 Feb 2019)
Checksum: 6ecfb0af69522dc6dac74c8c96bc6ffb6dcf440b

Maybe I got something wrong, but I was thinking /releng/ should be the RELEASE path. And I didn't patch this one. ;)
 
PMc said:
Maybe I got something wrong, but I was thinking /releng/ should be the RELEASE path. And I didn't patch this one. ;)
Click to expand...
There is a /release/ branch there too, just goto release.
And here is a diagram about the FreeBSD code branches that explains what those terms mean: https://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/release-branches.html

According to the diagram, RELENG is a living code branch, while RELEASE is like a snapshot of it. I guess, this applies also to the RELEASE patch levels.
 
roccobaroccoSC said:
There is a /release/ branch there too, just goto release.
Click to expand...

Yes, I know - but that is almost certainly not what one would want; because, that one is frozen at the release date, it does not receive security fixes!

According to the diagram, RELENG is a living code branch, while RELEASE is like a snapshot of it. I guess, this applies also to the RELEASE patch levels.
Click to expand...

/releng/ is not "living". It should get exactly and only the security and errata fixes that are officially published. So this is most probably the thing you want for an operative system if you bother to compile on-site.

Nevertheless, in the frozen /release/ path the KDB also appears to be included.

Besides, I completely agree to SirDice : if that was the conceptual idea, then that makes perfect sense to me - it just seems to somehow have fallen off the shelf in the reality. ;)
 
PMc said:
You sure?
Click to expand...
I was sure this was the case. So I rechecked it. Looks like it changed somewhere between 9 and 10. For 9.x releases it wasn't included but from 10.0 onward KDB was added to GENERIC. -CURRENT does have a whole slew of debug options enabled, as it always did. From what I remember STABLE fell somewhere in between RELEASE and CURRENT regarding debug options but that doesn't appear to be the case any more either.
 
PMc said:
Yes, I know - but that is almost certainly not what one would want; because, that one is frozen at the release date, it does not receive security fixes!



/releng/ is not "living". It should get exactly and only the security and errata fixes that are officially published. So this is most probably the thing you want for an operative system if you bother to compile on-site.

Nevertheless, in the frozen /release/ path the KDB also appears to be included.

Besides, I completely agree to SirDice : if that was the conceptual idea, then that makes perfect sense to me - it just seems to somehow have fallen off the shelf in the reality. ;)
Click to expand...
I do not agree that you won't get security updates. In fact you do get the updates with RELEASE, they just come in chunks called patches.
And releng, if I understand correctly, is meant for the release engineers to work on the next release or patch. So it is actually a dev branch and one does not use a dev branch productively to stay secure. This is what patches are for. As a matter of fact, using a dev branch can make you more insecure, because people try out things before they get them right. The latest changes have not been thoroughly tested either in a typical dev branch.
 
No, /base/release/11.2 is more or less an administrative tag. You shouldn't use it. To get 11.2-RELEASE plus security patches you follow /base/releng/11.2. The tag or branch was called RELENG_X_Y when we were still on CVS. "Releng" is short for RELease ENGineering.

The /base/stable/11 is 11-STABLE and is where new features and bug fixes are added. New -RELEASE versions are pulled from -STABLE. So you can basically see a -STABLE as an alpha of the next minor release version.

head is called -CURRENT. This will be the next major release version. It's where all the exciting new developments happen and where things can break at any given time.
 
That can easily be verified. When running svn log on the /releng/ branch, we can see that each commit has a "Security:" record, and these are the same as in the published advisories:
Code: 
admin@disp:912:1/usr/src$ svn log ^/releng/11.2
------------------------------------------------------------------------
r343793 | emaste | 2019-02-05 19:22:21 +0100 (Tue, 05 Feb 2019) | 5 lines

UPDATING and newvers entries for 11.2-p9

Approved by:    so
Security:       FreeBSD-SA-19:01.syscall

------------------------------------------------------------------------
r343789 | emaste | 2019-02-05 19:07:45 +0100 (Tue, 05 Feb 2019) | 7 lines

amd64: clear callee-preserved registers on syscall exit

Submitted by:   kib
Approved by:    so
Security:       CVE-2019-5595
Security:       FreeBSD-SA-19:01.syscall

------------------------------------------------------------------------
r342901 | emaste | 2019-01-09 20:11:32 +0100 (Wed, 09 Jan 2019) | 7 lines

UPDATING and newvers entries for 11.2-p8

Approved by:    so
Security:       FreeBSD-EN-19:03.sqlite
Security:       FreeBSD-EN-19:04.tzdata
Security:       FreeBSD-EN-19:05.kqueue

------------------------------------------------------------------------
r342899 | emaste | 2019-01-09 19:57:38 +0100 (Wed, 09 Jan 2019) | 5 lines

MFS11 r340904: Avoid unsynchronized updates to kn_status.

Approved by:    so
Security:       FreeBSD-EN-19:05.kqueue
[...]

I for my part, I expect that the source tree is always exactly the same as the running code. Because I want to look into that and be able to understand what is actually happening. It gave me an amount of grey hair when I tried to do that with Linux on a couple of occasions, where it is..., lets say, very difficult. So thats my main argument for FreeBSD. There is no "patching" here, except in the source and with logged revision identifiers.
 
SirDice said:
No, /base/release/11.2 is more or less an administrative tag. You shouldn't use it. To get 11.2-RELEASE plus security patches you follow /base/releng/11.2. The tag or branch was called RELENG_X_Y when we were still on CVS. "Releng" is short for RELease ENGineering.

The /base/stable/11 is 11-STABLE and is where new features and bug fixes are added. New -RELEASE versions are pulled from -STABLE. So you can basically see a -STABLE as an alpha of the next minor release version.

head is called -CURRENT. This will be the next major release version. It's where all the exciting new developments happen and where things can break at any given time.
Click to expand...
Indeed! It is documented, but I must have skimmed over it: https://www.freebsd.org/doc/handbook/makeworld.html#updating-src-obtaining-src-repopath
 
You must log in or register to reply here.
Back
Top