search for: zeroizes

utils/mkdiskimage.in: New option -S to sync zeroizing after each cylinder and to issue pacifier messages. --- utils/mkdiskimage_patched_03.in 2014-01-30 20:54:27.000000000 +0100 +++ utils/mkdiskimage.in 2014-01-30 20:59:19.000000000 +0100 @@ -139,6 +139,7 @@ if ( $file eq '' || $c < 1 || $h < 1 || print STDERR " -4 use partition entry 4 (standard for

utils/mkdiskimage.in: With option -s: Avoid zeroizing the partition even if truncate() failed. --- utils/mkdiskimage_patched_01.in 2014-01-30 20:43:02.000000000 +0100 +++ utils/mkdiskimage.in 2014-01-30 20:45:09.000000000 +0100 @@ -217,8 +217,11 @@ print OUTPUT "\x55\xaa"; $totalsize = $c*$h*$s; $tracks = $c*$h; -# If -s is given, try to simply use truncate... -unless

Hi, this is the diff which i consider a halfways reasonable solution for the following problems with mkdiskimage: 1. Ignoring option -s if the target file is not suitable for truncate(). 2. Miscalculation of truncate() size by a factor of 512. 3. The storage capacity of device files can only be measured for Linux block devices. 4. Long time of silent work when slow devices (e.g. USB

Hi, i too played with mkdiskimage in order to get more Linux examples. When i applied it to a real 2 GB stick with write speed 4 MB/s i had enough time to add some pacifier code to the big zeroizer loop. (-s does not prevent zeroizing on block device. Probably because truncate() fails.) My pacifier is combined with what Perl advised me when i tried "fsync(OUTPUT);". Of course this

--- utils/mkdiskimage.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils/mkdiskimage.in b/utils/mkdiskimage.in index 533193a..a95a077 100644 --- a/utils/mkdiskimage.in +++ b/utils/mkdiskimage.in @@ -218,7 +218,7 @@ $totalsize = $c*$h*$s; $tracks = $c*$h; # If -s is given, try to simply use truncate... -unless ($opt{'s'} && truncate(OUTPUT,

...te state is tested for its designated purpose only. The final state after applying all patches is tested with various options, suitable and unsuitable file types of various sizes. ---------------------------------------------------------------- I will think about another patch for an option which zeroizes the whole device even if the partition size is given explicitely and matches a cylinder end. (mkdiskimage_05.patch only zeroizes a known incomplete cylinder after the partition end.) Although mkdiskimage should be suitable now for USB sticks on unix-like systems beyond Linux, i still have no clue...

On 07/10/2014 12:18 PM, Geert Stappers wrote: >> >> following is a series of patches derived from my proposed diff. >> Based on syslinux-6.03-pre1, but should also apply down to 4.xx. >> >> I hope to have imitated the changelog style sufficiently. >> Mine are a bit longer than usual with patches in the archive, i fear. > > Yes, they are long. > There

Hello everyone, Since I have some some adventures in UEFI PXE booting ahead I tried to go with the latest syslinux development snapshot in this case 5.10pre1. But I already fail when booting from CD with Failed to load COM32 file .c32 I am a bit perplex since no name of COM32 files is given. I am trying to trace down the issue as good as I can. COM32 files present are:

On Mon, Jun 17, 2013 at 10:29 AM, Jeffrey Walton <noloader at gmail.com> wrote: > > > First is to ensure dead-writes are not removed. For example, a > function that zeroizes or wipes memory is subject to removal during > optimization. I often have to look at program's disassembly to ensure > the memset is not removed by the optimizer. > Appropriate use of `volatile` is probably sufficient for this use case. -- Sean Silva -------------- next part --------...

Hi, me: > >> I hope to have imitated the changelog style sufficiently. > >> Mine are a bit longer than usual with patches in the archive, i fear. Geert Stappers: > > Yes, they are long. H. Peter Anvin: > There seems to be no patch descriptions at all, which would really help > long-term maintainability. It is a mid-term while ago since i proposed these patches.

On Mon, Jun 17, 2013 at 6:23 PM, Sean Silva <silvas at purdue.edu> wrote: > On Mon, Jun 17, 2013 at 10:29 AM, Jeffrey Walton <noloader at gmail.com> wrote: >> First is to ensure dead-writes are not removed. For example, a >> function that zeroizes or wipes memory is subject to removal during >> optimization. I often have to look at program's disassembly to ensure >> the memset is not removed by the optimizer. > > Appropriate use of `volatile` is probably sufficient for this use case. That brings up a good point. As I un...

...ses our users' primary use-case without introducing the > complexity of full per-function optimization level control at this time. Unlike the cited use case, I encounter two others in the field during code reviews. First is to ensure dead-writes are not removed. For example, a function that zeroizes or wipes memory is subject to removal during optimization. I often have to look at program's disassembly to ensure the memset is not removed by the optimizer. Second is to ensure that questionable code (undefined behavior) is not removed. I see this most often in overflow checks when the progr...

On 01/23/2014 08:47 AM, Thomas Schmitt wrote: > Hi, > > i too played with mkdiskimage in order to get more Linux examples. > > When i applied it to a real 2 GB stick with write speed 4 MB/s > i had enough time to add some pacifier code to the big zeroizer > loop. (-s does not prevent zeroizing on block device. Probably > because truncate() fails.) > Yes, we should

...ignated purpose only. > The final state after applying all patches is tested with various > options, suitable and unsuitable file types of various sizes. > > ---------------------------------------------------------------- > > I will think about another patch for an option which zeroizes > the whole device even if the partition size is given explicitely > and matches a cylinder end. (mkdiskimage_05.patch only zeroizes > a known incomplete cylinder after the partition end.) > > Although mkdiskimage should be suitable now for USB sticks > on unix-like systems beyon...

Hi, me: > > [mkdiskimage] -s does not prevent zeroizing on block device. Probably > > because truncate() fails. hpa: > Yes, we should probably fix that. The tool was originally designed for > images, not for hardware devices, and it doesn't make much sense to zero > the whole hardware device like that. Maybe for privacy reasons ? But indeed: -s should skip zeroizing,

On Thu, Dec 01, 2016 at 02:27:19AM +0000, Gonglei (Arei) wrote: > > On Tue, Nov 29, 2016 at 08:48:14PM +0800, Gonglei wrote: > > > +static int virtio_crypto_alg_ablkcipher_init_session( > > > + struct virtio_crypto_ablkcipher_ctx *ctx, > > > + uint32_t alg, const uint8_t *key, > > > + unsigned int keylen, > > > + int encrypt) > > > +{

On Thu, Dec 01, 2016 at 02:27:19AM +0000, Gonglei (Arei) wrote: > > On Tue, Nov 29, 2016 at 08:48:14PM +0800, Gonglei wrote: > > > +static int virtio_crypto_alg_ablkcipher_init_session( > > > + struct virtio_crypto_ablkcipher_ctx *ctx, > > > + uint32_t alg, const uint8_t *key, > > > + unsigned int keylen, > > > + int encrypt) > > > +{

Hi all, I am the developer of the llcon software (llcon.sf.net) which is a software making it possible for musicians to play in real-time over the internet. Up to now I have used ADPCM or no audio coding. Gregory Maxwell was pointing me to the great CELT project. Using CELT has the advantage to be able to use higher sample rates, getting lower code rate and better error concealment. I have

Hi, ...i''m fairly new to ruby on rails, so maybe this is a simple question, but i''ve been racking my wits for a while now, but i can''t figure out why this isn''t working... i''m implementing some kind of a questioniere, so that when a user picks a certain answer, the value of that answer goes into a session variable that stores the amount of points

On Tue, Nov 29, 2016 at 08:48:14PM +0800, Gonglei wrote: > diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c b/drivers/crypto/virtio/virtio_crypto_algs.c > new file mode 100644 > index 0000000..08b077f > --- /dev/null > +++ b/drivers/crypto/virtio/virtio_crypto_algs.c > @@ -0,0 +1,518 @@ > + /* Algorithms supported by virtio crypto device > + * > + * Authors: