This commit is contained in:
Henrik Jess Nielsen
221
tools/benchmark-harness/vendored/docling/md/nougat_023.md
Normal file
221
tools/benchmark-harness/vendored/docling/md/nougat_023.md
Normal file
@@ -0,0 +1,221 @@
|
||||
## Discussion topics, Linux IPsec Workshop
|
||||
|
||||
Steffen Klassert secunet Security Networks AG
|
||||
|
||||
Dresden
|
||||
|
||||
Linux IPsec Workshop, Dresden, March 26, 2018
|
||||
|
||||
Discussion topics, Linux IPsec Workshop
|
||||
|
||||
Future of PFKEY in the kernel
|
||||
|
||||
Configurable system policy default (allow/drop)
|
||||
|
||||
Crypto layer problems
|
||||
|
||||
Hardware GRO
|
||||
|
||||
## Future of PFKEY in the kernel
|
||||
|
||||
- glyph[trianglerightsld] PFKEY is buggy
|
||||
- glyph[trianglerightsld] Google syscall fuzzer reports more and more (security related) bugs
|
||||
- glyph[trianglerightsld] No active development since more that 10 years
|
||||
- glyph[trianglerightsld] Do we still need to support PFKEY, and if yes how long?
|
||||
- glyph[trianglerightsld] What do we need to do to be able to remove PKKEY from the kernel?
|
||||
- glyph[trianglerightsld] How do we handle the PFKEY bug reports until we can remove it?
|
||||
|
||||
## Future of PFKEY in the kernel
|
||||
|
||||
## glyph[trianglerightsld] PFKEY is buggy
|
||||
|
||||
- glyph[trianglerightsld] Google syscall fuzzer reports more and more (security related) bugs
|
||||
- glyph[trianglerightsld] No active development since more that 10 years
|
||||
- glyph[trianglerightsld] Do we still need to support PFKEY, and if yes how long?
|
||||
- glyph[trianglerightsld] What do we need to do to be able to remove PKKEY from the kernel?
|
||||
- glyph[trianglerightsld] How do we handle the PFKEY bug reports until we can remove it?
|
||||
|
||||
## Future of PFKEY in the kernel
|
||||
|
||||
- glyph[trianglerightsld] PFKEY is buggy
|
||||
- glyph[trianglerightsld] Google syscall fuzzer reports more and more (security related) bugs
|
||||
- glyph[trianglerightsld] No active development since more that 10 years
|
||||
- glyph[trianglerightsld] Do we still need to support PFKEY, and if yes how long?
|
||||
- glyph[trianglerightsld] What do we need to do to be able to remove PKKEY from the kernel?
|
||||
- glyph[trianglerightsld] How do we handle the PFKEY bug reports until we can remove it?
|
||||
|
||||
## Future of PFKEY in the kernel
|
||||
|
||||
- glyph[trianglerightsld] PFKEY is buggy
|
||||
- glyph[trianglerightsld] Google syscall fuzzer reports more and more (security related) bugs
|
||||
- glyph[trianglerightsld] No active development since more that 10 years
|
||||
- glyph[trianglerightsld] Do we still need to support PFKEY, and if yes how long?
|
||||
- glyph[trianglerightsld] What do we need to do to be able to remove PKKEY from the kernel?
|
||||
- glyph[trianglerightsld] How do we handle the PFKEY bug reports until we can remove it?
|
||||
|
||||
## Future of PFKEY in the kernel
|
||||
|
||||
- glyph[trianglerightsld] PFKEY is buggy
|
||||
- glyph[trianglerightsld] Google syscall fuzzer reports more and more (security related) bugs
|
||||
- glyph[trianglerightsld] No active development since more that 10 years
|
||||
- glyph[trianglerightsld] Do we still need to support PFKEY, and if yes how long?
|
||||
- glyph[trianglerightsld] What do we need to do to be able to remove PKKEY from the kernel?
|
||||
- glyph[trianglerightsld] How do we handle the PFKEY bug reports until we can remove it?
|
||||
|
||||
## Future of PFKEY in the kernel
|
||||
|
||||
- glyph[trianglerightsld] PFKEY is buggy
|
||||
- glyph[trianglerightsld] Google syscall fuzzer reports more and more (security related) bugs
|
||||
- glyph[trianglerightsld] No active development since more that 10 years
|
||||
- glyph[trianglerightsld] Do we still need to support PFKEY, and if yes how long?
|
||||
- glyph[trianglerightsld] What do we need to do to be able to remove PKKEY from the kernel?
|
||||
- glyph[trianglerightsld] How do we handle the PFKEY bug reports until we can remove it?
|
||||
|
||||
## Future of PFKEY in the kernel
|
||||
|
||||
- glyph[trianglerightsld] PFKEY is buggy
|
||||
- glyph[trianglerightsld] Google syscall fuzzer reports more and more (security related) bugs
|
||||
- glyph[trianglerightsld] No active development since more that 10 years
|
||||
- glyph[trianglerightsld] Do we still need to support PFKEY, and if yes how long?
|
||||
- glyph[trianglerightsld] What do we need to do to be able to remove PKKEY from the kernel?
|
||||
- glyph[trianglerightsld] How do we handle the PFKEY bug reports until we can remove it?
|
||||
|
||||
## Configurable system policy default (allow/drop)
|
||||
|
||||
- glyph[trianglerightsld] The current default behaviour is to allow traffic if there is no matching policy
|
||||
- glyph[trianglerightsld] A patch that make the default configurable (allow/drop) exists
|
||||
- glyph[trianglerightsld] Each direction can be configured sepatately (input/output/forward)
|
||||
- glyph[trianglerightsld] When default is block, we need allow policies for all packet flows we accept
|
||||
- glyph[trianglerightsld] Would this be usefull for the userspace?
|
||||
|
||||
## Configurable system policy default (allow/drop)
|
||||
|
||||
- glyph[trianglerightsld] The current default behaviour is to allow traffic if there is no matching policy
|
||||
- glyph[trianglerightsld] A patch that make the default configurable (allow/drop) exists
|
||||
- glyph[trianglerightsld] Each direction can be configured sepatately (input/output/forward)
|
||||
- glyph[trianglerightsld] When default is block, we need allow policies for all packet flows we accept
|
||||
- glyph[trianglerightsld] Would this be usefull for the userspace?
|
||||
|
||||
## Configurable system policy default (allow/drop)
|
||||
|
||||
- glyph[trianglerightsld] The current default behaviour is to allow traffic if there is no matching policy
|
||||
- glyph[trianglerightsld] A patch that make the default configurable (allow/drop) exists
|
||||
- glyph[trianglerightsld] Each direction can be configured sepatately (input/output/forward)
|
||||
- glyph[trianglerightsld] When default is block, we need allow policies for all packet flows we accept
|
||||
- glyph[trianglerightsld] Would this be usefull for the userspace?
|
||||
|
||||
## Configurable system policy default (allow/drop)
|
||||
|
||||
- glyph[trianglerightsld] The current default behaviour is to allow traffic if there is no matching policy
|
||||
- glyph[trianglerightsld] A patch that make the default configurable (allow/drop) exists
|
||||
- glyph[trianglerightsld] Each direction can be configured sepatately (input/output/forward)
|
||||
- glyph[trianglerightsld] When default is block, we need allow policies for all packet flows we accept
|
||||
- glyph[trianglerightsld] Would this be usefull for the userspace?
|
||||
|
||||
## Configurable system policy default (allow/drop)
|
||||
|
||||
- glyph[trianglerightsld] The current default behaviour is to allow traffic if there is no matching policy
|
||||
- glyph[trianglerightsld] A patch that make the default configurable (allow/drop) exists
|
||||
- glyph[trianglerightsld] Each direction can be configured sepatately (input/output/forward)
|
||||
- glyph[trianglerightsld] When default is block, we need allow policies for all packet flows we accept
|
||||
- glyph[trianglerightsld] Would this be usefull for the userspace?
|
||||
|
||||
## Configurable system policy default (allow/drop)
|
||||
|
||||
- glyph[trianglerightsld] The current default behaviour is to allow traffic if there is no matching policy
|
||||
- glyph[trianglerightsld] A patch that make the default configurable (allow/drop) exists
|
||||
- glyph[trianglerightsld] Each direction can be configured sepatately (input/output/forward)
|
||||
- glyph[trianglerightsld] When default is block, we need allow policies for all packet flows we accept
|
||||
- glyph[trianglerightsld] Would this be usefull for the userspace?
|
||||
|
||||
## Crypto layer problems
|
||||
|
||||
- glyph[trianglerightsld] There is a lot of memcpy in the crypto layer
|
||||
- glyph[trianglerightsld] IV generators copy if src and dst buffer are different
|
||||
- glyph[trianglerightsld] Some algorithm implementations are not able to do SG operations
|
||||
- glyph[trianglerightsld] Might be worth to do some performance optimizations in the crypto layer
|
||||
- glyph[trianglerightsld] IPsec performance optimizations are 'eaten up' in the crypto layer
|
||||
|
||||
## Crypto layer problems
|
||||
|
||||
## glyph[trianglerightsld] There is a lot of memcpy in the crypto layer
|
||||
|
||||
- glyph[trianglerightsld] IV generators copy if src and dst buffer are different
|
||||
- glyph[trianglerightsld] Some algorithm implementations are not able to do SG operations
|
||||
- glyph[trianglerightsld] Might be worth to do some performance optimizations in the crypto layer
|
||||
- glyph[trianglerightsld] IPsec performance optimizations are 'eaten up' in the crypto layer
|
||||
|
||||
## Crypto layer problems
|
||||
|
||||
- glyph[trianglerightsld] There is a lot of memcpy in the crypto layer
|
||||
- glyph[trianglerightsld] IV generators copy if src and dst buffer are different
|
||||
- glyph[trianglerightsld] Some algorithm implementations are not able to do SG operations
|
||||
- glyph[trianglerightsld] Might be worth to do some performance optimizations in the crypto layer
|
||||
- glyph[trianglerightsld] IPsec performance optimizations are 'eaten up' in the crypto layer
|
||||
|
||||
## Crypto layer problems
|
||||
|
||||
- glyph[trianglerightsld] There is a lot of memcpy in the crypto layer
|
||||
- glyph[trianglerightsld] IV generators copy if src and dst buffer are different
|
||||
- glyph[trianglerightsld] Some algorithm implementations are not able to do SG operations
|
||||
- glyph[trianglerightsld] Might be worth to do some performance optimizations in the crypto layer
|
||||
- glyph[trianglerightsld] IPsec performance optimizations are 'eaten up' in the crypto layer
|
||||
|
||||
## Crypto layer problems
|
||||
|
||||
- glyph[trianglerightsld] There is a lot of memcpy in the crypto layer
|
||||
- glyph[trianglerightsld] IV generators copy if src and dst buffer are different
|
||||
- glyph[trianglerightsld] Some algorithm implementations are not able to do SG operations
|
||||
- glyph[trianglerightsld] Might be worth to do some performance optimizations in the crypto layer
|
||||
- glyph[trianglerightsld] IPsec performance optimizations are 'eaten up' in the crypto layer
|
||||
|
||||
## Crypto layer problems
|
||||
|
||||
- glyph[trianglerightsld] There is a lot of memcpy in the crypto layer
|
||||
- glyph[trianglerightsld] IV generators copy if src and dst buffer are different
|
||||
- glyph[trianglerightsld] Some algorithm implementations are not able to do SG operations
|
||||
- glyph[trianglerightsld] Might be worth to do some performance optimizations in the crypto layer
|
||||
- glyph[trianglerightsld] IPsec performance optimizations are 'eaten up' in the crypto layer
|
||||
|
||||
Discussion topics, Linux IPsec Workshop Hardware GRO
|
||||
|
||||
## Hardware GRO
|
||||
|
||||
- glyph[trianglerightsld] Hardware GRO: Routeable version of LRO
|
||||
- glyph[trianglerightsld] Middleboxes could benefit from receive side HW offload too
|
||||
- glyph[trianglerightsld] Infrastructure was introduced recently
|
||||
- glyph[trianglerightsld] Do the NIC vendors plan to support it???
|
||||
|
||||
Discussion topics, Linux IPsec Workshop Hardware GRO
|
||||
|
||||
## Hardware GRO
|
||||
|
||||
- glyph[trianglerightsld] Hardware GRO: Routeable version of LRO
|
||||
- glyph[trianglerightsld] Middleboxes could benefit from receive side HW offload too
|
||||
- glyph[trianglerightsld] Infrastructure was introduced recently
|
||||
- glyph[trianglerightsld] Do the NIC vendors plan to support it???
|
||||
|
||||
## Hardware GRO
|
||||
|
||||
- glyph[trianglerightsld] Hardware GRO: Routeable version of LRO
|
||||
- glyph[trianglerightsld] Middleboxes could benefit from receive side HW offload too
|
||||
- glyph[trianglerightsld] Infrastructure was introduced recently
|
||||
- glyph[trianglerightsld] Do the NIC vendors plan to support it???
|
||||
|
||||
## Hardware GRO
|
||||
|
||||
- glyph[trianglerightsld] Hardware GRO: Routeable version of LRO
|
||||
- glyph[trianglerightsld] Middleboxes could benefit from receive side HW offload too
|
||||
- glyph[trianglerightsld] Infrastructure was introduced recently
|
||||
- glyph[trianglerightsld] Do the NIC vendors plan to support it???
|
||||
|
||||
Discussion topics, Linux IPsec Workshop
|
||||
|
||||
Hardware GRO
|
||||
|
||||
## Hardware GRO
|
||||
|
||||
- glyph[trianglerightsld] Hardware GRO: Routeable version of LRO
|
||||
- glyph[trianglerightsld] Middleboxes could benefit from receive side HW offload too
|
||||
- glyph[trianglerightsld] Infrastructure was introduced recently
|
||||
- glyph[trianglerightsld] Do the NIC vendors plan to support it???
|
||||
Reference in New Issue
Block a user