Re: [pf] stable/12: block by OS broken
On 2/17/21 22:57, Xin Li wrote: > On 2/17/21 22:35, Kristof Provost wrote: >> On 18 Feb 2021, at 6:01, Xin Li wrote: >> >> Hi, >> >> It appears that some change between 939430f2377 (December 31) and >> b4bf7bdeb70 (today) on stable/12 have broken pf in a way that the >> following rule: >> >> block in quick proto tcp from any os "Linux" to any port ssh >> >> would get interpreted as: >> >> block drop in quick proto tcp from any to any port = 22 >> >> (and block all SSH connection instead of just the ones initiated from >> Linux). >> >> Thanks for the report. I think I see the problem. >> >> Can you test this patch? >> >> |diff --git a/sys/netpfil/pf/pf_ioctl.c b/sys/netpfil/pf/pf_ioctl.c >> index 593a38d4a360..458c6af3fa5e 100644 --- a/sys/netpfil/pf/pf_ioctl.c >> +++ b/sys/netpfil/pf/pf_ioctl.c @@ -1623,7 +1623,7 @@ >> pf_rule_to_krule(const struct pf_rule *rule, struct pf_krule *krule) /* >> Don't allow userspace to set evaulations, packets or bytes. */ /* kif, >> anchor, overload_tbl are not copied over. */ - krule->os_fingerprint = >> krule->os_fingerprint; + krule->os_fingerprint = rule->os_fingerprint; >> krule->rtableid = rule->rtableid; bcopy(rule->timeout, krule->timeout, >> sizeof(krule->timeout)); | >> >> With any luck we’ll be able to include the fix in 13.0. > > Thanks, I'll try this on a -CURRENT box which is exhibiting the same > issue and report back as soon as possible. And I can confirm that this fixed the issue on -CURRENT, thanks for the quick fix! Cheers, OpenPGP_signature Description: OpenPGP digital signature
Re: [pf] stable/12: block by OS broken
On 2/17/21 22:35, Kristof Provost wrote: > On 18 Feb 2021, at 6:01, Xin Li wrote: > > Hi, > > It appears that some change between 939430f2377 (December 31) and > b4bf7bdeb70 (today) on stable/12 have broken pf in a way that the > following rule: > > block in quick proto tcp from any os "Linux" to any port ssh > > would get interpreted as: > > block drop in quick proto tcp from any to any port = 22 > > (and block all SSH connection instead of just the ones initiated from > Linux). > > Thanks for the report. I think I see the problem. > > Can you test this patch? > > |diff --git a/sys/netpfil/pf/pf_ioctl.c b/sys/netpfil/pf/pf_ioctl.c > index 593a38d4a360..458c6af3fa5e 100644 --- a/sys/netpfil/pf/pf_ioctl.c > +++ b/sys/netpfil/pf/pf_ioctl.c @@ -1623,7 +1623,7 @@ > pf_rule_to_krule(const struct pf_rule *rule, struct pf_krule *krule) /* > Don't allow userspace to set evaulations, packets or bytes. */ /* kif, > anchor, overload_tbl are not copied over. */ - krule->os_fingerprint = > krule->os_fingerprint; + krule->os_fingerprint = rule->os_fingerprint; > krule->rtableid = rule->rtableid; bcopy(rule->timeout, krule->timeout, > sizeof(krule->timeout)); | > > With any luck we’ll be able to include the fix in 13.0. Thanks, I'll try this on a -CURRENT box which is exhibiting the same issue and report back as soon as possible. Cheers, OpenPGP_signature Description: OpenPGP digital signature
Re: [pf] stable/12: block by OS broken
On 18 Feb 2021, at 6:01, Xin Li wrote: Hi, It appears that some change between 939430f2377 (December 31) and b4bf7bdeb70 (today) on stable/12 have broken pf in a way that the following rule: block in quick proto tcp from any os "Linux" to any port ssh would get interpreted as: block drop in quick proto tcp from any to any port = 22 (and block all SSH connection instead of just the ones initiated from Linux). Thanks for the report. I think I see the problem. Can you test this patch? diff --git a/sys/netpfil/pf/pf_ioctl.c b/sys/netpfil/pf/pf_ioctl.c index 593a38d4a360..458c6af3fa5e 100644 --- a/sys/netpfil/pf/pf_ioctl.c +++ b/sys/netpfil/pf/pf_ioctl.c @@ -1623,7 +1623,7 @@ pf_rule_to_krule(const struct pf_rule *rule, struct pf_krule *krule) /* Don't allow userspace to set evaulations, packets or bytes. */ /* kif, anchor, overload_tbl are not copied over. */ - krule->os_fingerprint = krule->os_fingerprint; + krule->os_fingerprint = rule->os_fingerprint; krule->rtableid = rule->rtableid; bcopy(rule->timeout, krule->timeout, sizeof(krule->timeout)); With any luck we’ll be able to include the fix in 13.0. Best regards, Kristof ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: where to upgrade 12-stable now, svn still, or git?
On 2021-Feb-12, at 23:03, Mark Millard wrote: > Dewayne Geraghty dewayne at heuristicsystems.com.au wrote on > Sat Feb 13 06:04:52 UTC 2021 : > >> The main list we used was: >> >> https://lists.freebsd.org/pipermail/svn-src-stable-12/ >> >> but that appears dead. >> . . . >> https://lists.freebsd.org/pipermail/svn-src-release/ >> >> suspect also dead. > > I should have mentioned this area in my reply to tech-lists. > This part of things is more git based now, probably > meaning more use of https://svnweb.freebsd.org/ to look > at commits/check-ins is needed in order to see the modern > cross-references between svn and git. (Such is not available > from the git side.) > > (Older history in svn does not have git references as > far as I know.) > >> I suspect that >> >> https://lists.freebsd.org/pipermail/dev-commits-src-branches/2021-January/thread.html >> >> is the stable-12 equivalent but are incremental patch releases also >> available here? > > > That covers stable/11 , stable/12 , and stable/13 . But no list > that I know of covers any releng/* or release/* commit activity. That last sentence is false as of today for releng/13.0 : https://lists.freebsd.org/pipermail/dev-commits-src-branches/2021-February/thread.html lists 7 releng/13.0 entries, the first being: git: 00abeecb4a25 - releng/13.0 - pf: Slightly relax pf_rule_addr validation Kristof Provost > For the git side of things, one has to look at the likes of > branches via cgit (or whatever) via the likes of: > > https://cgit.freebsd.org/src/log/?h=releng/12.2 > https://cgit.freebsd.org/src/log/?h=releng/13.0 > > Something like release/12.2.0 seems to be via a tag > on a commit. So https://cgit.freebsd.org/src/log/?h=releng/12.2 > lists it but https://cgit.freebsd.org/src/log/?h=stable/12 > does not. (There are commits to releng/12.2 after the > release/12.2.0 tag.) > > Of course, for 12 there still is: > > https://svnweb.freebsd.org/base/release/12.2.0/ > https://svnweb.freebsd.org/base/releng/12.2/ > > as a svn side view of things that has the modern > cross references to git included. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[pf] stable/12: block by OS broken
Hi, It appears that some change between 939430f2377 (December 31) and b4bf7bdeb70 (today) on stable/12 have broken pf in a way that the following rule: block in quick proto tcp from any os "Linux" to any port ssh would get interpreted as: block drop in quick proto tcp from any to any port = 22 (and block all SSH connection instead of just the ones initiated from Linux). Cheers, OpenPGP_signature Description: OpenPGP digital signature
Problems with SDHCI on Denverton SoC on stable/12 and stable/11
On a Denverton SoC platform with eMMC, under heavy load I see a "Controller timeout" error, followed by a register dump, and then every operation performed after returns a timeout from the MMC (Error indicated: 1 Timeout). The only way to recover is to reboot the machine. This also occurs when sending some vendor commands while untarrring a large tarball on the eMMC. I've analyzed the code, compared quirks against Linux, which doesn't seem to even be affected, and so far have come up empty. So, my questions become: What can cause it to get into this state? And why would it be unable to recover? I've seen this on both mmcsd and mmccam. I haven't tested on HEAD, but have no reason to expect a difference, given there haven't been many changes that have not been MFC'd back to stable/12 in the SDHCI and MMC areas. Thanks, Justin ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: where to upgrade 12-stable now, svn still, or git?
> On Feb 12, 2021, at 11:03 PM, Dewayne Geraghty
> wrote:
> As a change management task, I would hope that a mapping between svnlite
> and git would've become available for FreeBSD users, similar to the cvs
> to svnlite migration. I guess we need to create a test machine to
> figure out the commands we need for git to replace what we use in the
> scripts (mainly "update -r "{$DATE}", diff and log along with the
> incantation to create a git repository).
I wrote this up:
https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md
which has how to do all the basics, but doesn’t have a handy translation table.
It should suffice. If it doesn’t, open a problem or send a pull request for
improvement.
All the information in my GitHub pages are moving to the handbook. I wrote them
there due to the asciidoc conversion going on at the same time as the git
conversion and didn’t want to step on any toes.
> I wish that I could articulate the reason to management that FreeBSD is
> making the move from svn to git?
I did this video:
https://youtu.be/uj1Ricrq0bs
which explains things (though there’s a few in-jokes)
As well as this blog entry:
http://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html
and this update
https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md
But the elevator pitch is that the svn ecosystem is fading and the git
ecosystem is growing stronger. The project can leverage many CI tools to
improve quality that don’t support subversion. More people know git than
subversion, so it helps with recruiting. Git will also enable the project to
have a better commit workflow that can do more testing prior to publishing
rather than after-the-fact as with subversion.
> Is there a timeline when svn for stable-12 /usr/src disappears?
At least the duration that the project officially supports stable/12. Maybe a
bit more, but many factors that are currently unknown confound being more
specific.
Warner
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: where to upgrade 12-stable now, svn still, or git?
> On Feb 12, 2021, at 5:31 PM, tech-lists wrote: > As subject, where to get sources for 12-stable upgrade now? Is it still > svn or is it git? tl;dr: git is the source of truth, but there’s a bunch of details that might matter. The current source of truth is git repository on gitrepo.freebsd.org. It is the canonical repo for the project. A very close copy can be found at cgit.freebsd.org (it usually lags by the time it takes to copy new commits over to it, usually some small number of seconds). All other sources are derived from these. The subversion repo was the source of truth for FreeBSD between the time it was adopted until git replaced it late last year. Prior to using subversion, CVS was the source of truth. The CVS repository was retired when we did the conversion to subversion. For the life of the stable/11 and stable/12 branches (and any releng branches from those), we will be mirroring commits to those branches to the subversion repository. When we were doing the conversion, we often heard that changing VCS mid-branch would be too burdensome and would really go against the branch stability guarantees we have. The svn mirroring service should be a faithful reflection of the git source of truth. Or is modulo bugs and semantic differences in the different VCS. If there’s a discrepancy, then git is authoritative. There will be a lag between what’s committed to git and its appearance in svn mirrors because the mirroring is done via a cron job and there’s propagation delays. Since subversion has different semantics, it expands the $FreeBSD$ keywords in the source, while git does not (and cannot in a meaningful way). This will result in a difference between trees checked out in one versus the order. Normally, this difference is inconsequential, though some folks may need it for various reasons. There’s a small wrinkle with any 12.x releases. Those will be built out of the subversion mirror of the git source of truth. We’re doing this to continue the $FreeBSD$ expansion through the life of the 12.x branch. This will result in a slightly different build for the non-reproducible builds when one builds out of subversion vs out of git. Should there be a difference between the svn sources and git sources, say due to a bug in the mirroring or the $FreeBSD$ expansion being meaningful, this can lead to some confusion. If this is a material difference, an updated would be issued right away to correct it. And in this case, the source of truth is still the git repo, it’s just been transformed in various ways before landing in the source artifacts that are used to create a release. In many ways the little difference have long been accepted. The tree you get from the old CVS repo differed from the tree you’d get from the same version post conversion to svn from the svn repo because of semantic differences in how $FreeBSD$ was expanded. You could never checkout a 2.1 release from subversion and get exactly the sources that phk used to build the 2.1.0 release because CVS expanded the keywords as $FreeSBD: foo.c 1.7$ and svn expanded them $FreeBSD: path/to/file/foo.c 3255$. This is muddied a bit further with the git conversion since the sources on the ISO images were used to recreate the 1.x series of releases. There may also be some early tags that haven’t made it through all the conversion processes... Even the git repo copies that are mirrored out differ slightly in that they publish a slightly abridged version. GitHub’s interface does not like having ~10k entries in it for the ‘branch’ menu. So we don’t publish vendor branches to GitHub because of how the subversion repo vendor branches and tags were converted lead to too many branches for GitHub to be happy. This information is available from gitrepo.freebsd.org, however. Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: where to upgrade 12-stable now, svn still, or git?
On Fri, 12 Feb 2021 at 23:11, tech-lists wrote: > > I saw on cgit that stable/12 was there. These older systems weekly > update their sources via svn till now, in a cron job. At the time I wrote > my message, I saw that svn still works, so was wondering which to use, > which has the latest updates. You can continue to use svn for these as long as stable/12 is supported. The git-svn conversion script was set up explicitly to support this use case, and will remain in operation at least until stable/12's EOL. Security updates for stable/12 and 12.x releases will also be available via svn, and the advisories reference the svn revision. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: where to upgrade 12-stable now, svn still, or git?
On Sat, 13 Feb 2021 at 01:04, Dewayne Geraghty wrote: > > Is there a timeline when svn for stable-12 /usr/src disappears? stable/11 and stable/12 will exist in svn for at least as long as the branches are supported - stable/12 expected EOL is June 30,2024. If you're tracking stable you don't need to use git until you migrate to stable/13. svnweb in particular should remain active as long as is reasonably practicable since there are bug reports, mailing list posts etc. which link to revisions on svnweb. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: git to svn update frequency ?
On 2/17/2021 12:10 PM, Warner Losh wrote: > On Feb 17, 2021, at 6:05 AM, mike tancsa wrote: >> I noticed on a box that I update RELENG_12 via git there are more >> recent commits then if I use svnlite to track. Are they only >> periodically updated ? If so, how frequently do they get refreshed ? >> e.g. I see the new OpenSSL version in git, but not when I update via >> svnlite. > Yes. There is a lag for a number of reasons. The updates happen on a batched > basis (it’s a script I wrote) and then there’s a delay in replication to the > main subversion servers. I believe that the rate is on the scale of hourly, > but lwhsu will have to answer that detail. > Thanks Warner, Looks like its about 12hrs compared to git right now. The last update in svn was https://cgit.freebsd.org/src/commit/?h=stable/12=42f7f5c5d22cc9e845e51a1f8a5b92573b8b3d2f, and nothing after that. ---Mike ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: git to svn update frequency ?
> On Feb 17, 2021, at 6:05 AM, mike tancsa wrote: > I noticed on a box that I update RELENG_12 via git there are more > recent commits then if I use svnlite to track. Are they only > periodically updated ? If so, how frequently do they get refreshed ? > e.g. I see the new OpenSSL version in git, but not when I update via > svnlite. Yes. There is a lag for a number of reasons. The updates happen on a batched basis (it’s a script I wrote) and then there’s a delay in replication to the main subversion servers. I believe that the rate is on the scale of hourly, but lwhsu will have to answer that detail. Warner ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
git to svn update frequency ?
Hi I noticed on a box that I update RELENG_12 via git there are more recent commits then if I use svnlite to track. Are they only periodically updated ? If so, how frequently do they get refreshed ? e.g. I see the new OpenSSL version in git, but not when I update via svnlite. # svnlite update Updating '.': At revision 369282. # Thanks, ---Mike ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Microcode update prevents boot
>> Could you see >> if the hang persists when boot-time ucode loading is enabled and >> vm.pmap.di_locked=1 is configured? Hi, I can confirm that setting vm.pmap.di_locked=1 and enabling the loading of the cpu microcode at the same time does not cause any trouble. Unfortunately I didn't had the time to patch and compile a custom kernel yet. Leon Dietrich ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
