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 11:41, Hans Petter Selasky 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 consi
On 3 Apr 2015, at 10:24, Hans Petter Selasky 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 repeatedly
>> sugge
On 3 Apr 2015, at 09:40, Hans Petter Selasky 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
> same n
On 3 Apr 2015, at 02:38, Hans Petter Selasky 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.
>
> In net
On 2 Apr 2015, at 21:54, Hans Petter Selasky 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.
>>
>> glebi
On 2 Apr 2015, at 19:24, Hans Petter Selasky 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 packet
> belongs
On 7 Jan 2015, at 20:48, Gleb Smirnoff 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
> a
> R> _
On 7 Sep 2014, at 11:23, Gleb Smirnoff 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 16:46:28 20
On 17 Mar 2014, at 01:48, Eitan Adler 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
> removed a
On 17 Mar 2014, at 07:54, David Malone 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 from the NIC. So
On 15 Mar 2014, at 17:29, Adrian Chadd 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
>> configuration problem
On 5 Feb 2014, at 19:05, John Baldwin 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
> place (pri
On 4 Feb 2014, at 13:23, Julian Elischer wrote:
> On 2/4/14, 3:40 PM, Robert N. M. Watson wrote:
>> On 3 Feb 2014, at 23:53, Doug Ambrisko wrote:
>>
>>> It's unfortunate that vimage requires jail. I want to use vimage but
>>> not have the security
On 4 Feb 2014, at 10:05, Ivan Voras wrote:
> On 31 January 2014 18:28, James Gritton 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 warning that enabling this
On 4 Feb 2014, at 07:53, Adrian Chadd 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 cards, or whet
On 3 Feb 2014, at 23:53, Doug Ambrisko 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 an insecure mode w
On 20 Nov 2013, at 20:11, Julian Elischer 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
>> used for KPIs
On 14 Nov 2013, at 11:06, Edward Tomasz Napierała 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 Founda
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 wa
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 attache
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 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)
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 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 a
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 g
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 elimin
g the bugs 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"
> wrote:
>
>>
>> On 28 Nov 2012, at 17:51, Gleb Smirnoff wrote:
>>
>>> On Wed, Nov
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 do
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 bre
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.
>>
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_sysc
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 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 so
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-head@freebsd.org mailing list
http://lists.freebsd.
On 27 Aug 2011, at 09:21, Navdeep Parhar wrote:
>> (3) options BREAK_TO_DEBUGGER and options ALT_BREAK_TO_DEBUGGER continue
>> to behave as before -- only now instead of compiling in
>> break-to-debugger support, they change the default values of the
>> above sysctls to enable tho
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 rep
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 ch
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 cou
On 3 Mar 2011, at 13:14, Alexander Leidinger wrote:
> Quoting Robert Watson (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 always
On 1 Mar 2011, at 14:53, Alexander Leidinger wrote:
> Quoting Robert Watson (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 for
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-head@freebsd.org mailing list
http://lis
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 SC
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 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 s
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 p
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 ar
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
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 per
On 24 Oct 2010, at 14:20, Alexander Best 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 11 Jul 2010, at 04:18, Gabor PALI wrote:
> On Sat, Jul 10, 2010 at 5:24 PM, Robert N. M. Watson
> wrote:
>> If we can do it in one atomic in the common case, and two atomics in an edge
>> case, that sounds fine. I think any use of locking(9) would be sufficiently
>
On 9 Jul 2010, at 19:58, Gabor PALI wrote:
>> I assume there are reasonable alternatives that work around the
>> potential race with a small probability of a missed or extra update,
>> or similar, which would be fine.
>
> In a few words: As far as I know, 64-bit atomic counters could be
> imple
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 cycl
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 dr
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 i
useful is adding a new IFCAP flag that allows
a driver to statically declare 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
>
> --
If we haven't converted that
>particular driver by then, we will update the driver if it's capable
> at that time.
>
> -- Qing
>
>
> On Fri, Mar 12, 2010 at 12:00 AM, Robert N. M. Watson
> wrote:
>>
>> On Mar 12, 2010, at 7:52 AM, Qing Li wrote
On Mar 12, 2010, at 8:11 AM, Qing Li wrote:
> I like Julian's suggestion because it is simple and very low risk.
> And there isn't a need to check for interface type any more.
> Here is why:
>
> 1. The interfaces that are popular and modern are already supporting
>link_state. So for these dr
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 th
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 devic
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 a
62 matches
Mail list logo
