Hi!
> > On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik wrote:
> > > Upfront, let me admit that SUSE has a vested interest in a
> > > FIPS-certifiable Linux kernel.
> >
> > Sorry, but just because you have a "vested interest", or a financial
> > interest, or because you want it does not suddenly
Hi!
> > Any updates on that?
> >
> > I don't believe Torsten's concerns are simply about *applying* patches
> > but more about these long periods of radio silence. That kills
>
> Exactly. I could live with replies in the style of "old" Linus like:
> "Your code is crap, because it does X and Y".
Fix resource leak in error handling.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index bd270e66185e..40869ea1ed20 100644
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
@@ -1744,7 +1744,7 @@ ccp_run_sha_cmd
Hi!
> The following patch set provides a different approach to /dev/random which is
> called
> Linux Random Number Generator (LRNG) to collect entropy within the Linux
> kernel. The
> main improvements compared to the existing /dev/random is to provide
> sufficient entropy
> during boot time
On Sun 2018-12-09 23:47:17, Josh Triplett wrote:
> On Sun, Dec 09, 2018 at 09:06:00PM +0100, Pavel Machek wrote:
> ...
> > > > > The default permissions for the device are 600.
> > > >
> > > > Good. This does not belong to non-root.
> > >
&
Hi!
(sorry to bring up old thread).
> > > > > Intel(R) SGX is a set of CPU instructions that can be used by
> > > > > applications
> > > > > to set aside private regions of code and data. The code outside the
> > > > > enclave
> > > > > is disallowed to access the memory inside the enclave by t
Hi!
> This patch provides a performance improvement for the CRC16 calculations done
> in read/write
> workloads using the T10 Type 1/2/3 guard field. For example, today with
> sequential write
> workloads (one thread/CPU of IO) we consume 100% of the CPU because of the
> CRC16 computation
> bo
Hi!
> > Define unsafe.
> >
> > If you want security against bad people resuming your machines, please
> Yes, this is one of the requirements.
> > But I thought you were trying to do something for secure boot, and "bad
> > person resumes your machine" is out of scope there.
> >
> Not exactly, se
On Mon 2018-08-06 18:39:58, joeyli wrote:
> On Mon, Aug 06, 2018 at 04:45:34PM +0800, Yu Chen wrote:
> > Hi Pavel,
> > On Sun, Aug 05, 2018 at 12:02:00PM +0200, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > User space doesn't need to involve
Hi!
> > > > User space doesn't need to involve. The EFI root key is generated by
> > > > EFI boot stub and be transfer to kernel. It's stored in EFI boot service
> > > > variable that it can only be accessed by trusted EFI binary when
> > > > secure boot is enabled.
> > > >
> > > Okay, this apply
Hi!
> WarpDrive is a common user space accelerator framework. Its main component
> in Kernel is called spimdev, Share Parent IOMMU Mediated Device. It exposes
spimdev is really unfortunate name. It looks like it has something to do with
SPI, but
it does not.
> +++ b/Documentation/warpdrive/war
Hi!
> > User space doesn't need to involve. The EFI root key is generated by
> > EFI boot stub and be transfer to kernel. It's stored in EFI boot service
> > variable that it can only be accessed by trusted EFI binary when
> > secure boot is enabled.
> >
> Okay, this apply to the 'suspend' phase,
On Sat 2018-08-04 20:25:14, Theodore Y. Ts'o wrote:
> On Sat, Aug 04, 2018 at 11:52:10PM +0200, Pavel Machek wrote:
> > > However, enabling config option means that the CRNG will be
> > > initialized with potentially information available to the CPU
> > > man
Hi!
On Wed 2018-07-18 10:26:25, Theodore Y. Ts'o wrote:
> On Wed, Jul 18, 2018 at 09:22:13AM +0200, Yann Droneaud wrote:
> >
> > The text message should explain this is only relevant during
> > initialization / early boot.
> >
> > The config option name should state this.
>
> There are other wo
On Tue 2018-07-24 13:49:41, Oliver Neukum wrote:
> On Mo, 2018-07-23 at 14:22 +0200, Pavel Machek wrote:
>
> > > Yes. But you are objecting to encryption in kernel space at all,
> > > aren't you?
> >
> > I don't particulary love the idea of doing hib
On Tue 2018-07-24 14:47:54, Oliver Neukum wrote:
> On Di, 2018-07-24 at 14:01 +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > >"There have some functions be locked-down because
> > > > > >there have no appropriate mechani
Hi!
> > > Yes. But you are objecting to encryption in kernel space at all,
> > > aren't you?
> >
> > I don't particulary love the idea of doing hibernation encryption in
> > the kernel, correct.
> >
> > But we have this weird thing called secure boot, some people seem to
> > want. So we may need
Hi!
> > > >"There have some functions be locked-down because
> > > >there have no appropriate mechanisms to check the
> > > >integrity of writing data."
> > > >https://patchwork.kernel.org/patch/10476751/
> > >
> > > So your goal is to make hibernation compatible w
Hi!
> > > 2. Ideally kernel memory should be encrypted by the
> > >kernel itself. We have uswsusp to support user
> > >space hibernation, however doing the encryption
> > >in kernel space has more advantages:
> > >2.1 Not having to transfer plain text kernel memory to
> > >
Hi!
> > > > > As security becomes more and more important, we add the in-kernel
> > > > > encryption support for hibernation.
> > > >
> > > > Sorry, this does not really explain what security benefit it is
> > > > supposed have to against what attack scenarios.
> > > >
> > > > Which unfortunatel
On Thu 2018-07-19 07:58:51, Yu Chen wrote:
> Hi,
> On Wed, Jul 18, 2018 at 10:22:35PM +0200, Pavel Machek wrote:
> > On Thu 2018-07-19 00:38:06, Chen Yu wrote:
> > > As security becomes more and more important, we add the in-kernel
> > > encryption support for hib
On Thu 2018-07-19 00:38:06, Chen Yu wrote:
> As security becomes more and more important, we add the in-kernel
> encryption support for hibernation.
Sorry, this does not really explain what security benefit it is
supposed have to against what attack scenarios.
Which unfortunately means it can not
Hi!
On Tue 2017-07-18 21:51:33, Theodore Ts'o wrote:
> On Tue, Jul 18, 2017 at 09:00:10PM -0400, Sandy Harris wrote:
> > The only really good solution I know of is to find a way to provide a
> > chunk of randomness early in the boot process. John Denker has a good
> > discussion of doing this by m
On Thu 2017-06-22 06:42:01, Brijesh Singh wrote:
> CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor,
> which is not dedicated solely to crypto. The AMD Secure Processor includes
> CCP and PSP (Platform Secure Processor) devices.
>
> This patch series adds a framework that all
Hi!
> > From my point of view, it would make sense to factor time from RTC and
> > mac addresses into the initial hash. Situation in the paper was so bad
> > some devices had _completely identical_ keys. We should be able to do
> > better than that.
>
> We fixed that **years** ago. In fact, the
On Thu 2016-08-18 13:27:12, Theodore Ts'o wrote:
> On Wed, Aug 17, 2016 at 11:42:55PM +0200, Pavel Machek wrote:
> >
> > Actually.. I'm starting to believe that getting enough entropy before
> > userspace starts is more important than pretty much anything else.
>
Hi!
> As far as whether or not you can gather enough entropy at boot time,
> what we're really talking about how how much entropy we want to assume
> can be gathered from interrupt timings, since what you do in your code
> is not all that different from what the current random driver is
> doing.
On Fri 2016-07-08 10:19:26, Linus Torvalds wrote:
> [ rare comment rant. I think I'll do this once, and then ignore the
> discussion ]
>
> On Fri, Jul 8, 2016 at 9:45 AM, Herbert Xu
> wrote:
> >
> > Nack. As I said the commenting style in the crypto API is the
> > same as the network stack. S
On Mon 2016-06-13 11:48:39, Theodore Ts'o wrote:
> Signed-off-by: Theodore Ts'o
> ---
> drivers/char/random.c | 54
> ++-
> 1 file changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index d64
Hi!
> Yes, I understand the argument that the networking stack is now
> requiring the crypto layer --- but not all IOT devices may necessarily
> require the IP stack (they might be using some alternate wireless
> communications stack) and I'd much rather not make things worse.
>
>
> The final th
Hi!
> 6. You have a significant lack of data regarding embedded systems, which is
> one of the two biggest segments of Linux's market share. You list no
> results for any pre-ARMv6 systems (Linux still runs on and is regularly used
> on ARMv4 CPU's, and it's worth also pointing out that the value
Hi!
> > On Sun 2016-06-19 17:58:41, Stephan Mueller wrote:
> > > Hi Herbert, Ted,
> > >
> > > The following patch set provides a different approach to /dev/random which
> > > I call Linux Random Number Generator (LRNG) to collect entropy within the
> > > Linux kernel. The main improvements compar
On Sun 2016-06-19 17:58:41, Stephan Mueller wrote:
> Hi Herbert, Ted,
>
> The following patch set provides a different approach to /dev/random which
> I call Linux Random Number Generator (LRNG) to collect entropy within the
> Linux
> kernel. The main improvements compared to the legacy /dev/rand
Hi!
> > > > When dropping the add_disk_randomness function in the legacy
> > > > /dev/random, I
> > > > would assume that without changes to add_input_randomness and
> > > > add_interrupt_randomness, we become even more entropy-starved.
> > >
> > > Sure, but your system isn't doing anything magic
Hi1
> > When dropping the add_disk_randomness function in the legacy /dev/random, I
> > would assume that without changes to add_input_randomness and
> > add_interrupt_randomness, we become even more entropy-starved.
>
> Sure, but your system isn't doing anything magical here. The main
> diffe
Hi!
> > So you are relying on high-resolution timestamps. Ok. then you do kind
> > of the check on the timestamps... ok, why not. But then you mix in the
> > data regardless, saying that "they are not dependent" and thus can't
> > hurt.
> >
> > But you already know they _are_ dependent, that's wh
Hi!
> Please find in [1] the full design discussion covering qualitative assessments
> of the entropy collection and entropy flow. Furthermore, a full
> testing of the
I don't get it.
# The
# idea is that only after obtaining LRNG_POOL_SIZE_BITS healthy bits,
# the
#entropy pool is completely ch
On Tue 2015-09-15 16:03:36, David Howells wrote:
> From: David Woodhouse
>
> The GPL does not permit us to link against the OpenSSL library. Use
> LGPL for sign-file and extract-file instead.
Actually GPL does permit you to link to "system libraries", and it looks like
OpenSSL is pretty much sy
On Tue 2015-06-23 23:47:33, Stephan Mueller wrote:
> Am Dienstag, 23. Juni 2015, 22:44:11 schrieb Pavel Machek:
>
> Hi Pavel,
>
> > On Mon 2015-05-18 18:25:25, Stephan Mueller wrote:
> > > Make the threshold at which the output entropy pools are considered to
> &
On Mon 2015-05-18 18:25:25, Stephan Mueller wrote:
> Make the threshold at which the output entropy pools are considered to
> be initialized configurable via a kernel command line option. The
> current integer value of 128 bits is a good default value. However, some
> user groups may want to use di
On Sun 2015-03-08 11:01:01, Pali Rohár wrote:
> Function pm_runtime_get_sync could fail and we need to check return
> value to prevent kernel crash.
>
> Signed-off-by: Pali Rohár
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pic
On Thu 2015-02-26 14:49:55, Pali Rohár wrote:
> Device timer12 is automatically disabled on all HS devices via DTS property
> "ti,timer-secure" in file omap3.dtsi so it can be safely removed. We do not
> need to disable it on another place.
Dunno. Theoretically, Linux is not the only user of dts..
On Thu 2015-02-26 14:49:56, Pali Rohár wrote:
> This patch adds missing dma DTS definitions for omap aes and sham drivers.
> Without it kernel drivers do not work.
>
> Signed-off-by: Pali Rohár
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(ces
On Thu 2015-02-26 14:50:00, Pali Rohár wrote:
> These files are not used by any DTS file anymore.
>
> Signed-off-by: Pali Rohár
Acked-by: Pavel Machek
> ---
> arch/arm/boot/dts/omap34xx-hs.dtsi | 12
> arch/arm/boot/dts/omap36xx-hs.dtsi | 12
On Thu 2015-02-26 14:49:59, Pali Rohár wrote:
> This patch just move content of file omap34xx-hs.dtsi into omap3-tao3530.dts.
> There is no code change, patch is just preparation for removing -hs file.
>
> Signed-off-by: Pali Rohár
Acked-by: Pavel Machek
> --- a/arch/arm
oader enable L3
> firewall
> for omap sham. There is no kernel crash with both official bootloader and
> crypto
> enable bootloader. So we can safely enable sham code.
>
> Signed-off-by: Pali Rohár
Acked-by: Pavel Machek
> +/*
> + * Default secure signed bootloader (Nokia X
ed-off-by: Pali Rohár
Acked-by: Pavel Machek
> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> @@ -8,7 +8,7 @@
> * published by the Free Software Foundation.
> */
>
> -#include "omap36xx-hs.dtsi"
> +#include "
On Thu 2015-02-26 14:49:54, Pali Rohár wrote:
> Function pm_runtime_get_sync could fail and we need to check return
> value to prevent kernel crash.
>
> Signed-off-by: Pali Rohár
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pic
ble to use omap-aes and omap-sham linux drivers.
>
> Signed-off-by: Pali Rohár
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the li
On Thu 2015-02-26 14:49:53, Pali Rohár wrote:
> omap3 support is same as omap2, just with different IO address (specified in
> DT)
>
> Signed-off-by: Pali Rohár
Acked-by: Pavel Machek
> @@ -1792,6 +1792,10 @@ static const struct of_device_id omap_sham_of_match[]
> = {
>
On Tue 2015-02-24 09:37:34, Tony Lindgren wrote:
> * Pali Rohár [150224 09:42]:
> > On Tuesday 24 February 2015 18:25:12 Tony Lindgren wrote:
> > > * Pali Rohár [150218 16:03]:
> > > > --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> > > > +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> > >
On Thu 2014-07-31 10:06:37, Bernd Petrovitsch wrote:
> On Don, 2014-07-31 at 00:18 +0200, Pavel Machek wrote:
> > On Wed 2014-07-30 16:40:52, Bernd Petrovitsch wrote:
> > > On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote:
> > > > Pavel. I have bit 'ol enterpr
On Wed 2014-07-30 16:40:52, Bernd Petrovitsch wrote:
> On Mit, 2014-07-30 at 07:56 -0600, Bob Beck wrote:
> > Pavel. I have bit 'ol enterprise daemon running with established file
> > descriptors serving thousands of connections
> > which periodically require entropy. Now I run out of descriptors.
On Wed 2014-07-23 14:10:16, Hannes Frederic Sowa wrote:
>
>
> On Wed, Jul 23, 2014, at 13:52, George Spelvin wrote:
> > I keep wishing for a more general solution. For example, some way to
> > have a "spare" extra fd that could be accessed with a special O_NOFAIL
> > flag.
> >
> > That would al
Hi!
> The rationale of this system call is to provide resiliance against
> file descriptor exhaustion attacks, where the attacker consumes all
> available file descriptors, forcing the use of the fallback code where
> /dev/[u]random is not available. Since the fallback code is often not
> well-te
On Mon 2014-05-12 00:36:01, Stephan Mueller wrote:
> Hi,
>
> as discussed in thread [1], an in-kernel equivalent to the blocking
> /dev/random device behavior is suggested. This in-kernel blocking access to
> the RNG can be used to seed deterministic random number generators with
> random
> nu
Hi!
> Most likely yes but I wanted to keep sha1_ssse3_mod_init consistent
> with sha256_ssse3_mod_init/sha512_ssse3_mod_init functions.
> > > Reported-by:
> > > Signed-off-by: Milos Vyletel
> > > ---
> > > arch/x86/crypto/sha1_ssse3_glue.c | 22 --
> > > 1 file changed, 12
On Wed 2014-04-30 15:17:54, Milos Vyletel wrote:
> Coverity detected possible use of uninitialized pointer when printing info
> message during module load. While this is higly unlikely to cause any troubles
> simple change in sha1_ssse3_mod_init to make it look like sha256/512 init
> function will
Hi!
> >BTW: MFENCE is not guaranteed to flush the instruction pipeline; you
> >need CPUID for that.
>
> I was not aware of that. Can I simply call the CPUID instruction to read
> it or do I have to do something special?
Simply call CPUID (warning, it clobbers some registers.).
Hi!
> >I plugged that idea into my current Jitter RNG processing and disabled
> >the other jitter measurements to get a clear, isolated picture.
> >
> >The result is also a white noise! And it is even quite fast.
>
> After doing some more research on this approach, I have to admit that
> the out
Hi!
> Of course, some of the state in the CPU may not be unknown to the
> attacker, if it is derived by external events that are not visible to
> the attacker, such as a network interrupt. But if that's the case,
> why not measure network interrupts directly? We're much less likely
> to overesti
Hi!
> Another friend of mine mentioned that he assumes the rise and fall times
> of transistors varies very slightly and could be the main reason for the
> jitter. I do not think that this is really the case, because our gates
> that form the CPU instructions comprise of many transistors. The
On Sat 2013-11-02 12:01:12, Pavel Machek wrote:
> Hi!
>
> > >sense of where the unpredictability might be coming from, and whether
> > >the unpredictability is coming from something which is fundamentally
> > >arising from something which is chaotic or quantu
Hi!
> >sense of where the unpredictability might be coming from, and whether
> >the unpredictability is coming from something which is fundamentally
> >arising from something which is chaotic or quantum effect, or just
> >because we don't have a good way of modelling the behavior of the
> >L1/L2 c
Hi!
> For the symmetric key solution, I will try HMAC (Hash Message
> Authentication Code). It's already used in networking, hope the
> performance is not too bad to a big image.
Kernel already supports crc32 of the hibernation image, you may want
to take a look how that is done.
Maybe you want
Hi!
> > On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote:
> > > This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> > > hash algorithm will be used during signature generation of snapshot.
> >
> > This series is big enough already... and who is going to test it?
>
> The hash
On Wed 2013-09-25 15:16:54, James Bottomley wrote:
> On Wed, 2013-09-25 at 17:25 -0400, Alan Stern wrote:
> > On Wed, 25 Sep 2013, David Howells wrote:
> >
> > > I have pushed some keyrings patches that will likely affect this to:
> > >
> > >
> > > http://git.kernel.org/cgit/linux/kernel/git/d
On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote:
> This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> hash algorithm will be used during signature generation of snapshot.
This series is big enough already... and who is going to test it?
There's no need to make hash configurab
Hi!
> > >- Bootloader store the public key to EFI boottime variable by itself
> > >- Bootloader put The private key to S4SignKey EFI variable for forward
> > > to
> > > kernel.
> >
> > Is the UEFI NVRAM really suited for such regular updates?
> >
>
> Yes, Matthew raised this conce
On Tue 2013-08-27 14:01:42, Manfred Hollstein wrote:
> On Tue, 27 Aug 2013, 13:29:43 +0200, Pavel Machek wrote:
> > > > > @@ -1205,6 +1290,10 @@ struct boot_params *efi_main(void *handle,
> > > > > efi_system_table_t *_table,
> > > >
On Tue 2013-08-27 18:22:17, joeyli wrote:
> 於 日，2013-08-25 於 18:43 +0200，Pavel Machek 提到：
> > On Thu 2013-08-22 19:01:56, Lee, Chun-Yi wrote:
> > > This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> > > hash algorithm will be used during signa
> > > @@ -1205,6 +1290,10 @@ struct boot_params *efi_main(void *handle,
> > > efi_system_table_t *_table,
> > >
> > > setup_efi_pci(boot_params);
> > >
> > > +#ifdef CONFIG_SNAPSHOT_VERIFICATION
> > > + setup_s4_keys(boot_params);
> > > +#endif
> > > +
> >
> > Move ifdef inside the functio
Hi!
> > > Due to RSA_I2OSP is not only used by signature verification path but also
> > > used
> > > in signature generation path. So, separate the length checking of octet
> > > string
> > > because it's not for generate 0x00 0x01 leading string when used in
> > > signature
> > > generation.
>
On Thu 2013-08-22 19:01:56, Lee, Chun-Yi wrote:
> This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> hash algorithm will be used during signature generation of snapshot.
>
> v2:
> Add define check of oCONFIG_SNAPSHOT_VERIFICATION in snapshot.c before
> declare pkey_hash().
>
On Thu 2013-08-22 19:01:54, Lee, Chun-Yi wrote:
> In current solution, the snapshot signature check used the RSA key-pair
> that are generated by bootloader(e.g. shim) and pass the key-pair to
> kernel through EFI variables. I choice to binding the snapshot
> signature check mechanism with UEFI sec
On Thu 2013-08-22 19:01:52, Lee, Chun-Yi wrote:
> This patch add swsusp_page_is_sign_key() method to hibernate_key.c and
> check the page is S4 sign key data when collect saveable page in
> snapshot.c to avoid sign key data included in snapshot image.
>
> Reviewed-by: Jiri Kosina
> Signed-off-by:
On Thu 2013-08-22 19:01:51, Lee, Chun-Yi wrote:
> This patch add the code for generate/verify signature of snapshot, it
> put the signature to snapshot header. This approach can support both
> on userspace hibernate and in-kernel hibernate.
>
> v2:
> - Due to loaded S4 sign key before ExitBootServ
On Thu 2013-08-22 19:01:50, Lee, Chun-Yi wrote:
> Introduced a hibernate_key.c file to query the key pair from EFI variables
> and maintain key pair for check signature of S4 snapshot image. We
> loaded the private key when snapshot image stored success.
>
> This patch introduced 2 EFI variables f
On Thu 2013-08-22 19:01:49, Lee, Chun-Yi wrote:
> From: Matthew Garrett
>
> The firmware has a set of flags that indicate whether secure boot is enabled
> and enforcing. Use them to indicate whether the kernel should lock itself
> down. We also indicate the machine is in secure boot mode by addi
You may want to check subject. If it does something, it is not dummy.
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2784,6 +2784,13 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> Note: increases p
On Thu 2013-08-22 19:01:47, Lee, Chun-Yi wrote:
> From: Matthew Garrett
>
> Secure boot adds certain policy requirements, including that root must not
> be able to do anything that could cause the kernel to execute arbitrary code.
> The simplest way to handle this would seem to be to add a new ca
On Thu 2013-08-22 19:01:46, Lee, Chun-Yi wrote:
> Per PKCS1 spec, the EMSA-PKCS1-v1_5 encoded message is leading by 0x00 0x01 in
> its first 2 bytes. The leading zero byte is suppressed by MPI so we pass a
> pointer to the _preceding_ byte to RSA_verify() in original code, but it has
> risk for the
On Thu 2013-08-22 19:01:45, Lee, Chun-Yi wrote:
> Add ASN.1 files and parser to support parsing PKCS #8 noncompressed private
> key information. It's better than direct parsing pure private key because
> PKCS #8 has a privateKeyAlgorithm to indicate the algorithm of private
> key, e.g. RSA from PKC
On Thu 2013-08-22 19:01:42, Lee, Chun-Yi wrote:
> Due to RSA_I2OSP is not only used by signature verification path but also used
> in signature generation path. So, separate the length checking of octet string
> because it's not for generate 0x00 0x01 leading string when used in signature
> generat
On Thu 2013-08-22 19:01:41, Lee, Chun-Yi wrote:
> Implement EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2] in rsa.c. It's the
> first step of signature generation operation
> (RSASSA-PKCS1-v1_5-SIGN).
Is this your own code, or did you copy it from somewhere?
> + if (!T)
> + goto error_T
On Mon 2011-02-07 19:24:43, Jesper Juhl wrote:
> On Mon, 7 Feb 2011, tadeusz.st...@intel.com wrote:
>
> > From:
> > Date: Sun, 16 Jan 2011 16:41:11 +
> > Subject: RE: [PATCH] rfc4106, Intel, AES-NI: Don't leak memory in
> > rfc4106_set_hash_subkey().
> >
> > Hi Jesper,
> > Thanks, but I thi
Hi!
> Motivations for the extensions: governments are asking for more security
> features in the operating systems they procure, which make user-space
> implementations impractical. A few examples:
>
> * Advanced crypto module for OSPP for Common Criteria requires OS services
> implementing se
On Fri 2008-08-08 21:35:30, Herbert Xu wrote:
> Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> >
> > I think you want to use
> >
> > #define SCALE_F sizeof(unsigned long)
>
> Yeah in general that's what we should do. However, this driver
> is specific to Intel x86 CPUs.
I thought we support intel
On Wed 2008-08-06 07:05:27, Austin Zhang wrote:
> Paval,
>
> Thanks for your comments.
>
> On Wed, 2008-08-06 at 11:42 +0200, Pavel Machek wrote:
> > Copyright / GPL?
> Yes, as : ???+MODULE_LICENSE("GPL");
Well, it should normally go t
Hi!
> ??Revised by comments:
> Add 'static' for limitation namespace;
> Resend for fixing lines-folded by adjusting evolution config;
> (The patch was created against 2.6.27-rc1)
>
> >From NHM processor onward, Intel processors can support hardware accelerated
> CRC32c algorithm with the new
Hi!
> > well, the situation for external modules is no worse than usual.
> > They still work, they just aren't signed. Which from a distributor point
> > of view, is actually a nice thing, as they stick out like a sore thumb
> > in oops reports with (U) markers :)
>
> I agree, that's really what
Hi!
> Now, this is not a complete solution by any means: the core kernel is not
> protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
> controls) one relatively simple attack vector.
Could we fix the /dev/*mem holes, first? They are already used by
malicious modules (aka root
On So 11-03-06 13:41:16, Herbert Xu wrote:
> On Sat, Mar 11, 2006 at 02:03:39AM +0100, Adrian Bunk wrote:
> >
> > ...
> > #define loop8(i)\
>
> ...
>
> > t ^= E_KEY[8 * i + 7]; E_KEY[8 * i + 15] = t; \
> > }
> >
> > static int
> > aes_set_key(void *ctx_a
93 matches
Mail list logo
