I disabled client signing from the client side, via OS X's global nsmb.conf file: https://discussions.apple.com/message/30282470#30282470 The performance was back to over 600 MB/s, as compared to 60 MB/s with signing. It just seems a bit weird to me that Apple, in response to the Badlock bug, would have changed the OS X client default to something with such drastic performance implications, without much notice. My contact at Apple said that the engineers were able to replicate the slow performance on OS X Server as well, so even if they didn't test it with Samba on Linux or FreeBSD servers, they might have just been too hasty in their response to Badlock. I wonder if they had only tested OS X clients with Windows Server. I wonder what that performance looks like, but I don't have access to Windows Server. On Wed, Jun 1, 2016 at 1:25 PM Jeremy Allison <jra at samba.org> wrote:> On Wed, Jun 01, 2016 at 05:23:29PM +0000, Seth Goldin wrote: > > Would signing cause a performance hit by an order of magnitude though? Is > > that expected behavior? If so, then it seems worth it to disable signing > > from the client, given that this is just a NAS on a LAN, not connected to > > the Internet. > > Possibly. There are many optimizations unsigned SMB can do > that signed SMB can't. > > Try it and see. >
On Wed, Jun 01, 2016 at 07:44:26PM +0000, Seth Goldin wrote:> I disabled client signing from the client side, via OS X's global nsmb.conf > file: https://discussions.apple.com/message/30282470#30282470 > > The performance was back to over 600 MB/s, as compared to 60 MB/s with > signing. > > It just seems a bit weird to me that Apple, in response to the Badlock bug, > would have changed the OS X client default to something with such drastic > performance implications, without much notice. My contact at Apple said > that the engineers were able to replicate the slow performance on OS X > Server as well, so even if they didn't test it with Samba on Linux or > FreeBSD servers, they might have just been too hasty in their response to > Badlock. I wonder if they had only tested OS X clients with Windows Server. > I wonder what that performance looks like, but I don't have access to > Windows Server.My guess is the Apple security Team gave the client devs no choice. Badlock was a protocol level bug (although the problem protocol was DCE-RPC, not SMB) and enabling SMB-signing fixes the problem with DCE-RPC tunnelled inside SMB[123] packets. Otherwise Apple would have had to do what Samba did, which was to fix the DCE-stack to refuse non-signed/sealed connections on security-sensitive pipes. Insisting on SMB signing is a simpler and quicker fix, especially if their server only accepts DCE-RPC tunnelled inside SMB[123] packets.
On Wed, Jun 01, 2016 at 07:44:26PM +0000, Seth Goldin wrote:> I disabled client signing from the client side, via OS X's global nsmb.conf > file: https://discussions.apple.com/message/30282470#30282470 > > The performance was back to over 600 MB/s, as compared to 60 MB/s with > signing. > > It just seems a bit weird to me that Apple, in response to the Badlock bug, > would have changed the OS X client default to something with such drastic > performance implications, without much notice. My contact at Apple said > that the engineers were able to replicate the slow performance on OS X > Server as well, so even if they didn't test it with Samba on Linux or > FreeBSD servers, they might have just been too hasty in their response to > Badlock. I wonder if they had only tested OS X clients with Windows Server. > I wonder what that performance looks like, but I don't have access to > Windows Server.What protocol is this? Metze has patches to use hardware-accellerated AES so that latest 3.11 will have much less impact on performance. I'm not sure those patches have already landed, but I want to counter the impression that signing is sooo bad for performance. It can be good, given the right protocol and CPU support. Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de SerNet & BSI laden ein: 29. Juni 2016, 2. IT-Grundschutztag 2016, BPA Berlin. Anmeldung: https://www.sernet.de/gstag
2016-06-02 8:48 GMT+02:00 Volker Lendecke <Volker.Lendecke at sernet.de>:> On Wed, Jun 01, 2016 at 07:44:26PM +0000, Seth Goldin wrote: > > I disabled client signing from the client side, via OS X's global > nsmb.conf > > file: https://discussions.apple.com/message/30282470#30282470 > > > > The performance was back to over 600 MB/s, as compared to 60 MB/s with > > signing. > > > > It just seems a bit weird to me that Apple, in response to the Badlock > bug, > > would have changed the OS X client default to something with such drastic > > performance implications, without much notice. My contact at Apple said > > that the engineers were able to replicate the slow performance on OS X > > Server as well, so even if they didn't test it with Samba on Linux or > > FreeBSD servers, they might have just been too hasty in their response to > > Badlock. I wonder if they had only tested OS X clients with Windows > Server. > > I wonder what that performance looks like, but I don't have access to > > Windows Server. > > What protocol is this? Metze has patches to use hardware-accellerated > AES so that latest 3.11 will have much less impact on performance. > > I'm not sure those patches have already landed, but I want to counter > the impression that signing is sooo bad for performance. It can be > good, given the right protocol and CPU support. >What would we have to do to get that hardware performance improvement? Just upgrade Samba to some version patched with Metze stuffs or is there also some drivers to be compiled and loaded into Kernel? The hardware seems to be included directly in CPU: https://en.wikipedia.org/wiki/Cryptographic_accelerator gave me: https://en.wikipedia.org/wiki/AES_instruction_set Then looking for my own desktop CPU I found that page from Intel where there is a line for "Intel® AES New Instructions" near the bottom: http://ark.intel.com/products/63697/Intel-Core-i7-3930K-Processor-12M-Cache-up-to-3_80-GHz Cheers, mathias> > Volker > > -- > SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen > phone: +49-551-370000-0, fax: +49-551-370000-9 > AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen > http://www.sernet.de, mailto:kontakt at sernet.de > > SerNet & BSI laden ein: 29. Juni 2016, > 2. IT-Grundschutztag 2016, BPA Berlin. > Anmeldung: https://www.sernet.de/gstag > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >