On 2 Oct 2018, at 18:15, Alan Somers wrote:
>> 3. Remove a check of trail enablement/suspension from audit_new() --
>> at the point where this function has been entered, we believe that
>> system-call auditing is already in force, or we wouldn't get here,
>> so simply proceed to
On 3 Apr 2015, at 02:38, Hans Petter Selasky h...@selasky.org wrote:
I would like have a comment on one final issue about the IP ID field.
Given two [small] prime numbers: P and Q
Assume you have a firewall that separate two networks, called A and B, that
are not allowed to communicate.
On 3 Apr 2015, at 09:40, Hans Petter Selasky h...@selasky.org wrote:
There are countless covert channels in TCP/IP; breaking the IP
implementation to close a covert channel is probably not a worthwhile
investment.
The IP ID channel is a _broadcast_ channel to all devices connected to the
On 3 Apr 2015, at 10:24, Hans Petter Selasky h...@selasky.org wrote:
Before engaging further in this conversation, and trying to modify the
behaviour of the TCP/IP stack, you need to educate yourself about the design
and history of the protocols involved. Otherwise, you're going to
On 3 Apr 2015, at 11:41, Hans Petter Selasky h...@selasky.org wrote:
On 04/03/15 11:31, Robert N. M. Watson wrote:
TCP/IP covert and side channels
Hi,
Can you provide a reference to a document in the area of TCP/IP covert and
side channels which is considered state of the art
On 2 Apr 2015, at 19:24, Hans Petter Selasky h...@selasky.org wrote:
In my sketchup I assume that packets for the same destination will not be
re-ordered. I see that the current ip_reass() code does not care about TCP or
UDP port numbers at all. Maybe we should add code to check that the
On 2 Apr 2015, at 21:54, Hans Petter Selasky h...@selasky.org wrote:
Please go read about how IP fragmentation works. Having an identical IP
ID in ip_fragment() is the point of the function!
rwatson: You're right, the more fragment flag gets set there, I
overlooked that bit. Sorry.
On 15 Jan 2015, at 12:35, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Wed, Jan 14, 2015 at 11:44:00PM +, Robert Watson wrote:
- As we anticipate embedding mbufs headers within variable-size regions of
memory in the future, change the definitions of byte arrays embedded in
On 7 Jan 2015, at 20:48, Gleb Smirnoff gleb...@freebsd.org wrote:
R Shouldn't this come w/ a FreeBSD version bump for drivers to use?
R
R Yes, probably. Old drivers will continue to work fine in not checking the
R return value (for now), but drivers seeing backporting will probably want
On 7 Sep 2014, at 11:23, Gleb Smirnoff gleb...@freebsd.org wrote:
R Modified: head/sys/sys/mbuf.h
R
==
R --- head/sys/sys/mbuf.hFri Sep 5 16:40:47 2014(r271173)
R +++ head/sys/sys/mbuf.hFri Sep 5
On 17 Mar 2014, at 01:48, Eitan Adler ead...@freebsd.org wrote:
Fix a comment in capability.h: it got renamed to capsicum.h, not
capability.h.
Perhaps it makes to sense to add a #warning statement to the file as well?
Additionally, is it intended that this file live forever or will be
On 17 Mar 2014, at 07:54, David Malone dwmal...@maths.tcd.ie wrote:
(1) Merge a software implementation of the Toeplitz hash specified in
RSS implemented by David Malone. This is used to allow suitable
pcbgroup placement of connections before the first packet is
received
On 15 Mar 2014, at 17:29, Adrian Chadd adr...@freebsd.org wrote:
I'd characterise this work as early in that it would benefit from
performance optimisation, device-driver work, and feature enhancement (e.g.,
not just stuff like load rebalancing, but also statistics to detect RSS
On 5 Feb 2014, at 19:05, John Baldwin j...@freebsd.org wrote:
A short term solution that would permit non-security jails without having to
do the longer term work that Robert would like might be to add a new per-jail
flag that in effect means no security at all. You would then modify one
On 4 Feb 2014, at 07:53, Adrian Chadd adr...@freebsd.org wrote:
I really would rather see Xorg gain whatever abstraction is necessary
to probe/attach/interface with a DRI API supported graphics card.
So, this then becomes a question of whether this is needed for DRI API
supported graphics
On 4 Feb 2014, at 10:05, Ivan Voras ivo...@freebsd.org wrote:
On 31 January 2014 18:28, James Gritton ja...@freebsd.org wrote:
On 1/31/2014 5:34 AM, Robert Watson wrote:
Frankly, I'd like to see this backed out and not reintroduced. If it must
be retained, then it needs a much more clear
On 4 Feb 2014, at 13:23, Julian Elischer jul...@freebsd.org wrote:
On 2/4/14, 3:40 PM, Robert N. M. Watson wrote:
On 3 Feb 2014, at 23:53, Doug Ambrisko ambri...@ambrisko.com wrote:
It's unfortunate that vimage requires jail. I want to use vimage but
not have the security restrictions
On 3 Feb 2014, at 23:53, Doug Ambrisko ambri...@ambrisko.com wrote:
It's unfortunate that vimage requires jail. I want to use vimage but
not have the security restrictions of a jail. To do this I patched
jail to basically let everything through. It would be nice to be
able to run jail in
On 20 Nov 2013, at 20:11, Julian Elischer jul...@freebsd.org wrote:
Currently, it is quite easy to make mistakes regarding individual mbuf
chains vs. lists of mbuf chains. This leads me to wonder whether a new
type, perhaps simply constructed on the stack before passing in, should be
On 14 Nov 2013, at 11:06, Edward Tomasz Napierała tr...@freebsd.org wrote:
Wiadomość napisana przez Robert Watson w dniu 14 lis 2013, o godz. 09:07:
On Tue, 12 Nov 2013, Edward Tomasz Napierala wrote:
Mention acl_get_brand_np(3).
MFC after: 2 weeks
Sponsored by: The FreeBSD
On 2 Jan 2013, at 21:02, Andrew Turner wrote:
This seemed to do the trick; what do you think of the attached? This
isn't a board-specific change, so I dropped it into the common
fdt_mips.c code. On the other hand, this left it a bit open as to
what the right compatible= line to use was, so
On 1 Jan 2013, at 22:08, Andrew Turner wrote:
On a semi-related note: the current obstacle to moving more devices
over to using FDT on BERI is that our FDT implementation appears to
require a PIC to be configured. We're not actually using a PIC on
BERI currently. It works fine attached to
Hi Garrett:
Thanks for the report -- I didn't realise tinderbox was now building all
kernels, or I would have merged my fix from P4 more quickly.
The patch you've attached isn't quite the right one -- BERI supports both FDT
and non-FDT kernels, so we shouldn't build the Openfirmware headers in
On 1 Jan 2013, at 19:17, Andrew Turner wrote:
@@ -76,6 +85,17 @@ mips_init(void)
{
int i;
+#ifdef FDT
+#ifndef FDT_DTB_STATIC
+#error mips_init with FDT requires FDT_DTB_STATIC
+#endif
+
+if (OF_install(OFW_FDT, 0) == FALSE)
+while (1);
+if
On 1 Jan 2013, at 19:17, Andrew Turner wrote:
This looks like it is too late in the boot process. If you are using
FDT you will need to use the FDT uart which is initialised in cninit.
On a semi-related note: the current obstacle to moving more devices over to
using FDT on BERI is that our
On 29 Dec 2012, at 14:50, Adrian Chadd wrote:
The standing consensus is that we try not to break certain classes of device
drivers, not that we don't ever change any kernel interfaces. The reason is
that we don't have a formal definition of public and do not wish to use
the definition all
On 29 Dec 2012, at 06:40, Adrian Chadd wrote:
There's likely a bunch of companies/users that would love things to
not change during a stable branch and there's likely a bunch of
companies/users that would hate things being immutable during a stable
branch.
There's never been a formal
On 29 Dec 2012, at 04:43, Alfred Perlstein wrote:
Yes. Kib and I chatted offline, it seems that the SOP is really there is no
guarantee about KPI when talking about VFS so the headache that it would be
to write the shim layer and maintain it (particularly considering the 9.x
release
On 19 Dec 2012, at 10:57, Andrey Zonov wrote:
I think you should not MFC this one quickly -- let's wait for it to
shake out in the -CURRENT userbase for a few months to see what
breaks. I wouldn't be surprised if a fair number of applications
(both publicly available, and local at various
On 28 Nov 2012, at 17:51, Gleb Smirnoff wrote:
On Wed, Nov 28, 2012 at 09:39:15AM -0800, Alfred Perlstein wrote:
A Personally I don't think we need any more anchors attached to people's
A feet when developing FreeBSD.
A
A Mistakes will happen, they will happen in head. Slowing down the
later, in the field, where it is hardest to do so.
Robert
Sent from my iPhone
On Nov 28, 2012, at 10:25 AM, Robert N. M. Watson rwat...@freebsd.org
wrote:
On 28 Nov 2012, at 17:51, Gleb Smirnoff wrote:
On Wed, Nov 28, 2012 at 09:39:15AM -0800, Alfred Perlstein wrote:
A Personally I
On 29 Nov 2012, at 04:17, Alfred Perlstein wrote:
I've seen what happens with large groups, it doesn't scale and basically you
wind up with the following type of reviewers:
I think we have to assume best intent here -- the goal of code review in
complex critical components is not to
On 29 Nov 2012, at 07:02, Simon J. Gerraty wrote:
On Wed, 28 Nov 2012 20:17:33 -0800, Alfred Perlstein writes:
I've seen what happens with large groups, it doesn't scale and basically
you wind up with the following type of reviewers:
The issues you cite, are the result of taking a good
On 27 Nov 2012, at 22:54, Andre Oppermann wrote:
Andre.. this breaks incoming connections. TCP is immediately reset and
never even gets to the
listener process. You need to back out of fix this urgently please.
I just found out and fixed it. Sorry for the breakage.
I'd like to see a
On 27 Nov 2012, at 23:29, Andre Oppermann wrote:
Andre.. this breaks incoming connections. TCP is immediately reset and
never even gets to the
listener process. You need to back out of fix this urgently please.
I just found out and fixed it. Sorry for the breakage.
I'd like to see a
On 28 May 2012, at 09:36, Konstantin Belousov wrote:
On Sun, May 27, 2012 at 07:49:36AM +1000, Bruce Evans wrote:
On Sat, 26 May 2012, Konstantin Belousov wrote:
On Sat, May 26, 2012 at 10:21:25PM +1000, Bruce Evans wrote:
The 'low level' AKA magic happens in several *_fetch_syscall_args()
On 29 Feb 2012, at 07:50, Mikolaj Golub wrote:
JE well that's exactly what I AM questioning.. how often will this be used?
JE one person using this once in all of history isn't a real requirement
JE for inclusion.
This information may be very useful when troubleshooting unexpected
On 21 Jan 2012, at 11:30, Hans Petter Selasky wrote:
Author: hselasky
Date: Wed Jan 18 07:57:17 2012
New Revision: 230302
URL: http://svn.freebsd.org/changeset/base/230302
Log:
MFC r230032, r230050, r230090, r230091 and r228493.
- Various XHCI and USB 3.0 related issues.
- USB 3.0 HUBs
On 21 Jan 2012, at 13:33, Hans Petter Selasky wrote:
Just to clarify, are you saying that:
(1) We should not ever do an errata note + binary update for the most
important of these bug fixes, just wait for them to ship in FreeBSD
8.3/9.1?
(2) We should do errata notes + binary updates
On 20 Jan 2012, at 21:29, Hans Petter Selasky wrote:
On Friday 20 January 2012 16:16:00 Robert Watson wrote:
On Wed, 18 Jan 2012, Hans Petter Selasky wrote:
Author: hselasky
Date: Wed Jan 18 07:57:17 2012
New Revision: 230302
URL: http://svn.freebsd.org/changeset/base/230302
Log:
MFC
On 26 Nov 2011, at 17:48, Kostik Belousov wrote:
in138:~% procstat -x 2008
PID COMM AUXV VALUE
2008 nginxAT_PHDR 0x400040
2008 nginxAT_PHENT 56
2008 nginxAT_PHNUM 8
2008 nginx
On 6 Nov 2011, at 05:51, Mikolaj Golub wrote:
On Sun, 6 Nov 2011 10:47:20 + (UTC) Mikolaj Golub wrote:
MG Author: trociny
MG Date: Sun Nov 6 10:47:20 2011
MG New Revision: 227207
MG URL: http://svn.freebsd.org/changeset/base/227207
MG Log:
MG Cache SO_REUSEPORT socket option in
On 10 Sep 2011, at 12:10, Hans Petter Selasky wrote:
For most other classes of hardware device driver framework KPIs --
especially things like PCI bus attachment, busdma, CAM, ifnet, and GEOM
frameworks, our MFC rules would strictly disallow this sort of change, on
the grounds that it is our
On 10 Sep 2011, at 12:35, Robert N. M. Watson wrote:
I understand your point. The change is not breaking any KPIs towards
userspace. The structure in question is only used within the kernel and
kernel
modules.
Right -- exactly my point. If this change breaks third-party compiled USB
On 27 Aug 2011, at 09:21, Navdeep Parhar wrote:
Shouldn't opt_comconsole.h be included in subr_kdb.c for this part to
actually work?
Should now be fixed; do let me know if not!
Robert
___
svn-src-all@freebsd.org mailing list
On 4 Jun 2011, at 15:30, Kristof Provost wrote:
div_bind probably also needs to surround the call to in_pcbbind with
INP_HASHW(UN)LOCK(...)
I'm currently running 222680. I've only now seen the issue, but I've also
just now activated INVARIANTS.
Hi Kristof:
Thanks for the detailed report,
On 24 Apr 2011, at 17:32, Alexey Dokuchaev wrote:
On Sun, Apr 24, 2011 at 06:28:48PM +0300, Alexander Motin wrote:
What's about creating some kind of symlinks, it could be nice if it
worked, but I don't see the way to do it on disk(9) or GEOM layers
without breaking device's access counters
On 24 Apr 2011, at 12:49, Alexander Motin wrote:
Reverting is not an option. _Constructive_ propositions are welcome.
It is the policy of this project that the release engineering team has
final authority over what ships in a release. It is entirely within
scope to revert this change for
On 1 Mar 2011, at 14:53, Alexander Leidinger wrote:
Quoting Robert Watson rwat...@freebsd.org (from Tue, 1 Mar 2011 13:23:37
+ (UTC)):
Author: rwatson
Date: Tue Mar 1 13:23:37 2011
New Revision: 219129
URL: http://svn.freebsd.org/changeset/base/219129
Log:
Add initial support
On 3 Mar 2011, at 13:14, Alexander Leidinger wrote:
Quoting Robert Watson rwat...@freebsd.org (from Thu, 3 Mar 2011 11:14:59
+ (GMT)):
On Tue, 1 Mar 2011, Dmitry Chagin wrote:
Teach kdump to decode linux syscalls names too.
Fix bug introduced in my previous commit: the kernel
On 1 Mar 2011, at 15:21, John Baldwin wrote:
Looks like head/sys/sys/capability.h wasn't added by accident?
Indeed -- a classic case of things building fine but a missing svn add --
thanks!
Robert___
svn-src-all@freebsd.org mailing list
On 1 Mar 2011, at 16:55, Ryan Stone wrote:
I'm a bit confused. The 8.2 release notes claim that userland dtrace
support was added to 8.2. Is this incorrect?
http://www.freebsd.org/releases/8.2R/relnotes.html
Userland support for the dtrace(1) subsystem has been added. This
allows
On 4 Feb 2011, at 10:56, John Baldwin wrote:
The difference here is that FOREACH_THREAD_IN_PROC() is just a
TAILQ_FOREACH(). The CPU iterators are more complex.
I agree that that we should have topology-aware iterators, though part of the
problem is what do you iterate? We'd have to
On 4 Feb 2011, at 13:30, Michael Tuexen wrote:
Hmm. It might be better to add a new NETISR_SCTP and use netisr's support
for multithreading?
That sounds really good.
Is it possible that different network cards put packets in the same queue?
That would be helpful in the case of SCTP.
On 26 Jan 2011, at 23:41, m...@freebsd.org wrote:
Upon further consideration, I don't think sbuf_new_for_sysctl() should
be doing the wire. Whether the buffer needs to be wired or not is up
to the implementation of the individual sysctl; *most* of them will be
holding a lock when doing
On 26 Jan 2011, at 17:12, m...@freebsd.org wrote:
Hmm. Is this description missing mention of how wiring failures are
handled? (Also, it should probably mention that this call can sleep for
potentially quite long periods of time, even if sbuf_printf (and friends)
can't).
I'm not sure how
On 26 Jan 2011, at 18:29, m...@freebsd.org wrote:
I suppose an important question is now often we see this actually failing
I don't believe we've ever seen a memory failure relating to sysctls
at Isilon and we've been using the equivalent of this code for a few
years. Our machines aren't
On 26 Jan 2011, at 21:14, m...@freebsd.org wrote:
The kinds of cases I worry about are things like the tcp connection
monitoring sysctls. Most systems have a dozen, hundred, or a thousand
connections. Some have half a million or a million. If we switched to
requiring wiring every page
On 13 Dec 2010, at 18:28, Ion-Mihai Tetcu ite...@freebsd.org wrote:
I see. Thanks for the time you took to explain things, I'm very new to
XEN.
Do we have any docs somewhere (well, except the sources) about our XEN
support and various options / optimizations? I only know about
AdrianChadd's
On 27 Oct 2010, at 13:56, David Xu wrote:
Yay, it's fd_set all over again :-).
It sounds like we might just need to add a sysctl and a few wrapper
functions in userspace along the lines of (hand-wave):
cpuset_t*cpuset_alloc();
void cpuset_free();
And perhaps some sort of
On 24 Oct 2010, at 14:20, Alexander Best arun...@freebsd.org wrote:
On Sun Oct 24 10, Robert Watson wrote:
Author: rwatson
Date: Sun Oct 24 09:14:21 2010
New Revision: 214261
URL: http://svn.freebsd.org/changeset/base/214261
Log:
Add microbenchmark for create/unlink of a zero-byte file.
On 4 Jun 2010, at 20:33, Ermal Luçi wrote:
Interface event are not an issue for pfSense architecture since it
controls all the underlying data and i think most of the divert
applications do not care much about interface events apart renaming.
Keeping both options sounds reasonable too.
A
On 3 Jun 2010, at 14:09, Ermal Luçi wrote:
Would it make sense to remove even passing the interface name up and
actually send the
interface index?
That is what we are doing at pfSense and it works quite ok.
I see one important argument for doing this:
- Looking up an interface by number
On 1 Jun 2010, at 15:23, Nikolay Denev wrote:
When close() is called on a connected socket pair, SO_ISCONNECTED might be
set but be cleared before the call to sodisconnect(). In this case,
ENOTCONN is returned: suppress this error rather than returning it to
userspace so that
On Mar 13, 2010, at 1:50 PM, Randall Stewart wrote:
did not think of that.. we COULD possible do it another way.. a bit harder
but possible.. i.e. have the delayed sack code actually look into
the mbufs and see if its ipv4 or ipv6.. I thought about doing it
that way but it takes more cycles
On Mar 12, 2010, at 7:52 AM, Qing Li wrote:
Is there any way we can pick up via an assertion that an interface driver
has failed to implement this functionality? This has never been a historic
requirement, so I suspect there are a lot of drivers floating around that
fail to meet the
that it will someday set the link state. But I
don't think that helps with ECMP, that's just for the benefit of programs like
dhclient that care about future events rather than current state.
Robert
-- Qing
On Fri, Mar 12, 2010 at 12:26 AM, Robert N. M. Watson
rwat...@freebsd.org wrote
On Mar 12, 2010, at 8:44 AM, Julian Elischer wrote:
I'm confused about Julian's proposal because it seems to me that we
already know when a driver hasn't set or is unable to determine the link
state: it will (should) be set to LINK_STATE_UNKNOWN by default.
the question is whether there
On Mar 12, 2010, at 6:56 PM, Qing Li wrote:
Right now I like to implement Robert's suggestion of using if_capabilities
field. I'd like to create a new flag, IFCAP_LINKSTATE_NOTIFY flag.
The routing decision will check against the if_link_state if this bit
is set.
Only a handful of drivers
On Mar 11, 2010, at 11:30 PM, Qing Li wrote:
What you raised is definitely a possibility and these fixes take the
similar approach. I am going to try and go through each of these
drivers in /sys/dev/ and converting them, very soon.
Is there any way we can pick up via an assertion that an
On Mar 12, 2010, at 12:18 AM, Qing Li wrote:
You definitely have a very good point here. I was a bit surprised
during debugging that the link state is not consistently initialized
and by far not enforced across all of the drivers. Admittedly I checked
the most commonly deployed devices
On Mar 10, 2010, at 1:15 PM, John Baldwin wrote:
On Tuesday 09 March 2010 7:27:06 pm Robert Watson wrote:
On Tue, 9 Mar 2010, John Baldwin wrote:
Log:
MFC 183525: Bump MAXCPU to 32 now that 32 CPU x86 systems exist.
Hmmm. I'd be a bit surprised if this doesn't cause ABI issues for
On 14 Dec 2009, at 16:08, Bruce Evans wrote:
On Mon, 14 Dec 2009, Robert Watson wrote:
Log:
Merge r197808 from head to stable/8:
In rtld's map_object(), use pread(..., 0) rather than read() to read the
ELF header from the front of the file. As all other I/O on the binary
is done
On 14 Jan 2010, at 20:01, Doug Barton wrote:
FWIW, I actually think this makes it worse, not better. The
INCLUDE_CONFIG_FILE option should include everything needed to recreate
the kernel. If it doesn't, it's worse than worthless, it leads to a
false sense of security which makes it
On 1 Dec 2009, at 11:25, Sean C. Farley wrote:
We've already had two major security issues arising out of getenv.c in the
past year, and I'd like to make sure we don't have a third.
I think it's fair to say that the POSIXization of the environment code has
been an unmitigated disaster,
On 1 Nov 2009, at 15:33, Ed Schouten wrote:
Because d_kind is a pointer, there will be a hole in the structure
of at
least 2 bytes (maybe even 6), which means we can safely extend
d_mode to
32 bits as well. I could have decided to leave it at uint16_t, but
that
would only obfuscate it
On 6 Oct 2009, at 20:27, Gabor Kovesdan wrote:
Robert Watson escribió:
+
+char *
+basename(path)
+ const char *path;
+{
+ static char *bname = NULL;
+
Sorry if it's a trivial question but isn't ANSI prototype preferred
over KR function definition?
For the purposes of this
On 2 Aug 2009, at 20:29, Alfred Perlstein wrote:
* Robert Watson rwat...@freebsd.org [090801 15:15] wrote:
On Sat, 1 Aug 2009, Hans Petter Selasky wrote:
This has slowed down core dumps very significantly. What used
to take
10-15s on my system now takes around 3 minutes. A simple test
78 matches
Mail list logo
